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