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 kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
