[SeaBIOS] [Qemu-devel] [PATCH 2/2] Get system state configuration from QEMU and patcth DSDT with it.

[Kevin O'Connor]

On Wed, May 16, 2012 at 04:46:57PM +0300, Gleb Natapov wrote:
> On Tue, May 15, 2012 at 07:18:10PM -0400, Kevin O'Connor wrote:
> > As in the other recent discussion, a struct can be built by the BIOS
> > and a pointer passed in via a dynamic SSDT (eg, BDAT).  Whatever data
> > is needed can then be passed in via that struct.
> > 
> 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.

If it has to be patched anyway (eg, to remove _S3 definition) then,
yes, might as well do the whole thing via patching.

> > Why?  Just put the definitions in ssdp_pcihp.dsl instead of
> > acpi-dsdt.dsl - there's no real difference.
> Fine by me. I verified and Windows/Linux can cope with _Sx definitions
> being in SSDT. If we a going to move all the code that needs patching to
> this file may we should rename it to something like ssdp_dynamic.dsl?

Agreed.

BTW, what's the background to the requirement to configure the Sx
sleep levels?  As we've discussed some time back, I'm leery of
building custom QEMU->SeaBIOS interfaces just so SeaBIOS can then
reencode into ACPI for the OS.

> > The QEMU_CFG_FILE_DIR is just a list of "names" and "sizes" for each
> > "port".  There's no fundamental limitation to the interface.  If QEMU
> > has a limit, we should just fix that.
> >
> Each time Seabios wants to read a file it need to iterate over all/most
> existing files.

Yes.  I'd like to change this in SeaBIOS by caching the "romfile"
entries.  It would actually simplify the code.

>I can understand advantage of using files for code that
> is shared between coreboot and qemu since files is what real HW uses,
> but for QEMU internal code it is just overhead for the sake of it.

The real benefit to using QEMU_CFG_FILE_DIR is that we can get at the
size of the data in a standard way.  Without that, each new data item
has to have its own fw_cfg reading code which is just a waste.

>I do
> not have strong fillings about this issue. If you think that files is
> the only way forward may be you should communicate this to QEMU and put
> a comment in hw/fw_cfg.h explaining that and increasing FW_CFG_FILE_SLOTS
> to some ridiculously large value.

I've been meaning to build a qemu patch that puts all fw_cfg entries
in QEMU_CFG_FILE_DIR.  (There's no harm in making names for the
existing hard-coded fw_cfg "ports".)  Unfortunately, I haven't gotten
around to it.  :-(

-Kevin