All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: "KVM devel mailing list" <kvm@vger.kernel.org>,
	"Juan Quintela" <quintela@redhat.com>,
	"Alexander Graf" <agraf@suse.de>,
	qemu-devel <qemu-devel@nongnu.org>,
	"Alex Williamson" <alex.williamson@redhat.com>,
	"Alon Levy" <alevy@redhat.com>,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	"Anthony Liguori" <anthony@codemonkey.ws>,
	qemu-ppc <qemu-ppc@nongnu.org>,
	"David Gibson" <david@gibson.dropbear.id.au>,
	"Andreas Färber" <afaerber@suse.de>,
	"Hervé Poussineau" <hpoussin@reactos.org>
Subject: Re: KVM call minutes 2013-01-29 - Port I/O
Date: Fri, 1 Feb 2013 00:28:19 +0200	[thread overview]
Message-ID: <20130131222818.GB17928@redhat.com> (raw)
In-Reply-To: <1359667353.15464.5.camel@pasglop>

On Fri, Feb 01, 2013 at 08:22:33AM +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2013-01-31 at 12:49 +0200, Michael S. Tsirkin wrote:
> 
> > OK but this appears behind a bridge.  So the bridge configuration tells
> > the root complex where to send accesses to the VGA.
> 
> Sort-of, again the root complex isn't "sending" anything targeted here.
> PCIe is point to point and any device is behind a bridge, real or
> virtual.

I think we are arguing about terminology here. root complex
has a virtual bridge for each port, presumably it examines bridge control
for each port to know which link to use for a VGA access.
I say presumably because VGA enable bit in bridge control
is not listed in spec (but as Alex says some real
hardware has it implemented).

> > But qemu currently puts devices directly on root bus.
> 
> Sure, because qemu doesn't specifically model PCIe but something "else"
> 
> > And as far as I can tell when we present devices directly on bus 0, we
> > pretend these are integrated in the root complex.
> 
> Right, it's a bit gross.
> 
> >  The spec seems to
> > say explicitly that root complex integrated devices should not use legacy
> > addresses or support hotplug. So I would be surprised if such one
> > appears in real world.
> 
> Sure but that doesn't change the fact that there's no point in treating
> things differently between PCI and PCIe for the sake of address range
> decoding. The high level model remains the same.

Yes, and it's not by chance.

