On Thu, Jan 11, 2024 at 12:02 PM Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > > On Thu, Jan 11, 2024 at 5:25 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > > It is unusual to assign a huge RAM to guest, but passthrough a device also may trigger > > > this issue which we have met, i.e. alloc memslot for the 64bit BAR which can set > > > bits[51:48]. BIOS can control the BAR address, e.g. seabios moved 64bit pci window > > > to end of address space by using advertised physical bits[1]. > > > > Drat. Do you know if these CPUs are going to be productized? We'll still need > > something in KVM either way, but whether or not the problems are more or less > > limited to funky software setups might influence how we address this. > > Wait, we do have an API for guest physical address size. It's > KVM_GET_SUPPORTED_CPUID2: the # of bits is in leaf 0x80000008, bits > 0:7 of EAX. In fact that leaf is what firmware uses to place the BARs. > So it just needs to be adjusted for VMX in __do_cpuid_func, and looked > up in selftests. We've discussed this. The only *supported* value for guest.MAXPHYADDR is host.MAXPHYADDR. If EPT doesn't also support that value, then the only *supported* configuration is shadow paging. If someone wants to run with scissors, that's fine, but don't abuse KVM_GET_SUPPORTED_CPUID2 to return an *unsupported* configuration.
