From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:53934)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1ZF5oO-00087F-Iy
	for qemu-devel@nongnu.org; Tue, 14 Jul 2015 15:24:17 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1ZF5oL-0004YR-2E
	for qemu-devel@nongnu.org; Tue, 14 Jul 2015 15:24:16 -0400
Received: from mx1.redhat.com ([209.132.183.28]:60142)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1ZF5oK-0004YM-Tf
	for qemu-devel@nongnu.org; Tue, 14 Jul 2015 15:24:13 -0400
Message-ID: <1436901844.7200.26.camel@redhat.com>
From: Gerd Hoffmann <kraxel@redhat.com>
Date: Tue, 14 Jul 2015 21:24:04 +0200
In-Reply-To: <20150714182314.GO1606@HEDWIG.INI.CMU.EDU>
References: <20150713200936.GK1606@HEDWIG.INI.CMU.EDU>
	<20150714094346.GR29283@redhat.com>
	<20150714182314.GO1606@HEDWIG.INI.CMU.EDU>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] RFC: guest-side retrieval of fw_cfg file
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/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: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: "Gabriel L. Somlo" <gsomlo@gmail.com>
Cc: matt.fleming@intel.com, mdroth@linux.vnet.ibm.com, qemu-devel@nongnu.org, jordan.l.justen@intel.com, "Gabriel L. Somlo" <somlo@cmu.edu>, gleb@cloudius-systems.com, "Richard W.M. Jones" <rjones@redhat.com>, pbonzini@redhat.com, Laszlo Ersek <lersek@redhat.com>

  Hi,

> > > /* read chunk of given fw_cfg blob (caller responsible for sanity-check) */
> > > static inline void fw_cfg_read_blob(uint16_t select,
> > > 				     void *buf, loff_t pos, size_t count)
> > > {
> > > 	mutex_lock(&fw_cfg_dev_lock);
> > > 	outw(select, FW_CFG_PORT_CTL);
> > > 	while (pos-- > 0)
> > > 		inb(FW_CFG_PORT_DATA);
> > > 	insb(FW_CFG_PORT_DATA, buf, count);
> > > 	mutex_unlock(&fw_cfg_dev_lock);
> > > }
> > 
> > How slow is this?
> 
> Well, I think each outw() and inb() will result in a vmexit, with
> userspace handling emulation, so much slower comparatively than
> inserting into a list (hence mutex here, vs. spinlock there).

There are a few tricks to speed up things, not sure this really matters
here as we don't transfer big stuff like kernel or initrd here.

Trick one (for x86) is that you can use string prefixes (i.e. load ecx
register with count, then use "rep insb").

Trick two (for arm) is that you can read eight instead of one byte per
instruction.

Both reduce the number of vmexits.

But speaking of kernel+initrd:  You eventually might want add them to
the filesystem too.

cheers,
  Gerd