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