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
