From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH 3/3] Add the paravirtualization CPUID entry to QEMU (v2) Date: Mon, 27 Aug 2007 15:04:50 -0500 Message-ID: <1188245090.21322.2.camel@squirrel> References: <1188243723984-git-send-email-aliguori@us.ibm.com> <11882437243411-git-send-email-aliguori@us.ibm.com> <11882437252643-git-send-email-aliguori@us.ibm.com> <1188243725114-git-send-email-aliguori@us.ibm.com> <46D32BF5.2030904@qumranet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Avi Kivity Return-path: In-Reply-To: <46D32BF5.2030904-atKUWr5tajBWk0Htik3J/w@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org On Mon, 2007-08-27 at 22:54 +0300, Avi Kivity wrote: > Anthony Liguori wrote: > > This adds a CPUID entry for the paravirtualization feature bitmap. We can do > > this unconditionally because the guest requires that both the feature CPUID > > entry and the signature CPUID entry exists to enable paravirtualization. > > > > This means that guest will never enable paravirtualization if either userspace > > or kernelspace doesn't support paravirtualization. > > > > Signed-off-by: Anthony Liguori > > > > diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c > > index 491c32c..1c93388 100644 > > --- a/qemu/qemu-kvm.c > > +++ b/qemu/qemu-kvm.c > > @@ -1103,12 +1103,18 @@ static void do_cpuid_ent(struct kvm_cpuid_entry *e, uint32_t function, > > int kvm_qemu_init_env(CPUState *cenv) > > { > > struct kvm_cpuid_entry cpuid_ent[100]; > > + struct kvm_cpuid_entry *pv_features; > > int cpuid_nent = 0; > > CPUState copy; > > uint32_t i, limit; > > > > copy = *cenv; > > > > + pv_features = &cpuid_ent[cpuid_nent++]; > > + memset(pv_features, 0, sizeof(*pv_features)); > > + pv_features->function = 0x40000003; > > + pv_features->eax = (1 << KVM_PARA_FEATURE_NOP_IO_DELAY); > > + > > copy.regs[R_EAX] = 0; > > qemu_kvm_cpuid_on_env(©); > > limit = copy.regs[R_EAX]; > > > > Shouldn't we query kvm here to see if the feature is needed? I don't think so. At the moment, PIO goes to QEMU so QEMU is really the only one that should be making that decision. > I imagine I/O delay is never needed unless we passthrough a device, > which this qemu doesn't support, but it would be nice to set a good > example for the future. In this particular case, it would be a bad example since the kernel isn't the one that ought to be making the decision. I suspect PCI pass-through should be initiated in QEMU anyway so it still will be the one making the decision. However, if you apply these patches before my flight levels tomorrow, I can send out the MMU optimization patches that include a proper example of how to query kernel-space ;-) Regards, Anthony Liguori ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/