All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <aliguori-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
To: Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [PATCH 3/3] Add the paravirtualization CPUID entry to QEMU (v2)
Date: Mon, 27 Aug 2007 15:04:50 -0500	[thread overview]
Message-ID: <1188245090.21322.2.camel@squirrel> (raw)
In-Reply-To: <46D32BF5.2030904-atKUWr5tajBWk0Htik3J/w@public.gmane.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 <aliguori-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
> >
> > 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(&copy);
> >      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/

  parent reply	other threads:[~2007-08-27 20:04 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-27 19:42 [PATCH 0/3] KVM paravirtualization framework (v2) Anthony Liguori
2007-08-27 19:42 ` [PATCH 1/3] Refactor hypercall infrastructure (v2) Anthony Liguori
2007-08-27 19:42   ` [PATCH 2/3] KVM paravirt-ops implementation (v2) Anthony Liguori
     [not found]     ` <11882437252643-git-send-email-aliguori-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2007-08-27 19:42       ` [PATCH 3/3] Add the paravirtualization CPUID entry to QEMU (v2) Anthony Liguori
     [not found]         ` <1188243725114-git-send-email-aliguori-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2007-08-27 19:54           ` Avi Kivity
     [not found]             ` <46D32BF5.2030904-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-08-27 20:04               ` Anthony Liguori [this message]
2007-08-27 19:42   ` [PATCH 2/3] KVM paravirt-ops implementation (v2) Anthony Liguori
2007-09-09 12:29 ` [kvm-devel] [PATCH 0/3] KVM paravirtualization framework (v2) Avi Kivity

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1188245090.21322.2.camel@squirrel \
    --to=aliguori-r/jw6+rmf7hqt0dzr+alfa@public.gmane.org \
    --cc=avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org \
    --cc=kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.