From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N5BWt-0001vp-M6 for qemu-devel@nongnu.org; Tue, 03 Nov 2009 00:02:03 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N5BWo-0001uo-Bi for qemu-devel@nongnu.org; Tue, 03 Nov 2009 00:02:02 -0500 Received: from [199.232.76.173] (port=37886 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N5BWn-0001uW-UT for qemu-devel@nongnu.org; Tue, 03 Nov 2009 00:01:57 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51466) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N5BWm-0004w4-TK for qemu-devel@nongnu.org; Tue, 03 Nov 2009 00:01:57 -0500 Message-ID: <4AEFB940.1020201@redhat.com> Date: Tue, 03 Nov 2009 07:01:52 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] PC machine types switched to SeaBIOS/gPXE References: <4AEAFE39.1030302@us.ibm.com> <4AEED5EC.8000406@suse.de> <4AEED9D8.2020307@redhat.com> <4AEEDB75.3090100@suse.de> <4AEEDF86.7080009@redhat.com> <20091102135107.GA9856@morn.localdomain> <4AEEE4F8.1020409@redhat.com> <20091103045056.GA13246@morn.localdomain> <6C88F564-1E98-4F82-90F8-99F390927042@suse.de> In-Reply-To: <6C88F564-1E98-4F82-90F8-99F390927042@suse.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Anthony Liguori , Kevin O'Connor , beth kon , "qemu-devel@nongnu.org" , Gleb Natapov On 11/03/2009 06:57 AM, Alexander Graf wrote: >> Yes, I'd prefer to see this. In earlier emails, Gleb made a reference >> to a qemu-cfg "stream" interface that is used for acpi tables - maybe >> the kernel could be put in one of the streams and the rom could copy >> it into ram on boot. > > > I don't think streaming is the right approach here. Streaming would > mean the rom had to copy, which again either a lot of PIO accesses > (slow!) or a complicated DMA interface. A rep/ins instruction will take one exit/page so it won't be particularly slow. > I'd rather go for a RAM poking approach. As soon as the option rom is > loaded, it calls qemu via PIO telling it to "load the kernel in RAM > now" and as of the next instruction everything's in place at the > determined addresses. It's not like we could do anything about the > physical layout in the option rom anyways, usually the kernel tells us > what that looks like. That works too, but if firmware config can use rep/ins, that's one less interface we have to add. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.