xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Wei Liu <wei.liu2@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Cc: Xen-devel <xen-devel@lists.xenproject.org>,
	Wei Liu <wei.liu2@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [RFC] VirtFS support on Xen
Date: Fri, 22 Jan 2016 11:31:24 +0000	[thread overview]
Message-ID: <20160122113124.GA1691@citrix.com> (raw)
In-Reply-To: <fd07e92b0b464c57b29249ff6e34060d@AMSPEX02CL03.citrite.net>

On Fri, Jan 22, 2016 at 11:12:01AM +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> > bounces@lists.xen.org] 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@lists.xen.org
> > http://lists.xen.org/xen-devel

  reply	other threads:[~2016-01-22 11:31 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-21 10:28 [RFC] VirtFS support on Xen Wei Liu
2016-01-21 10:50 ` David Vrabel
2016-01-21 10:59   ` Wei Liu
2016-01-22 10:45     ` Bob Liu
2016-01-22 10:50       ` Wei Liu
2016-01-22 11:12         ` Paul Durrant
2016-01-22 11:31           ` Wei Liu [this message]
2016-01-23  5:33         ` Bob Liu
2016-01-23 14:50           ` Wei Liu
2016-01-23 15:35             ` Konrad Rzeszutek Wilk
2016-01-25 11:29               ` Wei Liu
2016-01-25 11:35                 ` David Vrabel
2016-01-25 15:13                   ` Wei Liu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160122113124.GA1691@citrix.com \
    --to=wei.liu2@citrix.com \
    --cc=Paul.Durrant@citrix.com \
    --cc=david.vrabel@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).