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 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

--
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