Re: [Qemu-devel] Secondary VGA passthrough not working, hitting linux kernel's pci_fixup_video

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

On Wed, Jan 15, 2014 at 11:35:29PM +0100, Sander Eikelenboom wrote:
> 
> Wednesday, January 15, 2014, 11:10:35 PM, you wrote:
> 
> > [+cc Jesse, David]
> 
> > On Wed, Jan 15, 2014 at 12:19 PM, Sander Eikelenboom
> > <linux@eikelenboom.it> wrote:
> 
> >>>> >>         I understood there is no bridge for a VGA device in your virtual machine.
> >>>> >>         Your emulator for the bridge control register is odd.
> >>>>
> >>>> > That seems beside the point as there's no bridge here.
> >>>>
> >>>> >>         I guess your virtual machine ignore "PCI-to-PCI Bridge Architecture
> >>>> >>         Specification".
> >>>>
> >>>> > Since there's no pci to pci bridge in this VM, why would this
> >>>> > specification apply?
> 
> > My guess is that he is referring to sec 11.3.2 "Initialization
> > Algorithm" of the Bridge spec r1.2.  That section (and chapter 24 of
> > MindShare PCI System Architecture, 4th edition) apparently reiterate a
> > discovery algorithm that appears in the PCI spec.  I can't find that
> > algorithm in the 3.0 or 2.3 PCI specs, but I assume it was in an
> > earlier version.
> 
> >> Yes i have done some more reading .. from what i could find from PCI specs there is nothing in there
> >> that points to a specific boot vga card.
> >> The whole agp/pci/pcie bios selection is ACPI stuff .. but if all the cards are of the same type ..
> >> there is no way to specify a specific card.
> 
> > The algorithm from sec 11.3.2 *does* seem to give a way to identify a
> > specific boot VGA card, i.e., the first one you find when searching in
> > the specified order.  There are still issues, such as the fact that
> > 11.3.2 says to start at PCI bus 0, while MindShare says to start with
> > the largest bus number.
> 
> > Also, sec 12.1.2.1 of the Bridge spec says the PCI_COMMAND memory and
> > I/O enables do apply to VGA accesses, so that is potentially a way to
> > make two sibling VGA devices work, e.g., by toggling those bits to
> > control which device you want to talk to.  I also assume that when
> > identifying the "boot VGA device," one might ignore devices that the
> > BIOS left disabled.
> 
> >>>> >> 00:03.0 VGA compatible controller [0300]: Cirrus Logic GD 5446 [1013:00b8] (prog-if 00 [VGA controller])
> >>>> >>         Subsystem: Red Hat, Inc Device [1af4:1100]
> >>>> >>         Physical Slot: 3
> >>>> >>         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
> >>>> >>         Region 0: Memory at f0000000 (32-bit, prefetchable) [size=32M]
> >>>> >>         Region 1: Memory at f30b0000 (32-bit, non-prefetchable) [size=4K]
> >>>> >>         Expansion ROM at f30a0000 [disabled] [size=64K]
> >>>> >>
> >>>> >> 00:05.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI Turks [Radeon HD 6570] [1002:6759] (prog-if 00 [VGA controller])
> >>>> >>         Subsystem: PC Partner Limited Device [174b:e193]
> >>>> >>         Physical Slot: 5
> >>>> >>         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
> >>>> >>         Interrupt: pin A routed to IRQ 81
> >>>> >>         Region 0: Memory at e0000000 (64-bit, prefetchable) [size=256M]
> >>>> >>         Region 2: Memory at f3060000 (64-bit, non-prefetchable) [size=128K]
> >>>> >>         Region 4: I/O ports at c100 [size=256]
> >>>> >>         Expansion ROM at f3080000 [disabled] [size=128K]
> 
> > I am not an expert on this legacy stuff, but this looks like an
> > illegal configuration to me: both 00:03.0 and 00:05.0 claim to be VGA
> > controllers and both have I/O+ and Mem+, so I would think both would
> > respond to the legacy VGA addresses.
> 
> Me neither .. and all pci specs seem to be paywalled, but apart from this
> the current code of pci_video_fixup doesn't check for  I/O+ and Mem+ either.

I see this:
        pci_read_config_word(pdev, PCI_COMMAND, &config);
        if (config & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) {
                pdev->resource[PCI_ROM_RESOURCE].flags |= IORESOURCE_ROM_SHADOW;

so it checks that either IO+ or Mem+ is enabled.


> Ánd as i pointed out the kernel at this point has already set vga_default_device (from what it seems
> indeed the first device from a ordered scan). So if there should be a better detection mechanism i think it should
> be implemented at what sets vga_default_device .. and pci_fixup_video should adhere to that (or fixup if it's still not set)
> And that's essentially what the patch does .. and it also doesn't seem to alter anything for the cases it was implemented for
> of i read the comment and commit messages correctly.
> 
> --
> Sander