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
slight variations)

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 ABI.


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
Please read the FAQ at