From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 01/16] KVM-HDR: register KVM basic header infrastructure Date: Thu, 27 Jan 2011 14:31:23 +0200 Message-ID: <4D41659B.1010706@redhat.com> References: <1295892397-11354-1-git-send-email-glommer@redhat.com> <1295892397-11354-2-git-send-email-glommer@redhat.com> <4D400045.2000405@redhat.com> <1296044013.15920.47.camel@mothafucka.localdomain> <4D4039CB.6060008@redhat.com> <1296056170.3591.14.camel@mothafucka.localdomain> <4D405853.6010003@codemonkey.ws> <1296064182.3591.30.camel@mothafucka.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Anthony Liguori , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, aliguori@us.ibm.com To: Glauber Costa Return-path: In-Reply-To: <1296064182.3591.30.camel@mothafucka.localdomain> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org 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