Re: [Xen-devel] [RFC] VirtFS support on Xen

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Fri, Jan 22, 2016 at 11:12:01AM +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: xen-devel-bounces@xxxxxxxxxxxxx [mailto:xen-devel-
> > bounces@xxxxxxxxxxxxx] On Behalf Of Wei Liu
> > Sent: 22 January 2016 10:51
> > To: Bob Liu
> > Cc: Xen-devel; Wei Liu; David Vrabel
> > Subject: Re: [Xen-devel] [RFC] VirtFS support on Xen
> > 
> > On Fri, Jan 22, 2016 at 06:45:30PM +0800, Bob Liu wrote:
> > > Hi Wei,
> > >
> > > On 01/21/2016 06:59 PM, Wei Liu wrote:
> > > > On Thu, Jan 21, 2016 at 10:50:08AM +0000, David Vrabel wrote:
> > > >> On 21/01/16 10:28, Wei Liu wrote:
> > > >>> [RFC] VirtFS support on Xen
> > > >>>
> > > >>> # Introduction
> > > >>>
> > > >>> QEMU/KVM supports file system passthrough via an interface called
> > > >>> VirtFS [0]. VirtFS is in turn implemented with 9pfs protocol [1] and
> > > >>> VirtIO transport.
> > > >>>
> > > >>> Xen used to have its own implementation of file system passthrough
> > > >>> called XenFS, but that has been inactive for a few years. The latest
> > > >>> update was in 2009 [2].
> > > >>>
> > > >>> This project aims to add VirtFS support on Xen. This is more
> > > >>> sustainable than inventing our own wheel.#
> > > >>
> > > >> What's the use case for this?  Who wants this feature?
> > > >>
> > > >
> > > > Anyone who wants file system passthrough.  More specifically, VM-
> > based
> > > > container solutions can share files from host file system.
> > > >
> > >
> > > I'm a bit confused, can't we just use the VirtFS of Qemu?
> > > E.g
> > > ./configure --with-extra-qemuu-configure-args="--enable-virtfs"
> > >
> > 
> > Yes, in theory you can -- with VirtIO transport. But I'm not sure if
> > Virtio has been fixed to work with Xen.  That also means you need QEMU
> > emulation, which we don't really need (or want) when running in PV or
> > PVH mode.
> > 
> 
> Is there not scope for:
> 
> a) Fixing VirtIO so it does work with Xen?

Presumably you mean fixing VirtIO to work with Xen HVM guest.  Yes.
Stefano sent patches for fixing that. That involves changing some
assumptions in Virtio design. Not sure how it goes at the moment. As far
as I can tell those patches are not yet upstreamed or have been
superseded by some other patches promised to be written by someone else.

> b) Resurrecting the idea of emulator disaggregation so that we could
> spawn a QEMU that only serves as a VirtIO backend so that this can be
> used for PV/PHV guests?
> 

I think disaggregation of emulators is a different and orthogonal issue.
(There is on-going work to spawn two QEMU for HVM guests, one for PV
backends, one for emulation.)

PV can't use existing Virtio transports because there is no emulation
for PV guest, unless we write Xen transport for Virtio. After
investigation I found it very hard to finish in a finite time frame  and
unsustainable in the long run.

PVH can possibly use VirtIO, but how it is going to be implemented is
unclear.  There are a few things to get hashed out before we can think
of VirtIO with PVH guests.  There is nothing that prevents we make
VirtIO work with PVH in the future though, once everything is in place.

Wei.

> Seems like a better solution that implementing our own 9p transport and 
> backend.
> 
>   Paul
> 
> > 
> > Wei.
> > 
> > 
> > > Thanks,
> > > Bob
> > >
> > > > http://xendevsummit2015.sched.org/event/3WDg/xen-containers-
> > better-way-to-run-docker-containers-sainath-grandhi-
> > intel?iframe=no&w=&sidebar=yes&bg=no
> > > > http://xendevsummit2015.sched.org/event/3X1L/hyper-make-vm-run-
> > like-containers-xu-wang-hyper?iframe=no&w=&sidebar=yes&bg=no
> > > >
> > > > Wei.
> > > >
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxx
> > http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel