From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=39298 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Oajaj-00069I-Bo
	for qemu-devel@nongnu.org; Mon, 19 Jul 2010 02:12:42 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <gleb@redhat.com>) id 1Oajai-0000Zk-2y
	for qemu-devel@nongnu.org; Mon, 19 Jul 2010 02:12:41 -0400
Received: from mx1.redhat.com ([209.132.183.28]:1374)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <gleb@redhat.com>) id 1Oajah-0000ZS-RU
	for qemu-devel@nongnu.org; Mon, 19 Jul 2010 02:12:40 -0400
Date: Mon, 19 Jul 2010 09:12:34 +0300
From: Gleb Natapov <gleb@redhat.com>
Subject: Re: [Qemu-devel] Question about qemu firmware configuration
	(fw_cfg) device
Message-ID: <20100719061234.GS4689@redhat.com>
References: <20100717095059.GA19767@amd.home.annexia.org>
	<20100717095353.GB19767@amd.home.annexia.org>
	<269D196D-8CE8-4E24-8EE1-39756AC55F7F@suse.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <269D196D-8CE8-4E24-8EE1-39756AC55F7F@suse.de>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Alexander Graf <agraf@suse.de>
Cc: "Richard W.M.Jones" <rjones@redhat.com>, qemu-devel@nongnu.org

On Sun, Jul 18, 2010 at 07:26:57PM +0200, Alexander Graf wrote:
> 
> On 17.07.2010, at 11:53, Richard W.M. Jones wrote:
> 
> > On Sat, Jul 17, 2010 at 10:50:59AM +0100, Richard W.M. Jones wrote:
> >> I understand from the git logs that fw_cfg was added because the old
> >> way was to load kernel & initrd into RAM directly, but this didn't
> >> work because SeaBIOS would clear the RAM, clobbering kernel & initrd.
> >> Could we change to loading these directly into RAM, and instead
> >> provide some indication to SeaBIOS so it doesn't clobber the RAM?  I'm
> >> quite prepared to do the work, just wondering if there's something
> >> else I'm not getting about this.
> > 
> > Or thinking around the subject:
> > 
> > Change fw_cfg so that you send a command + a physical address, and
> > fw_cfg memcpy's the kernel / initrd / etc to that physical address.
> > Then linuxboot.bin doesn't have to do the manual copying.
> > 
> > Or just change linuxboot.bin so it does 32 bit inl instructions, which
> > might at least be a bit faster ...
> 
> I don't see why it would be slow. ins should be emulated using coalesced mmio, no?
> 
Coalesced mmio is for mmio, not pio. But we do try to optimize pio
string instructions otherwise loading of 100M would take hours.

--
			Gleb.