From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Namlr-0000Jv-M9 for qemu-devel@nongnu.org; Fri, 29 Jan 2010 04:04:07 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Namln-0000HE-MZ for qemu-devel@nongnu.org; Fri, 29 Jan 2010 04:04:07 -0500 Received: from [199.232.76.173] (port=56396 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Namln-0000H0-5a for qemu-devel@nongnu.org; Fri, 29 Jan 2010 04:04:03 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51276) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Namlm-0006nC-Fy for qemu-devel@nongnu.org; Fri, 29 Jan 2010 04:04:02 -0500 Message-ID: <4B62A47B.5070807@redhat.com> Date: Fri, 29 Jan 2010 10:03:55 +0100 From: Jes Sorensen MIME-Version: 1.0 References: <4B5DCAF2.3010105@redhat.com> <20100126002447.GA8800@morn.localdomain> <4B5F640C.2030907@redhat.com> <20100128043917.GA3623@morn.localdomain> In-Reply-To: <20100128043917.GA3623@morn.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH] Seabios - read e820 table from qemu_cfg List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin O'Connor Cc: Anthony Liguori , Gleb Natapov , kvm@vger.kernel.org, seabios@seabios.org, Alexander Graf , qemu-devel@nongnu.org, Avi Kivity On 01/28/10 05:39, Kevin O'Connor wrote: > I think defining accessor functions for every piece of data passed > through qemu-cfg interface is going to get tiring. I'd prefer to > extend the existing qemu-cfg "file" interface for new content. > > For example, add a helper with something like: > > int qemu_cfg_get_file(const char *name, void *dest, int maxsize); Hi Kevin, I think switching qemu_cfg to use a file name based interface would be a nice feature, but I think it should be independent of this patch. I am CC'ing Gleb on this as he did the original design I believe. >> - if (kvm_para_available()) >> - // 4 pages before the bios, 3 pages for vmx tss pages, the >> - // other page for EPT real mode pagetable >> - add_e820(0xfffbc000, 4*4096, E820_RESERVED); >> + if (kvm_para_available()) { >> + u32 count; >> + >> + count = qemu_cfg_e820_entries(); >> + if (count) { >> + struct e820_entry entry; >> + int i; >> + >> + for (i = 0; i< count; i++) { >> + qemu_cfg_e820_load_next(&entry); >> + add_e820(entry.address, entry.length, entry.type); >> + } > > and then this becomes: > > struct e820entry map[128]; > int len = qemu_cfg_get_file("e820map",&map, sizeof(map)); > if (len>= 0) > for (i=0; i add_e820(map[i].start, map[i].size, map[i].type); > > The advantage being that it should be possible to write one set of > helper functions in both qemu and seabios that can then be used to > pass arbitrary content. The only issue here is that I designed the Seabios portion to not rely on the size of the struct, to avoid having to statically reserve it like in your example. Having the qemu_cfg_get_file() function return a pointer to a file descriptor and then have a qemu_cfg_read() helper that takes the descriptor as it's first argument would avoid this problem. > As a side note, it should probably do the e820 map check even for qemu > users (ie, not just kvm). Ah I didn't realize Seabios would try to use the fw_cfg interface if it wasn't running on top of QEMU. That would be good to do. Cheers, Jes