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 <[email protected]> >> Signed-off-by: Jan Beulich <[email protected]> > Acked-by: Tim Deegan <[email protected]> > > 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). Address widths vary greatly between generations and SKUs, so blocking migrate on a MAXPHYSADDR mismatch isn't a viable option. VM migration works in practice because native kernels don't tend to use reserved bit optimisations in the first place. The fault lies with Xen. We're using a property of reserved bit behaviour which was always going to change eventually, and can't be levelled in common heterogeneous scenarios. ~Andrew
