Huang Ying wrote:
On Sat, 2009-04-11 at 20:04 +0800, Avi Kivity wrote:
Why not always allocate it on vcpu setup?
Because the MCE bank number is not fixed, it is based on mcg_cap from
user space.
Right, but we can allocate the maximum number, no? it's a fairly small
amount of memory.
OK. If you are OK with 8k extra memory usage.
Let's make it 64 banks like Andi suggests. Return the number in the
KVM_CHECK_EXTENSION call (we do the same for memory slots) so userspace
can adjust.
kvm does feature negotiation (really, feature advertising) using
KVM_CAP_... and KVM_CHECK_EXTENSION. So there's no need for this.
It is not only feature advertising, but also something like CPUID. Based
on CPU type specified in command line (qemu -cpu ?), different mcg_cap
can be used to determine number of MCE banks and various features of MCE
(MCG_CTL_P, MCG_TES_P, MCG_CMCI, etc) for specified CPU type. With KVM
feature advertising, we can only check whether MCE simulation is
supported, but can not set parameters of MCE simulation.
Maybe this interface can be changed to KVM_SET_MSRS, with
MSR_IA32_MCG_CAP be set by kvm-qemu. But MSR_IA32_MCG_CAP is read-only
by spec, and current interface can not distinguishes between MSR set
from guest system and MSR setup from kvm-qemu. I think there should be
other read-only MSRs need to be setup during guest system
creation/setup. How about add a interface such as KVM_SETUP_MSRS to
setup the value of read-only MSRs?
Then we would need to tell which read-only MSRs are setup writeable and
which aren't...
I'm okay with an ioctl to setup MCE, but just make sure userspace has
all the information to know what the kernel can do rather than the
try-and-see-if-it-works approach. We can publish this information via
KVM_CAP things, or via another ioctl (see KVM_GET_SUPPORTED_CPUID2 for
an example).
--
error compiling committee.c: too many arguments to function
--
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
