[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 1/2][4.15?] x86/shadow: suppress "fast fault path" optimization when running virtualized
On 08.03.2021 14:47, Andrew Cooper wrote: > On 08/03/2021 09:25, Tim Deegan wrote: >> At 16:37 +0100 on 05 Mar (1614962224), Jan Beulich wrote: >>> We can't make correctness of our own behavior dependent upon a >>> hypervisor underneath us correctly telling us the true physical address >>> with hardware uses. Without knowing this, we can't be certain reserved >>> bit faults can actually be observed. Therefore, besides evaluating the >>> number of address bits when deciding whether to use the optimization, >>> also check whether we're running virtualized ourselves. >>> >>> Requested-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> >>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> >> Acked-by: Tim Deegan <tim@xxxxxxx> >> >> I would consider this to be a bug in the underlying hypervisor, but I >> agree than in practice it won't be safe to rely on it being correct. > > I'd argue against this being a hypervisor bug. If anything, it is a > weakness in how x86 virtualisation works. > > For booting on a single host, then yes - vMAXPHYSADDR really ought to be > the same as MAXPHYSADDR, and is what happens in the common case. > > For booting in a heterogeneous pool, the only safe value is the min of > MAXPHYSADDR across the resource pool. Anything higher, and the VM will > malfunction (get #PF[rsvd] for apparently-legal PTEs) on the smallest > pool member(s). Except that min isn't safe either - the guest may then expect reserved bit faults where none surface. Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |