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.
