From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:34468) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SUoRu-0004Bl-KO for qemu-devel@nongnu.org; Wed, 16 May 2012 20:20:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SUoRs-00071y-NB for qemu-devel@nongnu.org; Wed, 16 May 2012 20:20:10 -0400 Received: from mail-qc0-f173.google.com ([209.85.216.173]:33855) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SUoRs-0006zl-II for qemu-devel@nongnu.org; Wed, 16 May 2012 20:20:08 -0400 Received: by qcsc20 with SMTP id c20so1050051qcs.4 for ; Wed, 16 May 2012 17:20:06 -0700 (PDT) Date: Wed, 16 May 2012 20:20:05 -0400 From: Kevin O'Connor Message-ID: <20120517002005.GA19382@morn.localdomain> References: <1336998923-30144-1-git-send-email-gleb@redhat.com> <1336998923-30144-2-git-send-email-gleb@redhat.com> <20120515014319.GA21845@morn.localdomain> <20120515080605.GD32036@redhat.com> <20120515231810.GA674@morn.localdomain> <20120516134657.GU32036@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120516134657.GU32036@redhat.com> Subject: Re: [Qemu-devel] [PATCH 2/2] Get system state configuration from QEMU and patcth DSDT with it. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: seabios@seabios.org, qemu-devel@nongnu.org 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