Re: [PATCH 01/16] KVM-HDR: register KVM basic header infrastructure
From: Avi Kivity
Date: Thu Jan 27 2011 - 07:31:40 EST
On 01/26/2011 07:49 PM, Glauber Costa wrote:
> If type becomes implied based on the MSR number, you'd get the best of
> both worlds, no?
> I do think advertising features in CPUID is nicer than writing to an MSR
> and then checking for an ack in the memory region.
Fine. But back to the point, I think the reasoning here is that I see
all those areas as just a single feature, shared data.
That's not a feature. kvmclock and apf are features.
> I do think having a standard mechanism for small regions of shared
> memory between the hypervisor and guest is a reasonable thing to do.
Through what I am proposing, or through something else? (including
I'd like to keep the current way of doing things. Helpers in the guest
and host to consolidate code are fine, but there's no need to impact the
kvm_register_feature_msr(u32 msr, u64 alignment, struct cpuid_bit
*feature, int (*callback)(struct kvm_vcpu *vcpu, u64 value))
will install handlers for wrmsr and rdmsr, and declare the msr for
save/restore, tell the wrmsr handler which cpuid bit allows exposing the
msr, and registers a callback for when the msr is written by the guest.
error compiling committee.c: too many arguments to function
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/