Re: [PATCH][4.15] x86/shadow: suppress "fast fault path" optimization without reserved bits

From: Ian Jackson <iwj@xenproject.org>
To: Jan Beulich <jbeulich@suse.com>
Cc: "Tim Deegan" <tim@xen.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"George Dunlap" <george.dunlap@citrix.com>,
	"Wei Liu" <wl@xen.org>, "Roger Pau Monné" <roger.pau@citrix.com>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>
Subject: Re: [PATCH][4.15] x86/shadow: suppress "fast fault path" optimization without reserved bits
Date: Tue, 2 Mar 2021 12:32:28 +0000	[thread overview]
Message-ID: <24638.12380.286845.325678@mariner.uk.xensource.com> (raw)
In-Reply-To: <fb542bda-d25e-b286-400f-dfb54bfe55d4@suse.com>

Jan Beulich writes ("Re: [PATCH][4.15] x86/shadow: suppress "fast fault path" optimization without reserved bits"):
> On 01.03.2021 18:43, Ian Jackson wrote:
> > Andrew Cooper writes ("Re: [PATCH][4.15] x86/shadow: suppress "fast fault path" optimization without reserved bits"):
> >> On 01/03/2021 17:30, Ian Jackson wrote:
> >>> I'm afraid I don't follow enough of the background here to have an
> >>> opinion right now.  Can someone explain to me the risks (and,
> >>> correspondingly, upsides) of the options ?  Sorry to be dim, I don't
> >>> seem to be firing on all cylinders today.
> 
> I guess the risk from that patch is no different than that from the
> patch here. It would merely improve performance for guests using
> very large GFNs for memory areas needing emulation by qemu, which I
> suppose originally wasn't expected to be happening in the first place.
> In fact if I would have been certain there are no side effects of the
> too narrow GFN representation used so far, I would probably have
> submitted the patches in reverse order, or even folded them.

I am still confused.  You are saying that the existing patch, and your
proposal that you are wanting me to have an opinion on, have the same
risk.  So, what aspect of the proposed other way of fixing it might
make me say no ?

> >> Without this fix, some combinations of "normal" VM settings will
> >> malfunction.
> > 
> > Thanks for that explanation.
> > 
> > I don't quite follow how that relates to Jan's comment
> > 
> >  >> Will cook a patch, albeit I guess I'll keep as many of the bits set
> >  >> as possible, while still being able to encode a full-40-bit GFN.
> >  >>
> >  >> Ian - I don't suppose you'd consider this a reasonable thing to do
> >  >> for 4.15? It would allow limiting the negative (performance) effect
> >  >> the change here has.
> > 
> > I already gave a release-ack for the original patch.  I think Jan is
> > asking for a release-ack for a different way of fixing the problem.
> 
> Well, I was trying to negotiate whether I should submit that patch
> for 4.15, or only later for 4.16.

Precisely.  I was hoping someone (eg Andy) would be able to help
explain to me why this is a good idea, or a bad idea.

Ian.