On 9/1/22 08:07, Xiaoyao Li wrote: > On 8/31/2022 8:50 PM, Gerd Hoffmann wrote: >> When the guest (firmware specifically) knows how big >> the address space actually is it can be used better. >> >> Some more background: >> https://bugzilla.redhat.com/show_bug.cgi?id=2084533 > > QEMU enables host-phys-bits for "-cpu host/max" in > host_cpu_max_instance_init(); No, in host_cpu_max_instance_init the default for host-phys-bits is set to on. You can still get the phys bits adjusted if you set the property to on manually for other cpu models. > > I think the problem is for all the named CPU model, that they don't have > phys_bits defined. Thus they all have "cpu->phys-bits == 0", which leads > to cpu->phys_bits = TCG_PHYS_ADDR_BITS (36 for 32-bits build and 40 for > 64-bits build) > > Anyway, IMO, guest including guest firmware, should always consult from > CPUID leaf 0x80000008 for physical address length. Tt is the duty of > userspace VMM, here QEMU, to ensure VM's host physical address length > not exceeding host's. If userspace VMM cannot ensure this, guest is > likely hitting problem. > >> This is a RfC series exposes the information via cpuid. >> >> take care, >> Gerd >> >> Gerd Hoffmann (2): >> [hack] reserve bit KVM_HINTS_HOST_PHYS_BITS >> [RfC] expose host-phys-bits to guest >> >> include/standard-headers/asm-x86/kvm_para.h | 3 ++- >> target/i386/cpu.h | 3 --- >> hw/i386/microvm.c | 6 +++++- >> target/i386/cpu.c | 3 +-- >> target/i386/host-cpu.c | 4 +++- >> target/i386/kvm/kvm.c | 1 + >> 6 files changed, 12 insertions(+), 8 deletions(-) >> > >
