Re: Graphics card pass-through working with two pass pci-initialization

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

 



  Hi,

If I am not mistaken then the graphics card needs 2 bars, one with 256MB
and one with 128K. The sound card then needs 1 bar with 16K of PCI memory.
How big is the PCI memory with seabios?

Some comments on that (apply to the kraxel.q35 branch):

You can add this to the qemu command line to get the seabios debug output printed:

qemu $usualoptions -chardev stdio,id=seabios \
     -device isa-debugcon,iobase=0x402,chardev=seabios

Then you can watch seabios assigning memory.

The ordering of the cards should not matter at all, the hacked bios does a two-pass scan to order the memory bars by size and pack them nicely.

Finding holes in address space for pci bars is not perfect yet. Right now it has sort-of hardcoded the 0xf0000000 -> 0xfec00000 range and tries to fit in stuff there. If it fails to fit in everything it tries again but leaves out devices which are not essential for boot. If it still fails the error isn't handled yet. For q35 this is a non-starter as it uses the e0000000 -> efffffff range for pci mmconfig. For the piix it doesn't hurt for now as the area above 0xe0000000 is unused. And the address space up to 0xe0000000 is used for guest ram only, thus it depends on the amount of memory you assign to the guest whenever this area is free or not. If you assign -- say -- 2G to your guest everything above 0x80000000 is free.

With your setup (256m + 128m + small stuff) I'd expect seabios place the 256m bar @ 0xe0000000, the 128m bar @ 0xf0000000 and all the small ones above 0xf8000000. It will maps only the devices which it thinks are essential for boot (i.e. skip the sound card).

At the end of the day I want the pci address space allocation code have no hard-coded addresses in there but use the e820 table instead to figure how big the address space hole is. Maybe even use multiple holes (i.e. also use the memory below mmconfig @ 0xe0000000 with q35).

cheers,
  Gerd
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux