Re: [PATCH 01/16] KVM-HDR: register KVM basic header infrastructure

[Avi Kivity]

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.

e.g.

    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/