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

[Ian Jackson <iwj@xxxxxxxxxxxxxx>]

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:
> > Jan Beulich writes ("Re: [PATCH][4.15] x86/shadow: suppress "fast fault 
> > path" optimization without reserved bits"):
> >> On 26.02.2021 18:07, Tim Deegan wrote:
> >>> Yes, I think it could be reduced to use just one reserved address bit.
> >>> IIRC we just used such a large mask so the magic entries would be
> >>> really obvious in debugging, and there was no need to support arbitrary
> >>> address widths for emulated devices.
> >> 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'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.
> 
> Intel IceLake CPUs (imminently coming out) have no reserved bits in
> pagetable entries, so these "optimisations" malfunction.  It is
> definitely an issue for HVM Shadow guests, and possibly migration of PV
> guests (I can never remember whether we use the GNP fastpath on PV or not).
> 
> It is arguably wrong that we ever depended on reserved behaviour.
> 
> I've got a (not-yet-upsteamed) XTF test which can comprehensively test
> this.  I'll find some time to give them a spin and give a T-by.
> 
> 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.

Ian.