All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Bolognani <abologna@redhat.com>
To: David Gibson <david@gibson.dropbear.id.au>,
	Alexey Kardashevskiy <aik@ozlabs.ru>
Cc: Greg Kurz <groug@kaod.org>, Paolo Bonzini <pbonzini@redhat.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	qemu-ppc@nongnu.org, qemu-devel@nongnu.org,
	libvir-list@redhat.com, Michael Roth <mdroth@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] [Qemu-ppc] [RFC PATCH qemu] spapr_pci: Create PCI-express root bus by default
Date: Fri, 25 Nov 2016 15:36:25 +0100	[thread overview]
Message-ID: <1480084585.4367.69.camel@redhat.com> (raw)
In-Reply-To: <20161123050214.GE17795@umbus.fritz.box>

On Wed, 2016-11-23 at 16:02 +1100, David Gibson wrote:
> > > The change from OHCI to XHCI only affected the *default* USB
> > > controller, which libvirt tries its best not to use anyway:
> > > instead, it will prefer to use '-M ...,usb=off' along with
> > > '-device ...' and set both the controller model and its PCI
> > > address explicitly, partially to shield its users from such
> > > changes in QEMU.
> > 
> > Ok. Always likes this approach really. We should start moving to this
> > direction with PHB - stop adding the default PHB at all when -nodefaults is
> > passed (or -machine pseries,pci=off ?) and let libvirt manage PHBs itself
> > (and provide another spapr-phb type like spapr-pcie-host-bridge or add a
> > "pcie_root_bus_type" property to the existing PHB type).
> > 
> > What will be wrong with this approach?
> 
> Hm, that's a good point.  If were removing the default PHB entirely,
> that I would consider a possible case for a new machine type.  Putting
> construction of the PHBs into libvirt's hand could make life simpler
> there.  Although it would make it a bit of a pain for people starting
> qemu by hand.
> 
> I think this option is worth some thought.

Note that libvirt always runs QEMU with -nodefaults, so we
could just remove the default PHB if that flag is present,
and leave it in if that's not the case.

The idea itself sounds good, but of course it will require
more work from the libvirt side than simply making the PCIe
machine type behave like q35 and mach-virt.

Moreover, we already have an RFE for supporting additional
PHBs, we could solve both issues in one fell swoop and have
the libvirt guest XML be a more faithful representation of
the actual virtual hardware, which is always a win in my
book.

That will be even more important if it turns out that the
rules for PCIe device assignment (eg. what device/controller
can be plugged into which slot) are different for PCIe PHBs
than they are for q35/mach-virt PCIe Root Bus. I've asked
for clarifications about this elsewhere in the thread.

-- 
Andrea Bolognani / Red Hat / Virtualization

  reply	other threads:[~2016-11-25 14:36 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-28  7:56 [Qemu-devel] [RFC PATCH qemu] spapr_pci: Create PCI-express root bus by default Alexey Kardashevskiy
2016-10-28 10:07 ` [Qemu-devel] [Qemu-ppc] " Greg Kurz
2016-10-31  2:53   ` David Gibson
2016-10-31  4:10     ` Alexey Kardashevskiy
2016-11-01  2:46       ` David Gibson
2016-11-15 14:02         ` Andrea Bolognani
2016-11-17  2:02           ` Alexey Kardashevskiy
2016-11-18  6:11             ` David Gibson
2016-11-18  8:17             ` Andrea Bolognani
2016-11-21  2:12               ` Alexey Kardashevskiy
2016-11-21 13:08                 ` Andrea Bolognani
2016-11-22  2:26                   ` Alexey Kardashevskiy
2016-11-23  5:02                     ` David Gibson
2016-11-25 14:36                       ` Andrea Bolognani [this message]
2016-12-02  3:37                         ` David Gibson
2016-11-22 14:07                   ` [Qemu-devel] [libvirt] " Eric Blake
2016-11-23  5:00               ` [Qemu-devel] " David Gibson
2016-11-25 13:46                 ` Andrea Bolognani
2016-12-02  4:18                   ` David Gibson
2016-12-02  5:17                     ` Benjamin Herrenschmidt
2016-12-02  5:50                       ` David Gibson
2016-12-02 21:41                         ` Benjamin Herrenschmidt
2016-12-03  1:02                           ` Alexey Kardashevskiy
2016-12-05 19:06                     ` [Qemu-devel] [libvirt] " Laine Stump
2016-12-05 20:54                     ` Laine Stump
2016-12-07  3:34                       ` David Gibson
2016-12-06 17:30                     ` [Qemu-devel] " Andrea Bolognani
2016-12-07  4:11                       ` David Gibson
2016-12-07 16:42                         ` Andrea Bolognani
2016-12-13 12:25                           ` Marcel Apfelbaum
2016-12-13 13:15                             ` Greg Kurz
2016-12-13 15:15                             ` Benjamin Herrenschmidt
2016-12-14  2:48                               ` David Gibson
2016-12-14 12:02                               ` Marcel Apfelbaum
2016-12-14  2:46                             ` David Gibson
2016-12-14 18:26                               ` Marcel Apfelbaum
2016-12-15 21:59                                 ` Benjamin Herrenschmidt
2016-12-19 17:39                                 ` Andrea Bolognani

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=1480084585.4367.69.camel@redhat.com \
    --to=abologna@redhat.com \
    --cc=aik@ozlabs.ru \
    --cc=alex.williamson@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=groug@kaod.org \
    --cc=libvir-list@redhat.com \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=pbonzini@redhat.com \
    --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.