On 31.07.2020 12:12, Julien Grall wrote: > On 31/07/2020 07:39, Jan Beulich wrote: >> We're fixing other issues without breaking the ABI. Where's the >> problem of backporting the kernel side change (which I anticipate >> to not be overly involved)? > This means you can't take advantage of the runstage on existing Linux > without any modification. > >> If the plan remains to be to make an ABI breaking change, > > For a theoritical PoV, this is a ABI breakage. However, I fail to see > how the restrictions added would affect OSes at least on Arm.
"OSes" covering what? Just Linux? > In particular, you can't change the VA -> PA on Arm without going > through an invalid mapping. So I wouldn't expect this to happen for the > runstate. > > The only part that *may* be an issue is if the guest is registering the > runstate with an initially invalid VA. Although, I have yet to see that > in practice. Maybe you know? I'm unaware of any such use, but this means close to nothing. >> then I >> think this will need an explicit vote. > > I was under the impression that the two Arm maintainers (Stefano and I) > already agreed with the approach here. Therefore, given the ABI breakage > is only affecting Arm, why would we need a vote? The problem here is of conceptual nature: You're planning to make the behavior of a common hypercall diverge between architectures, and in a retroactive fashion. Imo that's nothing we should do even for new hypercalls, if _at all_ avoidable. If we allow this here, we'll have a precedent that people later may (and based on my experience will, sooner or later) reference, to get their own change justified. Jan
