On Mon, Dec 18, 2023 at 6:51 PM Chao Gao <chao.gao@xxxxxxxxx> wrote: > > On Mon, Dec 18, 2023 at 07:13:27AM -0800, Sean Christopherson wrote: > >On Mon, Dec 18, 2023, Tao Su wrote: > >> When host doesn't support 5-level EPT, bits 51:48 of the guest physical > >> address must all be zero, otherwise an EPT violation always occurs and > >> current handler can't resolve this if the gpa is in RAM region. Hence, > >> instruction will keep being executed repeatedly, which causes infinite > >> EPT violation. > >> > >> Six KVM selftests are timeout due to this issue: > >> kvm:access_tracking_perf_test > >> kvm:demand_paging_test > >> kvm:dirty_log_test > >> kvm:dirty_log_perf_test > >> kvm:kvm_page_table_test > >> kvm:memslot_modification_stress_test > >> > >> The above selftests add a RAM region close to max_gfn, if host has 52 > >> physical bits but doesn't support 5-level EPT, these will trigger infinite > >> EPT violation when access the RAM region. > >> > >> Since current Intel CPUID doesn't report max guest physical bits like AMD, > >> introduce kvm_mmu_tdp_maxphyaddr() to limit guest physical bits when tdp is > >> enabled and report the max guest physical bits which is smaller than host. > >> > >> When guest physical bits is smaller than host, some GPA are illegal from > >> guest's perspective, but are still legal from hardware's perspective, > >> which should be trapped to inject #PF. Current KVM already has a parameter > >> allow_smaller_maxphyaddr to support the case when guest.MAXPHYADDR < > >> host.MAXPHYADDR, which is disabled by default when EPT is enabled, user > >> can enable it when loading kvm-intel module. When allow_smaller_maxphyaddr > >> is enabled and guest accesses an illegal address from guest's perspective, > >> KVM will utilize EPT violation and emulate the instruction to inject #PF > >> and determine #PF error code. > > > >No, fix the selftests, it's not KVM's responsibility to advertise the correct > >guest.MAXPHYADDR. > > In this case, host.MAXPHYADDR is 52 and EPT supports 4-level only thus can > translate up to 48 bits of GPA. There are a number of issues that KVM does not handle when guest.MAXPHYADDR < host.MAXPHYADDR. For starters, KVM doesn't raise a #GP in PAE mode when one of the address bits above guest.MAXPHYADDR is set in one of the PDPTRs. Honestly, I think KVM should just disable EPT if the EPT tables can't support the CPU's physical address width. > 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.
