On 07/27/2009 12:08 PM, Jan Kiszka wrote:
When I add feature reporting to cpuinfo, I just put highlight features there,
otherwise the VMX feature list would at least as long as CPU one.
That could become true. But the question is always what the highlights
are. Often this depends on the hypervisor as it may implement
workarounds for missing features differently (or not at all). So I'm
also for exposing feature information consistently.
I'd put everything in there. It's information that is often useful.
Even minor features can expose bugs in the hypervisor.
I have also suggested another field for virtualization feature for it, but
some concern again userspace tools raised.
For we got indeed quite a lot features, and would get more, would it better to
export the part of struct vmcs_config entries(that's pin_based_exec_ctrl,
cpu_based_exec_ctrl, and cpu_based_2nd_exec_ctrl) through
sys/module/kvm_intel/? Put every feature to cpuinfo seems not that necessary
for such a big list.
I don't think this information should only come from KVM. Consider you
didn't build it into some kernel but still want to find out what your
system is able to provide.
What about adding some dedicated /proc entry for CPU virtualization
features, say /proc/hvminfo?
The flags line is already very long, and already has some virt features,
so I see no problem extending it. If we don't want that. I'd prefer a
virtualization line in /proc/cpuinfo rather than a new file.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
--
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
