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

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

[Alexander Graf]

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.


Alex

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

[Rudolf Marek]

Sorry I forgot to include all addresses.

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

Well I have written for coreboot a ACPI bytecode generator (check acpigen.c). 
Maybe moving to SeaBIOS+Coreboot would make sense? It has the PCI resource 
allocator and all already done.

Thanks,
Rudolf

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

[Avi Kivity]

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.

-- 
error compiling committee.c: too many arguments to function

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

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

[Avi Kivity]

On 06/01/2011 02:16 PM, Alexander Graf wrote:
> >>
> >
> >  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?

I believe that if you declare _CRS as a method, it should work (there 
are both "Name" and "Method" _CRSs in the DSDT currently).

-- 
error compiling committee.c: too many arguments to function

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

[Gerd Hoffmann]

On 06/01/11 12:20, Rudolf Marek wrote:
> Sorry I forgot to include all addresses.
>
>> 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.
>
> Well I have written for coreboot a ACPI bytecode generator (check
> acpigen.c). Maybe moving to SeaBIOS+Coreboot would make sense? It has
> the PCI resource allocator and all already done.

Probably makes more sense to move to qemu, then pass the tables to 
seabios as qemu knows which virtual hardware is requested by the user 
and thus is present and which isn't.

Having a brief look at the coreboot code it seems static stuff (compiled 
by iasl) and dynamic bits are combined into the final dsdt table, is 
that correct?

thanks,
   Gerd

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

[Rudolf Marek]

> Having a brief look at the coreboot code it seems static stuff (compiled by
> iasl) and dynamic bits are combined into the final dsdt table, is that correct?

Yes the dsdt is static, it has just external references to ssdt which is 
dynamically generated using the acpigen.

Acpigen can generate the packages, names and sometimes even bits of methods.

Thanks
Rudolf

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

[Kevin O'Connor]

On Wed, Jun 01, 2011 at 04:40:15PM +0200, Rudolf Marek wrote:
> >Having a brief look at the coreboot code it seems static stuff (compiled by
> >iasl) and dynamic bits are combined into the final dsdt table, is that correct?
> 
> Yes the dsdt is static, it has just external references to ssdt
> which is dynamically generated using the acpigen.
> 
> Acpigen can generate the packages, names and sometimes even bits of methods.

That's interesting.  SeaBIOS also has similar code - see
acpi.c:build_ssdt().

-Kevin

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

[Yushu Yao]

[-- Attachment #1: Type: text/plain, Size: 1441 bytes --]

Hi Folks,

Could anyone give me a 101 lesson on what is "two-pass PCI initialization"?

I tried some time ago to pass a LSI megaraid to a rhel5 guest, but the
initialization of the pci device inside the VM fails (because, I think, it
was already initialized in the host).

Just wondering could that be related? Have anyone tried passing a raid card
to the guest?

Thanks

_Yushu


+-------------------------------------------------+
| Yushu Yao
| Ph:1-510-486-4690
|
| Lawrence Berkeley National Lab
| Mailstop 50B-6222
| 1 Cyclotron Road
| Berkeley CA 94720-8147 - USA
+-------------------------------------------------+




On Wed, Jun 1, 2011 at 3:15 PM, Kevin O'Connor <kevin@koconnor.net> wrote:

> On Wed, Jun 01, 2011 at 04:40:15PM +0200, Rudolf Marek wrote:
> > >Having a brief look at the coreboot code it seems static stuff (compiled
> by
> > >iasl) and dynamic bits are combined into the final dsdt table, is that
> correct?
> >
> > Yes the dsdt is static, it has just external references to ssdt
> > which is dynamically generated using the acpigen.
> >
> > Acpigen can generate the packages, names and sometimes even bits of
> methods.
>
> That's interesting.  SeaBIOS also has similar code - see
> acpi.c:build_ssdt().
>
> -Kevin
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

[-- Attachment #2: Type: text/html, Size: 2115 bytes --]