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

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

 



On Mon, May 30, 2011 at 09:34:07AM +0200, Gerd Hoffmann wrote:
>   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).

0xE0000000 is hard-coded in the DSDT for both piix and q35 as below.
If the range is determined dynamically, the area also needs to be
updated somehow dynamically.

...
            Name (_CRS, ResourceTemplate ()
...
                DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, NonCacheable, ReadWrite,
                    0x00000000,         // Address Space Granularity
                    0xE0000000,         // Address Range Minimum
                    0xFEBFFFFF,         // Address Range Maximum 
                    0x00000000,         // Address Translation Offset
                    0x1EC00000,         // Address Length
                    ,, , AddressRangeMemory, TypeStatic)


thanks,
-- 
yamahata
--
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