From: "Michael S. Tsirkin" <mst@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
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>,
"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:20:42 +0200 [thread overview]
Message-ID: <20130131222042.GA17928@redhat.com> (raw)
In-Reply-To: <1359667310.7958.10.camel@ul30vt.home>
On Thu, Jan 31, 2013 at 02:21:50PM -0700, Alex Williamson wrote:
> On Thu, 2013-01-31 at 23:11 +0200, Michael S. Tsirkin wrote:
> > On Thu, Jan 31, 2013 at 09:34:03AM -0700, Alex Williamson wrote:
> > >
> > > On Thu, 2013-01-31 at 12:49 +0200, Michael S. Tsirkin wrote:
> > > > On Wed, Jan 30, 2013 at 04:28:30PM -0700, Alex Williamson wrote:
> > > > > On Thu, 2013-01-31 at 10:02 +1100, Benjamin Herrenschmidt wrote:
> > > > > > On Thu, 2013-01-31 at 00:49 +0200, Michael S. Tsirkin wrote:
> > > > > > > > In practice they do (VGA at least)
> > > > > > > >
> > > > > > > > >From a SW modelling standpoint, I don't think it's worth
> > > > > > > differentiating
> > > > > > > > PCI and PCIE.
> > > > > > > >
> > > > > > > > Cheers,
> > > > > > > > Ben.
> > > > > > >
> > > > > > > Interesting.
> > > > > > > Do you have such hardware? Could you please dump
> > > > > > > the output of lspci -vv?
> > > > > >
> > > > > > Any ATI or nVidia card still supports hard decoding of VGA regions for
> > > > > > the sake of legacy operating systems and BIOSes :-) I don't know about
> > > > > > Intel but I suppose it's the same.
> > > > >
> > > > > For example:
> > > > >
> > > > > -[0000:00]-+-00.0 Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (external gfx0 p
> > > > > +-04.0-[02]--+-00.0 Advanced Micro Devices [AMD] nee ATI Cedar PRO [Radeon HD 5450/6350]
> > > > >
> > > > > 00:04.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (PCI express gpp port D) (prog-if 00 [Normal decode])
> > > > > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
> > > > > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> > > > > Latency: 0, Cache Line Size: 64 bytes
> > > > > Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
> > > > > I/O behind bridge: 0000c000-0000cfff
> > > > > Memory behind bridge: fd100000-fd1fffff
> > > > > Prefetchable memory behind bridge: 00000000d0000000-00000000dfffffff
> > > > > Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
> > > > > BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- >Reset- FastB2B-
> > > > > ^^^^
> > > > > VGA+ (VGA Enable) indicates positive decode of 0x3b0 - 0x3bb, 0x3c0 -
> > > > > 0x3df, and 0xa0000 - 0xbfff. Device 2:00.0 of course doesn't report
> > > > > these "ISA" ranges as they're implicit in the VGA class code.
> > > >
> > > > OK but this appears behind a bridge. So the bridge configuration tells
> > > > the root complex where to send accesses to the VGA.
> > > >
> > > > But qemu currently puts devices directly on root bus.
> > > >
> > > > And as far as I can tell when we present devices directly on bus 0, we
> > > > pretend these are integrated in the root complex. 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.
> > > >
> > > > Luckily guests do not seem to be worried as long as we use ACPI.
> > >
> > > Yes, in fact I just figured out last night that Windows is unhappy with
> > > assigned PCI devices on bus 0 that claim to be an endpoint in their PCIe
> > > capability rather than an integrated endpoint. We'll need to do extra
> > > mangling of the PCIe capability to massage it into the guest visible
> > > topology.
> >
> > For now, just put you device behind an express bridge. This breaks acpi
> > hotplug for now, but I'm looking into hotplug with bridges anyway.
>
> We have the problem in both directions though, Endpoints that should be
> Integrated Endpoints and Integrated Endpoints that should be Endpoints.
> So I think we need to mangle the type.
>
> > If you really need it I can give you a hack for hotplug too.
> >
> > Of course express does not allow hotplug of root complex parts
> > but happens to work because we use ACPI.
>
> That's a little odd.
>
> > > Section 1.3.2.3 of the 3.0 spec says integrated endpoints must not
> > > require I/O resources claimed through BAR(s). VGA skirts around this by
> > > not having the legacy resources claimed by BARs, but instead being
> > > implicit.
> >
> > Aha. I missed this point.
> >
> > > Are there other sections restricting legacy I/O?
> >
> > One other interesting things is that VGA enable bit (for bridge control
> > register) does not appear in express spec at all.
>
> Yep, but it appears on hardware.
>
> > > It's common that a plugin VGA card sits behind a root port where the
> > > bridge registers tell us about VGA routing,
> > > but integrated VGA devices
> > > are often on bus 0 though, here's an example:
> > >
> > > -[0000:00]-+-00.0 Intel Corporation 2nd Generation Core Processor Family DRAM Controller
> > > +-02.0 Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller
> > >
> > > Often these systems will disable the integrated graphics when a plugin
> > > graphics is installed below a root port. I'm not sure how the system
> > > knows to route VGA to the integrated device vs the root port otherwise.
> >
> > I am guessing it disables the integrated graphics?
> >
> > > Here's a more interesting example:
> > >
> > > -+-[0000:01]-+-00.0 NVIDIA Corporation GT218 [GeForce G210M]
> > > | \-00.1 NVIDIA Corporation High Definition Audio Controller
> > > \-[0000:00]-+-00.0 Intel Corporation Mobile 4 Series Chipset Memory Controller Hub
> > > +-01.0 Intel Corporation Mobile 4 Series Chipset PCI Express Graphics Port
> > >
> > > This system seems to have two host bridges with VGA behind each of them.
> > > There's no bridge to control VGA routing, so I don't know how the
> > > selection is done.
> >
> > Is IO space disabled for the inactive card? Maybe that is how.
>
> The card has BAR defined I/O space resources. My guess is that VGA is
> just statically routed to the integrated device and the secondary works
> only in non-legacy mode until the BIOS switch is flipped, the integrated
> device is hidden and VGA is switched to static routing for the nvidia
> device. I suppose that means I'll never be able to assign the nvidia to
> a guest, at least not with any kind of legacy VGA support. Thanks,
>
> Alex
Can you check device control for both before and after the switch.
--
MST
next prev parent reply other threads:[~2013-01-31 22:20 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 [this message]
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
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=20130131222042.GA17928@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=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.