On Mon, Dec 18, 2023 at 07:23:01AM -0800, Sean Christopherson wrote: >On Mon, Dec 18, 2023, Tao Su wrote: >> With 4-level EPT, bits 51:48 of the guest physical address must all >> be zero; otherwise, an EPT violation always occurs, which is an unexpected >> VM exit in KVM currently. >> >> Even though KVM advertises the max physical bits to guest, guest may >> ignore MAXPHYADDR in CPUID and set a bigger physical bits to KVM. >> Rejecting invalid guest physical bits on KVM side is a choice, but it will >> break current KVM ABI, e.g., current QEMU ignores the physical bits >> advertised by KVM and uses host physical bits as guest physical bits by >> default when using '-cpu host', although we would like to send a patch to >> QEMU, it will still cause backward compatibility issues. >> >> For GPA that can't be translated by EPT but within host.MAXPHYADDR, >> emulation should be the best choice since KVM will inject #PF for the >> invalid GPA in guest's perspective and try to emulate the instructions >> which minimizes the impact on guests as much as possible. > >NAK. allow_smaller_maxphyaddr is a bit of a mess and in IMO was a mistake, but >at least there was reasonable motivation for trying to support guests with a small >MAXPHYADDR. Fudging around a QEMU bug is not good enough justification, especially >since the odds of a hack in KVM fully working are slim to none. The changelog is a little misleading. Even if there is no QEMU "bug" and QEMU sets guest.MAXPHYADDR to 48 correctly, guest __can__ set up CR3 page table to access GPAs with bits of 51:48 set. In this case, KVM still gets EPT violation and needs to inject #PF to the guest (by emulating the instruction).
