qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Andrea Bolognani <abologna@redhat.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: "Cédric Le Goater" <clg@kaod.org>,
	qemu-ppc@nongnu.org, qemu-devel@nongnu.org,
	"Benjamin Herrenschmidt" <benh@kernel.crashing.org>,
	"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] ppc/pnv: Add model for Power8 PHB3 PCIe Host bridge
Date: Thu, 28 Jun 2018 10:00:49 +0200	[thread overview]
Message-ID: <b84cc6b91f3af188c3eece0713f849031c5256c8.camel@redhat.com> (raw)
In-Reply-To: <20180628035909.GE23134@umbus.fritz.box>

On Thu, 2018-06-28 at 13:59 +1000, David Gibson wrote:
> On Wed, Jun 27, 2018 at 12:22:31PM +0200, Andrea Bolognani wrote:
> > On Tue, 2018-06-26 at 19:02 +0200, Cédric Le Goater wrote:
> > > I didn't follow that discussion but this is "another" kind of PHB.
> > > This one models the baremetal controller as found on OpenPOWER and
> > > IBM Power machines. pSeries has a virtual PHB.
> > 
> > I understand that, and of course libvirt will need to learn about
> > this new type of PHB and make sure both pSeries and PowerNV guests
> > get the correct one assigned to them.
> 
> Hmm.. does it?  I would have thought pnv could act more like x86, in
> that libvirt doesn't attempt to create PHBs at all and just use the
> ones that are built in.

AFAIK x86 guests have a single PHB and additional ones cannot be
created in any way, which means we don't have to do any additional
second-guessing when assigning IDs to additional PCI controllers.

> Though, come to that, I wouldn't think pnv support for libvirt would
> be much of a priority anyway.  The machine type is still very much in
> flux, and it's designed primarily for testing and development, not
> "real world" usage.

Can you *guarantee* that someone won't ask for PowerNV support in
libvirt at some point? Because if you can't (and I don't think you
can ;) then this is still a valuable conversation to have.

> > What I meant is that pSeries guests get a single PHB by default,
> > with additional ones being instantiable through -device; this is
> > also consistent with how PCI controllers are added to other guest
> > types including pc, q35 and aarch64/virt, so it would be really
> > nice if PowerNV behaved the same way.
> 
> Well.. sure.. but it doesn't.  pSeries is a virtual platform, so we
> have a reasonable amount of flexibility to define it as we want.
> PowerNV is an emulation of existing hardware which has a specific
> behaviour which we need to match.

Sure, that's something to keep in mind.

But the thing is, you still need to have *some* flexibility in
the number of PHBs, since there is variation among real Power8
and Power9 chips; in the current incarnation, that flexibility
is provided by the num_phbs parameter, which is an entirely new
interface that's exclusive to PowerNV.

What I'm suggesting is that the same amount of flexibility is
offered through a standard interface, namely -device, instead.

-- 
Andrea Bolognani / Red Hat / Virtualization

  reply	other threads:[~2018-06-28  8:01 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-26 13:59 [Qemu-devel] [PATCH] ppc/pnv: Add model for Power8 PHB3 PCIe Host bridge Cédric Le Goater
2018-06-26 15:57 ` Andrea Bolognani
2018-06-26 17:02   ` Cédric Le Goater
2018-06-27 10:22     ` Andrea Bolognani
2018-06-27 12:18       ` Cédric Le Goater
2018-06-27 19:48         ` Cédric Le Goater
2018-06-28  3:59       ` David Gibson
2018-06-28  8:00         ` Andrea Bolognani [this message]
2018-06-28 10:04           ` Cédric Le Goater
2018-06-28 11:40             ` Andrea Bolognani
2018-06-28 12:20               ` Cédric Le Goater
2018-06-28 13:05               ` Cédric Le Goater
2018-06-28 12:14           ` Benjamin Herrenschmidt
2018-07-02  6:23             ` David Gibson
2018-06-26 22:21   ` Benjamin Herrenschmidt
2018-06-27  0:35 ` Michael S. Tsirkin
2018-06-27  1:38   ` Benjamin Herrenschmidt
2018-06-27  2:39     ` Michael S. Tsirkin
2018-06-27  7:28     ` David Gibson
2018-06-27  7:46       ` Cédric Le Goater
2018-06-27  8:41         ` Benjamin Herrenschmidt
2018-06-27 10:40           ` Andrea Bolognani
2018-06-27 13:03             ` Cédric Le Goater
2018-06-27 11:51           ` Cédric Le Goater

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=b84cc6b91f3af188c3eece0713f849031c5256c8.camel@redhat.com \
    --to=abologna@redhat.com \
    --cc=benh@kernel.crashing.org \
    --cc=clg@kaod.org \
    --cc=david@gibson.dropbear.id.au \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=mst@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).