All of lore.kernel.org
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: Alexander Graf <agraf@suse.de>
Cc: "<qemu-ppc@nongnu.org>" <qemu-ppc@nongnu.org>,
	"<qemu-devel@nongnu.org>" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [RFC ppc-next PATCH 6/6] kvm/openpic: in-kernel mpic support
Date: Thu, 21 Mar 2013 16:59:48 -0500	[thread overview]
Message-ID: <1363903188.31522.25@snotra> (raw)
In-Reply-To: <9F6E8CFD-3DDF-4B9E-A741-20E7FE7BC856@suse.de> (from agraf@suse.de on Thu Mar 21 16:29:02 2013)

On 03/21/2013 04:29:02 PM, Alexander Graf wrote:
> 
> 
> Am 21.03.2013 um 21:50 schrieb Scott Wood <scottwood@freescale.com>:
> 
> > On 03/21/2013 03:41:19 AM, Alexander Graf wrote:
> >> Can't all the stuff above here just simply go into the qdev init  
> function?
> >
> > Not if you want platform code to be able to fall back to a QEMU  
> mpic if an in-kernel mpic is unavailable.
> 
> Do we want that? We used to have a default like that in qemu-kvm back  
> in the day. That was very confusing, as people started to report that  
> their VMs turned out to be really slow.
> 
> I think we should not have fallback code. It makes things easier and  
> more obvious. The default should just depend on the host's  
> capabilities.

I don't follow.  What is the difference between "falling back" and  
"depending on the host's capabilities"?  Either we can create an  
in-kernel MPIC or we can't.  We could use KVM_CREATE_DEVICE_TEST to see  
if the device type is supported separately from actually creating it,  
but I don't see what that would accomplish other than adding more code.

> >> >     /* MPIC */
> >> >     mpic = g_new(qemu_irq, 256);
> >> > -    dev = qdev_create(NULL, "openpic");
> >> > -    qdev_prop_set_uint32(dev, "nb_cpus", smp_cpus);
> >> > -    qdev_prop_set_uint32(dev, "model", params->mpic_version);
> >> > +
> >> > +    if (kvm_irqchip_wanted()) {
> >> > +        dev = kvm_openpic_create(NULL, params->mpic_version);
> >> This really should be just a
> >>    dev = qdev_create(NULL, kvm_irqchip_wanted() ? "kvm-openpic" :  
> "openpic");
> >> The logic whether an in-kernel irqchip is available belongs into  
> the default setting of kvm_irqchip_wanted.
> >
> > That is exactly what I was trying to avoid by introducing  
> kvm_irqchip_wanted.  We're no longer testing some vague generic  
> irqchip capability, but the presence of a specific type of device  
> (and version thereof).  How would the code that sets  
> kvm_irqchip_wanted know what to test for?
> 
> Then move the default code into the board file and check for the  
> in-kernel mpic cap.

I'm not quite sure what you mean by "the default code" -- if you mean  
the part that makes the decision whether to fall back or error out,  
that's already in board code.

-Scott

  reply	other threads:[~2013-03-21 22:00 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1360823521-32306-1-git-send-email-scottwood@freescale.com>
     [not found] ` <1360823521-32306-3-git-send-email-scottwood@freescale.com>
2013-03-21  8:30   ` [Qemu-devel] [RFC ppc-next PATCH 2/6] kvm: hw/kvm is not x86-specific Alexander Graf
     [not found] ` <1360823521-32306-4-git-send-email-scottwood@freescale.com>
2013-03-21  8:31   ` [Qemu-devel] [RFC ppc-next PATCH 3/6] memory: add memory_region_to_address() Alexander Graf
2013-03-21 10:53     ` Peter Maydell
2013-03-21 10:59       ` Alexander Graf
2013-03-21 11:01         ` Peter Maydell
2013-03-21 11:05           ` Alexander Graf
2013-03-21 11:09             ` Peter Maydell
2013-03-21 11:14               ` Alexander Graf
2013-03-21 11:22                 ` Peter Maydell
2013-03-21 11:29                   ` Alexander Graf
2013-03-21 11:32                     ` Peter Maydell
2013-03-21 11:38                       ` Alexander Graf
2013-03-21 11:44                         ` Peter Maydell
2013-03-21 11:49                           ` Alexander Graf
2013-03-21 11:51                             ` [Qemu-devel] [Qemu-ppc] " Alexander Graf
2013-03-21 22:43                               ` Scott Wood
2013-03-22 13:08                                 ` Peter Maydell
2013-03-22 22:05                                   ` Scott Wood
2013-03-23 11:24                                     ` Peter Maydell
2013-03-25 18:23                                       ` Scott Wood
2013-03-21 11:53                             ` [Qemu-devel] " Peter Maydell
     [not found] ` <1360823521-32306-6-git-send-email-scottwood@freescale.com>
2013-03-21  8:34   ` [Qemu-devel] [RFC ppc-next PATCH 5/6] kvm: export result of irqchip config check Alexander Graf
2013-03-21  8:45     ` Jan Kiszka
2013-03-21  8:50       ` Alexander Graf
     [not found] ` <1360823521-32306-7-git-send-email-scottwood@freescale.com>
2013-03-21  8:41   ` [Qemu-devel] [RFC ppc-next PATCH 6/6] kvm/openpic: in-kernel mpic support Alexander Graf
2013-03-21 20:50     ` Scott Wood
2013-03-21 21:29       ` Alexander Graf
2013-03-21 21:59         ` Scott Wood [this message]
2013-03-21 23:45           ` Alexander Graf
2013-03-22 22:51             ` Scott Wood
2013-04-15 23:19 ` [Qemu-devel] [RFC PATCH v2 0/6] kvm/openpic: in-kernel irqchip Scott Wood
2013-04-15 23:19   ` [Qemu-devel] [RFC PATCH v2 1/6] kvm: update linux-headers Scott Wood
2013-04-15 23:19   ` [Qemu-devel] [RFC PATCH v2 2/6] kvm: use hw/kvm/Makefile.objs consistently for all relevant architectures Scott Wood
2013-04-15 23:19   ` [Qemu-devel] [RFC PATCH v2 3/6] memory: add memory_region_to_address() Scott Wood
2013-04-16  8:25     ` Peter Maydell
2013-04-17  0:10       ` Scott Wood
2013-04-17  9:14         ` Peter Maydell
2013-04-15 23:19   ` [Qemu-devel] [RFC PATCH v2 4/6] openpic: factor out some common defines into openpic.h Scott Wood
2013-04-15 23:19   ` [Qemu-devel] [RFC PATCH v2 5/6] PPC: e500: factor out mpic init code Scott Wood
2013-04-15 23:19   ` [Qemu-devel] [RFC PATCH v2 6/6] kvm/openpic: in-kernel mpic support Scott Wood

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=1363903188.31522.25@snotra \
    --to=scottwood@freescale.com \
    --cc=agraf@suse.de \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.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.