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

[Sander Eikelenboom]

Wednesday, January 15, 2014, 11:10:35 PM, you wrote:

> [+cc Jesse, David]

> On Wed, Jan 15, 2014 at 12:19 PM, Sander Eikelenboom
> <address@hidden> 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.

Á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