> > Luckily guests do not seem to be worried as long as we use ACPI.
> 
> Right, it all just looks like PCI to the guest anyway and is mostly
> treated as such for the sake of routing and decoding (until you turn on
> ARI but that's a different can of worms).

Right, ARI only affects config cycles.

> > > BTW, I've been working on vfio-pci support of VGA assignment which makes
> > > use of the VGA arbiter in the host to manipulate the VGA Enable control
> > > register, allowing us to select which device to access.  The qemu side
> > > is simply registering memory regions for the VGA areas and expecting to
> > > be used with -vga none, but I'll adopt whatever strategy we choose for
> > > hard coded address range support.  Current base patches at the links
> > > below.  Thanks,
> > > 
> > > Alex
> > > 
> > > https://github.com/awilliam/qemu-vfio/commit/ea2befa59010a429dcf13c10dbccdf8b64e82fbd
> > > https://github.com/awilliam/linux-vfio/commit/bae182d929229cbf1eaeb01e5fad4f77f81a4c61
> 

  reply	other threads:[~2013-01-31 22:28 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-29 15:41 KVM call minutes 2013-01-29 Juan Quintela
2013-01-29 16:01 ` Paolo Bonzini
2013-01-29 16:47   ` Anthony Liguori
2013-01-29 17:36     ` Paolo Bonzini
2013-01-29 20:53 ` Alexander Graf
2013-01-29 21:39   ` Anthony Liguori
2013-01-30  7:02     ` What to do about non-qdevified devices? (was: KVM call minutes 2013-01-29) Markus Armbruster
2013-01-30  8:39       ` What to do about non-qdevified devices? Andreas Färber
2013-01-30 10:36       ` What to do about non-qdevified devices? (was: KVM call minutes 2013-01-29) Peter Maydell
2013-01-30 12:35         ` What to do about non-qdevified devices? Markus Armbruster
2013-01-30 13:44           ` [Qemu-devel] " Andreas Färber
2013-01-30 16:58             ` Paolo Bonzini
2013-01-30 17:14               ` [Qemu-devel] " Andreas Färber
2013-01-31 18:48             ` Markus Armbruster
2013-01-30 14:37           ` [Qemu-devel] " Anthony Liguori
2013-01-30 11:39 ` [Qemu-devel] KVM call minutes 2013-01-29 - Port I/O Andreas Färber
2013-01-30 11:48   ` Peter Maydell
2013-01-30 12:31     ` Michael S. Tsirkin
2013-01-30 13:24       ` [Qemu-devel] " Anthony Liguori
2013-01-30 14:11         ` Michael S. Tsirkin
2013-01-30 12:32     ` Alexander Graf
2013-01-30 13:09     ` Markus Armbruster
2013-01-30 15:08       ` [Qemu-devel] " Anthony Liguori
2013-01-30 17:55     ` Andreas Färber
2013-01-30 20:20       ` Michael S. Tsirkin
2013-01-30 20:33         ` [Qemu-devel] " Andreas Färber
2013-01-30 20:55           ` Michael S. Tsirkin
2013-01-30 13:59   ` [Qemu-devel] " Anthony Liguori
2013-01-30 21:05     ` Benjamin Herrenschmidt
2013-01-30 21:39       ` [Qemu-devel] " Anthony Liguori
2013-01-30 21:54         ` Benjamin Herrenschmidt
2013-01-30 22:20         ` Michael S. Tsirkin
2013-01-30 22:32           ` Benjamin Herrenschmidt
2013-01-30 22:49             ` Michael S. Tsirkin
2013-01-30 23:02               ` Benjamin Herrenschmidt
2013-01-30 23:28                 ` Alex Williamson
2013-01-31 10:49                   ` Michael S. Tsirkin
2013-01-31 16:34                     ` Alex Williamson
2013-01-31 21:11                       ` Michael S. Tsirkin
2013-01-31 21:21                         ` Alex Williamson
2013-01-31 22:20                           ` Michael S. Tsirkin
2013-01-31 21:44                       ` Benjamin Herrenschmidt
2013-01-31 22:37                         ` Michael S. Tsirkin
2013-01-31 23:25                         ` Alex Williamson
2013-01-31 21:22                     ` Benjamin Herrenschmidt
2013-01-31 22:28                       ` Michael S. Tsirkin [this message]
2013-01-30 15:45   ` [Qemu-devel] " Gerd Hoffmann
2013-01-30 16:33     ` Anthony Liguori
2013-01-30 16:54       ` Andreas Färber
2013-01-30 17:29         ` [Qemu-devel] " Anthony Liguori
2013-01-30 20:08           ` Michael S. Tsirkin
2013-01-30 20:19             ` Peter Maydell
2013-01-30 20:19           ` [Qemu-devel] " Andreas Färber
2013-01-30 21:07         ` Benjamin Herrenschmidt
2013-01-30 21:42           ` [Qemu-devel] " Anthony Liguori
2013-01-30 17:08       ` Paolo Bonzini
2013-01-30 21:08         ` Benjamin Herrenschmidt

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=20130131222818.GB17928@redhat.com \
    --to=mst@redhat.com \
    --cc=afaerber@suse.de \
    --cc=agraf@suse.de \
    --cc=alevy@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=benh@kernel.crashing.org \
    --cc=david@gibson.dropbear.id.au \
    --cc=hpoussin@reactos.org \
    --cc=kraxel@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=quintela@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.