On 01.03.2021 18:34, Andrew Cooper wrote:
> 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).
We do for not-present entries afaict, while (I guess obviously) we
don't for MMIO ones.
Jan
