From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:42396)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <josh@joshtriplett.org>) id 1ZXuWj-0004Mc-VL
	for qemu-devel@nongnu.org; Fri, 04 Sep 2015 13:11:51 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <josh@joshtriplett.org>) id 1ZXuWi-0008AA-Rc
	for qemu-devel@nongnu.org; Fri, 04 Sep 2015 13:11:49 -0400
Received: from relay4-d.mail.gandi.net ([2001:4b98:c:538::196]:46169)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <josh@joshtriplett.org>) id 1ZXuWi-00088S-LQ
	for qemu-devel@nongnu.org; Fri, 04 Sep 2015 13:11:48 -0400
Date: Fri, 4 Sep 2015 10:11:41 -0700
From: josh@joshtriplett.org
Message-ID: <20150904171141.GA30585@cloud>
References: <55E80FF8.10200@redhat.com> <20150903145007.GA5145@x>
	<55E86D09.1020504@redhat.com> <20150903164121.GA23008@cloud>
	<55E8812C.8090605@redhat.com> <20150903212504.GA24388@cloud>
	<55E8D615.5070808@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <55E8D615.5070808@redhat.com>
Subject: Re: [Qemu-devel] "Using Python to investigate EFI and ACPI"
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: Laszlo Ersek <lersek@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>, Michael Tsirkin <mtsirkin@redhat.com>, edk2-devel-01 <edk2-devel@ml01.01.org>, Shannon Zhao <zhaoshenglong@huawei.com>, qemu devel list <qemu-devel@nongnu.org>, "Moore,
	Robert" <robert.moore@intel.com>, "Smith,
	Jonathan D" <jonathan.d.smith@intel.com>, Paolo Bonzini <pbonzini@redhat.com>, Marcel Apfelbaum <marcel@redhat.com>, Igor Mammedov <imammedo@redhat.com>, Marc =?iso-8859-1?Q?Mar=ED?= <markmb@redhat.com>, Jake Edge <jake@lwn.net>, "Gabriel L. Somlo (CMU)" <somlo@cmu.edu>

On Fri, Sep 04, 2015 at 01:21:57AM +0200, Laszlo Ersek wrote:
> On 09/03/15 23:25, josh@joshtriplett.org wrote:
> > On Thu, Sep 03, 2015 at 07:19:40PM +0200, Laszlo Ersek wrote:
> 
> >> In any case, if what you need resembles a "general virtio filesystem",
> >> then please just use that -- a virtio-block or virtio-scsi disk, with a
> >> normal filesystem on it. The protocol is industry standard and the
> >> performance of the QEMU (and kernel) implementation is splendid.
> > 
> > Not at all what I'm looking for; I'm looking for a *filesystem*, like
> > virtio-9p, but with significantly better performance.  I agree that
> > starting from fw_cfg for that is probably a bad idea; it's more that if
> > a high-performance virtio filesystem existed, it might also work for
> > fw_cfg. :)
> 
> Thanks for mentioning "virtio-9p", now I remember what to point at
> instead of it. I recommend Stefan's slides from this year's KVM forum.
> 
> https://kvmforum2015.sched.org/event/bca50b64e0fbea734b855498f25d0753
> http://blog.vmsplice.net/2015/08/virtio-vsock-zero-configuration.html

Interesting!  While I'm not sure a network-style protocol is the right
one for a virtual filesystem, vsock certainly has the potential to
significantly improve performance and code cleanliness.

I'd hope, though, that a high-performance virtio filesystem could also
take advantage of the ability to directly mmap a file from outside the
VM into the VM's address space.

In any case, we're getting a bit far afield for the original thread. :)

- Josh Triplett