|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] xen pci and vga passthrough + option roms ... finally ... SUCCES
Hi Konrad,
Finally .. and i was searching in the complete wrong direction for the whole
time ...
red herring is the understatement of the year ... red whale would do it ..
It wasn't Xen, Seabios, Qemu ... but the guest kernel.
Which now makes sense with my recollection that secondary passthrough with ATI
cards used to work with Xen
with some expiriments i had done but laid aside for some time.
And the fact that trying older Xen versions failed to get a similar setup
working again
(because i kept trying newer .. not older guest kernels in those tests).
What is getting triggered is the pci_fixup_video (in arch/x86/pci/fixup.c)
below.
From dmesg:
[ 2.545728] pci 0000:00:00.0: calling quirk_natoma+0x0/0x40
[ 2.545730] pci 0000:00:00.0: Limiting direct PCI/PCI transfers
[ 2.558998] pci 0000:00:00.0: calling quirk_passive_release+0x0/0x90
[ 2.559121] pci 0000:00:01.0: PIIX3: Enabling Passive Release
[ 2.572412] pci 0000:00:01.0: calling quirk_isa_dma_hangs+0x0/0x40
[ 2.572415] pci 0000:00:01.0: Activating ISA DMA hang workarounds
[ 2.586527] pci 0000:00:03.0: calling pci_fixup_video+0x0/0xd0
[ 2.586609] pci 0000:00:03.0: Boot video device
[ 2.586696] pci 0000:00:05.0: calling pci_fixup_video+0x0/0xd0
[ 2.586827] pci 0000:00:05.0: Boot video device
[ 2.586928] pci 0000:00:06.0: calling quirk_e100_interrupt+0x0/0x1c0
So although there is a boot video device recognized already (the emulated one
with bfd 00:03.0)
it also applies the quirk to the secondary GPU which is now also marked as boot
device (passed through device with bfd 00:05.0)
which seems to be wrong.
I will go further with Dave Airlie for now .. see where that goes, will keep
you posted.
--
Sander
/*
* Fixup to mark boot BIOS video selected by BIOS before it changes
*
* From information provided by "Jon Smirl" <jonsmirl@xxxxxxxxx>
*
* The standard boot ROM sequence for an x86 machine uses the BIOS
* to select an initial video card for boot display. This boot video
* card will have it's BIOS copied to C0000 in system RAM.
* IORESOURCE_ROM_SHADOW is used to associate the boot video
* card with this copy. On laptops this copy has to be used since
* the main ROM may be compressed or combined with another image.
* See pci_map_rom() for use of this flag. IORESOURCE_ROM_SHADOW
* is marked here since the boot video device will be the only enabled
* video device at this point.
*/
static void pci_fixup_video(struct pci_dev *pdev)
{
struct pci_dev *bridge;
struct pci_bus *bus;
u16 config;
return;
/* Is VGA routed to us? */
bus = pdev->bus;
while (bus) {
bridge = bus->self;
/*
* From information provided by
* "David Miller" <davem@xxxxxxxxxxxxx>
* The bridge control register is valid for PCI header
* type BRIDGE, or CARDBUS. Host to PCI controllers use
* PCI header type NORMAL.
*/
if (bridge
&& ((bridge->hdr_type == PCI_HEADER_TYPE_BRIDGE)
|| (bridge->hdr_type == PCI_HEADER_TYPE_CARDBUS))) {
pci_read_config_word(bridge, PCI_BRIDGE_CONTROL,
&config);
if (!(config & PCI_BRIDGE_CTL_VGA))
return;
}
bus = bus->parent;
}
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;
dev_printk(KERN_DEBUG, &pdev->dev, "Boot video device\n");
if (!vga_default_device())
vga_set_default_device(pdev);
}
}
DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_ANY_ID, PCI_ANY_ID,
PCI_CLASS_DISPLAY_VGA, 8, pci_fixup_video);
Friday, January 10, 2014, 10:51:03 PM, you wrote:
> Hi Konrad,
> I'm starting a new thread .. since i'm essentially trying to start over from
> scratch.
> (shoot i forgot to include xen-devel on the first mail ...)
> - Xen-unstable the latest and greatest
> - Linux 3.13-rc7 as dom0 and guest kernel
> - Qemu-xen
> - Some patches (vga="none", enableing qemu debug, fixing builderrors when
> enabling qemu debug)
> I'm now first trying to replicate you :-) (don't worry .. it won't hurt :p),
> i'm using an intel NIC now (found one laying around and it has a rom.
> and after it was flashed .. it even has valid rom content :-) )
> Now the first experiment is to see if the sequence "echo 1 > rom; cat rom >
> romfile.bin; echo 0 > rom;" works.
> - Running Xen, on dom0, NIC owned by e1000e: dumping the rom works
> - Running Xen, on dom0, NIC owned by pciback: dumping the rom FAILS, kernel
> gives "cat: rom: Input/output error"
> - Running Xen, in a HVM guest, NIC passedthrough: dumping the rom works,
> contents are the same as under dom0
> The failure with pciback is perhaps because the device wasn't initialized on
> boot because it was seized by pciback.
> So generally speaking the rombar of pci devices is correctly passed through
> and can be dumped.
> So it indeed appears to be a VGA passthrough specific issue.
> This was on my intel machine, but unfortunately that one has an IGD that
> shares it's pci-e lanes with the only pcie x16 slot,
> so will put the NIC in my AMD machine .. and verify if it works there and
> then continue with the VGA card.
> Now trying on the AMD machine:
> NIC:
> - Running Xen, on dom0, NIC owned by e1000e: dumping the rom works
> - Running Xen, on dom0, NIC owned by pciback: dumping the rom FAILS, kernel
> gives "cat: rom: Input/output error"
> - Running Xen, in a HVM guest, NIC passedthrough: dumping the rom works,
> contents are the same as under dom0
> VGA card:
> - Running Xen, on dom0, VGA card owned by radeon: dumping the rom works
> - Running Xen, on dom0, VGA card owned by nothing (due to setting nomodeset):
> dumping the rom FAILS, kernel gives "cat: rom: Input/output error"
> - Running Xen, on dom0, VGA card owned by pciback: dumping the rom FAILS,
> kernel gives "cat: rom: Input/output error"
> - Running Xen, in a HVM guest, VGA card passedthrough: dumping the rom works,
> contents are DIFFERENT from dom0, i get the BOCHS VGAbios
> Prelimanary conclusions:
> - Passing through the rombar from a NIC works
> - Passing through the rombar from a VGA card doesn't work out of the box.
> - the sequence "echo 1 > rom; cat rom > romfile.bin; echo 0 > rom;" works but
> seems to rely on a loaded and working driver and is thus not very reliable
> for testing
> so i need to dust of my arithmatic and use /dev/kmem and dd.
> - So Anthony is probably right .. something is playing tricks with the rombar
> when it's VGA class, even if it's the secondary card in the Guest.
> --
> Sander
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |