On 10/07/20 18:02, Eduardo Habkost wrote: > On Fri, Jul 10, 2020 at 09:22:42AM +0200, Paolo Bonzini wrote: >> On 09/07/20 21:13, Eduardo Habkost wrote: >>>> Doesn't this require intercepting MOV-to-CR3 when the guest is in PAE >>>> mode, so that the hypervisor can validate the high bits in the PDPTEs? >>> If the fix has additional overhead, is the additional overhead >>> bad enough to warrant making it optional? Most existing >>> GUEST_MAXPHYADDR < HOST_MAXPHYADDR guests already work today >>> without the fix. >> >> The problematic case is when host maxphyaddr is 52. That case wouldn't >> work at all without the fix. > > What can QEMU do to do differentiate "can't work at all without > the fix" from "not the best idea, but will probably work"? Blocking guest_maxphyaddr < host_maxphyaddr if maxphyaddr==52 would be a good start. However it would block the default configuration on IceLake processors (which is why Mohammed looked at this thing in the first place). Paolo
