Re: KVM call minutes 2013-01-29 - Port I/O

["Michael S. Tsirkin" <mst@redhat.com>]

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.

> 
> 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