On Wed, May 16, 2012 at 06:47:55PM +0200, Paolo Bonzini wrote:
> Il 16/05/2012 18:40, Gleb Natapov ha scritto:
> > On Wed, May 16, 2012 at 05:50:31PM +0200, Paolo Bonzini wrote:
> >> Il 16/05/2012 15:46, Gleb Natapov ha scritto:
> >>> I saw that, but I don't get why doing it this way instead of defining
> >>> the object in AML and patching it? I can define Name(S4VL, 0x2) and path
> >>> 0x2 to whatever QEMU wants me to use, or I can patch Package directly
> >>> like I did.
> >>>
> >>
> >> Can we build an SSDT that includes the contents of fw_cfg (e.g.
> >> FW_CFG_SIGNATURE at offset 0, FW_CFG_UUID at offset 4, FW_CFG_NOGRAPHIC
> >> at offset 16... the entry <-> offset mapping and the defaults would be
> >> part of SeaBIOS), and then read that data from normal DSDT methods?
> >
> > Kevin does not want to use offsets any more :) He wants to use files, so
> > this will not work for new entries.
>
> Then we can have:
> - a table in SeaBIOS with (filenames, expected length) pairs
> - an ACPI table with a list of offsets for each file (-1 if file not
> found or length < expected length), with the same indices as the
> previous table
> - and another blob with all the files concatenated
>
> The idea is the same, just pass the fw_cfg data to the DSDT and read it
> from there. As long as Windows and Linux can cope with the more complex
> AML, there is no need to do complicated patching IMO...
>
Why would we want to do that? We do not need 99% present of fw_cfg data
in AML. There are exactly two cases, that appeared recently, where we need
to patch AML according to fw_cfg and your proposal does not eliminate
patching in one of those cases anyway. Namely we need to patch out
_S3/_S4 from AML. You can't do that in AML itself.
> >>
> >> That would be similar to Gerd's patch, but without letting the OSPM use
> >> the real fw_cfg device.
> >>
> > Latest Gerd's patch does not use fw_cfg device.
>
> Yes, I meant the same as his first patch, not really the machanics of
> creating the BDAT.
>
> Paolo
--
Gleb.
