All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Andrea Bolognani <abologna@redhat.com>
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>, 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: Wed, 23 Nov 2016 16:00:49 +1100	[thread overview]
Message-ID: <20161123050049.GD17795@umbus.fritz.box> (raw)
In-Reply-To: <1479457042.1391.11.camel@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2862 bytes --]

On Fri, Nov 18, 2016 at 09:17:22AM +0100, Andrea Bolognani wrote:
> On Thu, 2016-11-17 at 13:02 +1100, Alexey Kardashevskiy wrote:
> > > That said, considering that a big part of the PCI address
> > > allocation logic is based off whether the specific machine
> > > type exposes a legay PCI Root Bus or a PCI Express Root Bus,
> > > libvirt will need a way to be able to tell which one is which.
> > > 
> > > Version checks are pretty much out of the question, as they
> > > fail as soon as downstream releases enter the picture. A
> > > few ways we could deal with the situation:
> > > 
> > >   1) switch to PCI Express on newer machine types, and
> > >      expose some sort of capability through QMP so that
> > >      libvirt can know about the switch
> 
> [...]
> > > Option 1) would break horribly with existing libvirt
> > > versions, and so would Option 2) if we default to using
> > 
> > How exactly 1) will break libvirt? Migrating from pseries-2.7 to
> > pseries-2.8 does not work anyway, and machines are allowed to behave
> > different from version to version, what distinct difference will using
> > "pseries-pcie-X.Y" make?
> 
> Existing libvirt versions assume that pseries guests have
> a legacy PCI root bus, and will base their PCI address
> allocation / PCI topology decisions on that fact: they
> will, for example, use legacy PCI bridges.

Um.. yeah.. trouble is libvirt's PCI-E address allocation probably
won't work for spapr PCI-E either, because of the weird PCI-E without
root complex presentation we get in PAPR.

> So if you used a new QEMU binary with a libvirt version
> that doesn't know about the change, new guests would end up
> using the wrong controllers. Existing guests would not be
> affected as they would stick with the older machine types,
> of course.
> 
> > I believe after we introduced the very first
> > pseries-pcie-X.Y, we will just stop adding new pseries-X.Y.
> 
> Isn't i440fx still being updated despite the fact that q35
> exists? Granted, there are a lot more differences between
> those two machine types than just the root bus type.

Right, there are heaps of differences between i440fx and q35, and
reasons to keep both updated.  For pseries we have neither the impetus
nor the resources to maintain two different machine type variant,
where the only difference is between legacy PCI and weirdly presented
PCI-E.

> Even if no newer pseries-x.y were to be added after
> introducing pseries-pcie, you could still easily create
> guests that use either root bus, so no loss in functionality.
> 
> -- 
> Andrea Bolognani / Red Hat / Virtualization
> 

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  parent reply	other threads:[~2016-11-23  5:14 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
2016-12-02  3:37                         ` David Gibson
2016-11-22 14:07                   ` [Qemu-devel] [libvirt] " Eric Blake
2016-11-23  5:00               ` David Gibson [this message]
2016-11-25 13:46                 ` [Qemu-devel] " 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=20161123050049.GD17795@umbus.fritz.box \
    --to=david@gibson.dropbear.id.au \
    --cc=abologna@redhat.com \
    --cc=aik@ozlabs.ru \
    --cc=alex.williamson@redhat.com \
    --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.