On Tue, Dec 19, 2023 at 07:26:00AM -0800, Sean Christopherson wrote: > On Tue, Dec 19, 2023, Chao Gao wrote: > > On Mon, Dec 18, 2023 at 07:40:11PM -0800, Jim Mattson wrote: > > >Honestly, I think KVM should just disable EPT if the EPT tables can't > > >support the CPU's physical address width. > > > > Yes, it is an option. > > But I prefer to allow admin to override this (i.e., admin still can enable EPT > > via module parameter) because those issues are not new and disabling EPT > > doesn't prevent QEMU from launching guests w/ smaller MAXPHYADDR. > > > > >> Here nothing visible to selftests or QEMU indicates that guest.MAXPHYADDR = 52 > > >> is invalid/incorrect. how can we say selftests are at fault and we should fix > > >> them? > > > > > >In this case, the CPU is at fault, and you should complain to the CPU vendor. > > > > Yeah, I agree with you and will check with related team inside Intel. > > I agree that the CPU is being weird, but this is technically an architecturally > legal configuration, and KVM has largely committed to supporting weird setups. > At some point we have to draw a line when things get too ridiculous, but I don't > think this particular oddity crosses into absurd territory. > > > My point was just this isn't a selftest issue because not all information is > > disclosed to the tests. > > Ah, right, EPT capabilities are in MSRs that userspace can't read. > > > And I am afraid KVM as L1 VMM may run into this situation, i.e., only 4-level > > EPT is supported but MAXPHYADDR is 52. So, KVM needs a fix anyway. > > Yes, but forcing emulation for a funky setup is not a good fix. KVM can simply > constrain the advertised MAXPHYADDR, no? GPA is controlled by guest, I.e., just install PTE in guest page table, and the GPAs beyond 48-bits always trigger EPT violation. If KVM does nothing, guest can’t get #PF when accessing >MAXPHYADDR, which is inconsistent with architectural behavior. But doing nothing is also an option because userspace doesn’t respect the reported value. Thanks, Tao
