[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v2] xen/arm: Convert runstate address during hypcall
> On 31 Jul 2020, at 12:18, Jan Beulich <jbeulich@xxxxxxxx> wrote: > > 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. After a discussion with Jan, he is proposing to have a guest config setting to turn on or off the translation of the address during the hypercall and add a global Xen command line parameter to set the global default behaviour. With this was done on arm could be done on x86 and the current behaviour would be kept by default but possible to modify by configuration. @Jan: please correct me if i said something wrong @others: what is your view on this solution ? Bertrand
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |