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

[Alexander Graf]

On 01.06.2011, at 13:13, Avi Kivity wrote:

> On 06/01/2011 12:56 PM, Alexander Graf wrote:
>> On 01.06.2011, at 09:30, Gerd Hoffmann wrote:
>> 
>> >   Hi,
>> >
>> >>  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)
>> >
>> >  Uhm, indeed.  I know next to nothing about ACPI though.  Ideas anyone how 
>> > this could be done?
>> 
>> We're facing similar issues on PPC. The equivalent of the DSDT there is the 
>> device tree, which is currently passed in as binary blob and slightly 
>> appended for dynamic configuration. I'd much rather like to see it fully 
>> generated inside of Qemu from all the information we have available there, 
>> so we don't run into consistency issues.
>> 
>> This will be even more required when we pass through SoC devices to the 
>> guest, which are not on a PCI bus. Without specifying them in the DT, the 
>> guest doesn't know about them. X86 has a similar issue. Take a look at the 
>> HPET for example. If you don't want an HPET inside the guest, the DSDT needs 
>> to be modified. So you need to change things at 2 places - the DSDT and Qemu.
>> 
>> I don't know how much work it would be to generate the DSDT dynamically from 
>> Qemu, but IMHO that's the sanest way to make things flexible. We could 
>> probably even extract most information from the Qdev tree.
>> 
> 
> Generating the DSDT dynamically is hard, but the DSDT itself is dynamic.  You 
> can make any function talk to the firmware configuration interface and return 
> results that depend on the information there.

Does that hold true for nodes as well? I thought you can only use 'functions' 
for specific elements?


Alex