Re: [PATCH] KVM: x86: restrict maximal physical address

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




This check is correct.

However, I wonder if there is any way for user space to query this property?

Do you mean boot_cpu_data.x86_phys_bits?
Userspace can execute CPUID instruction and read the value; QEMU does.

Thanks, good to know. I remember that on s390x we explicitly decided to query the maximum address from KVM (KVM_S390_VM_MEM_LIMIT_SIZE) for two reasons. One of them was "just because our CPU supports it doesn't mean KVM supports it". Just like with all CPU features.

However, this applies only for configuring hardware virtualization. The value that is exposed to the guest comes from the cpu model (with s390x cpu model support). So it will also not change during migration.

But if this will never be relevant for x86 (KVM will always support host x86_phys_bits), fine.


On s390x, there is a kvm capability to export this information to user
space. So QEMU can fail (e.g. migration) with a nice error message about
missing hardware support.

(most probably we still want to block this case, as migration will seem to
work but than simply fail due to missing hardware support I guess). Maybe
there is also already a nice check in QEMU that I am not yet aware of :)

This patch is bad.  It would break QEMU on all old machines, because
QEMU sets 40 by default.

Not sure if rounding that value down (so it is at least consistent in KVM) makes sense (and documenting this behavior "may be rounded down"). And then implementing appropriate checks in QEMU (if not already present).


Heh, QEMU doesn't check at all -- it even allows migration with
"host-phys-bits" feature and will happily change phys-bits when
migrating to another machine.


Either migrate that value (hmmm... ) or glue it to a command line parameter, so it won't change while migrating. E.g.

- cpu models (if this value was always the same for a CPU generation - no expert on x86 cpu models). - "-cpu maxmem..." - could be a fit when thinking about "maximum VM size == max phys bits for our guest". But depends how this value is actually interpreted by guests.

--

David
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux