public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox