All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: Marcel Apfelbaum <marcel@redhat.com>,
	ehabkost@redhat.com, thuth@redhat.com, lvivier@redhat.com,
	qemu-ppc@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC] pxb: Restrict to x86
Date: Mon, 9 Jan 2017 03:58:03 +0200	[thread overview]
Message-ID: <20170109035746-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20170108234824.GC12515@umbus.fritz.box>

On Mon, Jan 09, 2017 at 10:48:24AM +1100, David Gibson wrote:
> On Sun, Jan 08, 2017 at 10:17:12AM +0200, Marcel Apfelbaum wrote:
> > On 01/06/2017 09:41 PM, Michael S. Tsirkin wrote:
> > > On Fri, Jan 06, 2017 at 08:13:11AM +0200, Marcel Apfelbaum wrote:
> > > > On 01/06/2017 07:04 AM, David Gibson wrote:
> > > > > The PCI Expander Bridge (PXB) device is essentially a hack to allow
> > > > > different PCIe devices to be assigned to different NUMA nodes on x86.  Each
> > > > > PXB is sort-of a separate PCI host bridge, except that its config space
> > > > > is shared with the config space of the main PCI host bridge, rather than
> > > > > being independent.
> > > > > 
> > > > 
> > > > Hi David,
> > > > 
> > > > > This is only necessary if the platform doesn't (easily) allow truly
> > > > > independent PCI host bridges.  AFAIK that's just x86.
> > > > > 
> > > > 
> > > > Indeed, it is possible to support independent PCI host bridges on x86 by
> > > > using a separate MMCONFIG space for each one and enable separate PCI domains.
> > > > We simply didn't need this until now, but maybe will be implemented it in the future.
> > > 
> > > In fact I would say that's the cleanest way to do this on q35.
> > 
> > Message received :)
> 
> Just so I'm clear, these last two comments are essentially suggesting
> a follow up cleanup on x86, rather than suggesting a different
> approach for non-PC platforms, yes?
> 
> If there are no objections to my original patch do you want to take it
> through your tree Michael, or should I take it through mine?
> 
> -- 
> 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



Go ahead and take it through  yours pls.

Acked-by: Michael S. Tsirkin <mst@redhat.com>

  reply	other threads:[~2017-01-09  1:58 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-06  5:04 [Qemu-devel] [RFC] pxb: Restrict to x86 David Gibson
2017-01-06  6:13 ` Marcel Apfelbaum
2017-01-06  6:26   ` Marcel Apfelbaum
2017-01-06 19:41   ` Michael S. Tsirkin
2017-01-08  8:17     ` Marcel Apfelbaum
2017-01-08 23:48       ` David Gibson
2017-01-09  1:58         ` Michael S. Tsirkin [this message]
2017-01-09  2:54           ` David Gibson

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=20170109035746-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=ehabkost@redhat.com \
    --cc=lvivier@redhat.com \
    --cc=marcel@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=thuth@redhat.com \
    /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.