qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Secondary VGA passthrough not working, hitting linux ke


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] Secondary VGA passthrough not working, hitting linux kernel's pci_fixup_video
Date: Thu, 16 Jan 2014 00:25:20 +0200

On Wed, Jan 15, 2014 at 03:10:35PM -0700, Bjorn Helgaas 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.

It's not in 2.2 either apparently.

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

The spec merely says walk topology top to bottom.
If there are no bridges there's a single bus and it
does not seem to apply.

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

Absolutely. But the disabled device can't be used at all.
Sander here wants to use one device in VGA mode, and the
second device in non VGA mode.

This can only work if the non VGA one is behind bridge, or
if second device doesn't use the legacy VGA addresses.

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

Also both are on the same bus so no bridge filters these.

-- 
MST



reply via email to

[Prev in Thread] Current Thread [Next in Thread]