From: Stefano Stabellini <firstname.lastname@example.org> To: Bertrand Marquis <Bertrand.Marquis@arm.com> Cc: "Stefano Stabellini" <email@example.com>, "Julien Grall" <firstname.lastname@example.org>, "Wei Liu" <email@example.com>, "Andrew Cooper" <firstname.lastname@example.org>, "Ian Jackson" <email@example.com>, "George Dunlap" <firstname.lastname@example.org>, "Jan Beulich" <email@example.com>, Xen-devel <firstname.lastname@example.org>, nd <email@example.com>, "Volodymyr Babchuk" <Volodymyr_Babchuk@epam.com>, "Roger Pau Monné" <firstname.lastname@example.org> Subject: Re: [PATCH v2] xen/arm: Convert runstate address during hypcall Date: Fri, 31 Jul 2020 16:03:42 -0700 (PDT) Message-ID: <alpine.DEB.2.21.2007310935350.1767@sstabellini-ThinkPad-T480s> (raw) In-Reply-To: <E39531EE-0265-4387-813D-22A57CD3F67B@arm.com> On Fri, 31 Jul 2020, Bertrand Marquis wrote: > > On 31 Jul 2020, at 12:18, Jan Beulich <email@example.com> 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. Please let's avoid "slippery slope" arguments (https://en.wikipedia.org/wiki/Slippery_slope) We shouldn't consider this instance as the first in a long series of bad decisions on hypercall compatibility. Each new case, if there will be any, will have to be considered based on its own merits. Also, let's keep in mind that there have been no other cases in the last 8 years. (I would like to repeat my support for hypercall ABI compatibility.) I would also kindly ask not to put the discussion on a "conceptual" level: there is no way to fix all guests and also keep compatibility. From a conceptual point of view, it is already game over :-) > 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 ? Having options to turn on or off the new behavior could be good-to-have if we find a guest that actually requires the old behavior. Today we don't know of any such cases. We have strong reasons to believe that there aren't any on ARM (see Julien's explanation in regards to the temporary invalid mappings.) In fact, it is one of the factors that led us to think this patch is the right approach. That said, I am also OK with adding such a parameter now, but we need to choose the default value carefully. We need the new behavior as default on ARM because we need the fix to work for all guests. I don't think we want to explain how you always need to set config_foobar otherwise things don't work. It has to work out of the box. It would be nice if we had the same default on x86 too, although I understand if Jan and Andrew don't want to make the same change on x86, at least initially.
prev parent reply index Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-07-28 15:52 Bertrand Marquis 2020-07-28 19:04 ` Stefano Stabellini 2020-07-29 6:47 ` Bertrand Marquis 2020-07-28 19:54 ` Jan Beulich 2020-07-29 7:08 ` Bertrand Marquis 2020-07-29 18:41 ` Jan Beulich 2020-07-30 1:30 ` Stefano Stabellini 2020-07-31 6:39 ` Jan Beulich 2020-07-31 10:12 ` Julien Grall 2020-07-31 10:18 ` Jan Beulich 2020-07-31 14:36 ` Bertrand Marquis 2020-07-31 23:03 ` Stefano Stabellini [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=alpine.DEB.2.21.2007310935350.1767@sstabellini-ThinkPad-T480s \ --firstname.lastname@example.org \ --cc=Bertrand.Marquis@arm.com \ --cc=Volodymyr_Babchuk@epam.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Xen-Devel Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/xen-devel/0 xen-devel/git/0.git git clone --mirror https://lore.kernel.org/xen-devel/1 xen-devel/git/1.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 xen-devel xen-devel/ https://lore.kernel.org/xen-devel \ firstname.lastname@example.org email@example.com public-inbox-index xen-devel Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.xenproject.lists.xen-devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git