Xen devel - Nov 2010 - is a pure usermode backend possible?

Is there any reason why a purely user mode backend driver could not work
in Dom0? I believe that the xenstore, grant table, and event channel
interfaces all exist so I can''t see why not, unless creating nodes
under
/local/domain/0/backend might confuse something?

Assuming it''s possible, are there any performance reasons or other
reasons why it might not be a good idea?

Thanks

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Stefano posted a pure userspace blkback for qemu only yesterday. Apparently
it performs very well.

 -- Keir

On 19/11/2010 09:59, "James Harper"
<james.harper@bendigoit.com.au> wrote:
> Is there any reason why a purely user mode backend driver could not work
> in Dom0? I believe that the xenstore, grant table, and event channel
> interfaces all exist so I can''t see why not, unless creating nodes
under
> /local/domain/0/backend might confuse something?
> 
> Assuming it''s possible, are there any performance reasons or other
> reasons why it might not be a good idea?
> 
> Thanks
> 
> James
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Fri, 2010-11-19 at 09:59 +0000, James Harper wrote:
> Is there any reason why a purely user mode backend driver could not work
> in Dom0? I believe that the xenstore, grant table, and event channel
> interfaces all exist so I can''t see why not,
Indeed, it''s not only possible but already done, e.g. pvfb, file and
the
console backends.

We are considering a userspace block backend right now. See the recent
thread "blktap: Sync with XCP, dropping zero-copy" and in particular
Stefano''s experiments with the blkback implementation which is already
in upstream qemu.
>  unless creating nodes under
> /local/domain/0/backend might confuse something?
Only if you reused a subdirectory which was already used by a kernel
mode backend. There''s no reason to do this though since the frontend
always finds the backend via its backend node in xenstore so you can
just pick a new name for your userspace backend.

The existing tap and vbd backends are an existing example of this
indirection, although both are in-kernel drivers in that case.
> Assuming it''s possible, are there any performance reasons or other
> reasons why it might not be a good idea?
The general feeling is that a block backend completely in userspace may
well be acceptable (e.g. compared with tapdisk which already goes
through userspace) and Stefano''s initial experiments seem to support
that.

We think that netback performance would suffer badly if you moved it to
userspace, although no one has done that experiment. AIUI the virtio
folks are currently looking at moving the virtio-net backend from user
to kernel for the same reason though.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

I guess it depends on what the specific backend needs to do. I can see that it
makes sense to put a block backend in user space where process scheduling
latency might not be such an issue. Putting a network backend, for instance, in
user space will probably hurt.

  Paul
> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of James Harper
> Sent: 19 November 2010 09:59
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] is a pure usermode backend possible?
> 
> Is there any reason why a purely user mode backend driver could not
> work
> in Dom0? I believe that the xenstore, grant table, and event channel
> interfaces all exist so I can''t see why not, unless creating nodes
> under
> /local/domain/0/backend might confuse something?
> 
> Assuming it''s possible, are there any performance reasons or other
> reasons why it might not be a good idea?
> 
> Thanks
> 
> James
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Fri, 19 Nov 2010, Keir Fraser wrote:
> Stefano posted a pure userspace blkback for qemu only yesterday. Apparently
> it performs very well.
I am waiting for upstream qemu to work with xen before doing any
benchmarks, because upstream qemu has a far better aio implementation
than the current qemu-xen.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> 
> Stefano posted a pure userspace blkback for qemu only yesterday.
Apparently
> it performs very well.
> 
I looked through the patch set, and it appears that this integrates
fairly closely to qemu. I assume that the xenstore state management is
handled somewhere inside qemu right?

Would it be possible to have a completely separate (from qemu) userspace
backend or would that leave an unclean termination in the event of the
userspace code crashing?

Is qemu modular in any way and could support a module build completely
separately? 

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wed, 24 Nov 2010, James Harper wrote:
> I looked through the patch set, and it appears that this integrates
> fairly closely to qemu. I assume that the xenstore state management is
> handled somewhere inside qemu right?
> 
Yes, there is generic code in xen_backend.c to take care of it.
> Would it be possible to have a completely separate (from qemu) userspace
> backend or would that leave an unclean termination in the event of the
> userspace code crashing?
> 
Yes, it is possible. Of course if the backend crashes the guest would be
in trouble.

> Is qemu modular in any way and could support a module build completely
> separately? 
 
No, it does not.

However it is possible to start a qemu instance that only provides
the disk backend and does nothing else and can be run in parallel to any
other qemu instance you need for that VM.
You just need to start qemu with command line options to choose the
xenpv machine and comment out all the other xen_be_register apart from
"qdisk" in hw/xen_machine_pv.c

The fact that the backend is in qemu doesn''t mean that has to be run in
the same qemu instance that provides device emulation.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> 
> On Wed, 24 Nov 2010, James Harper wrote:
> > I looked through the patch set, and it appears that this integrates
> > fairly closely to qemu. I assume that the xenstore state management
is
> > handled somewhere inside qemu right?
> >
> 
> Yes, there is generic code in xen_backend.c to take care of it.
> 
> > Would it be possible to have a completely separate (from qemu)
userspace
> > backend or would that leave an unclean termination in the event of
the
> > userspace code crashing?
> >
> 
> Yes, it is possible. Of course if the backend crashes the guest would
be
> in trouble.
> 
> 
> > Is qemu modular in any way and could support a module build
completely
> > separately?
> 
> No, it does not.
> 
> However it is possible to start a qemu instance that only provides
> the disk backend and does nothing else and can be run in parallel to
any
> other qemu instance you need for that VM.
> You just need to start qemu with command line options to choose the
> xenpv machine and comment out all the other xen_be_register apart from
> "qdisk" in hw/xen_machine_pv.c
> 
> The fact that the backend is in qemu doesn''t mean that has to be
run
in
> the same qemu instance that provides device emulation.
> 
Looks like there are almost too many choices :)

Thanks

James


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi,
> Would it be possible to have a completely separate (from qemu) userspace
> backend
http://hg.et.redhat.com/cgi-bin/hg-kvm.cgi/xenner/file/6b53579b4b15/blkbackd.c

That became the xen blk backend in upstream qemu later.  Bitrotted a bit 
I suspect, probably needs some patches to work with recent xen 
libraries.  Also you might want to re-sync the block drivers with qemu.
> Is qemu modular in any way and could support a module build completely
> separately?
No, although the discussion comes up now and then whenever this should 
be changed.  Especially splitting the block drivers into a shared 
library is considered useful, but nobody did the work yet.

Also note that qemu provides userspace xen backends already (pvfb, 
optionally console), so allowing it to handle disk too looks natural ;)

cheers,
   Gerd

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wed, 24 Nov 2010, Gerd Hoffmann wrote:
>  Hi,
>
>> Would it be possible to have a completely separate (from qemu)
userspace
>> backend
>
>
http://hg.et.redhat.com/cgi-bin/hg-kvm.cgi/xenner/file/6b53579b4b15/blkbackd.c
>
> That became the xen blk backend in upstream qemu later.  Bitrotted a bit I 
> suspect, probably needs some patches to work with recent xen libraries. 
Also
> you might want to re-sync the block drivers with qemu.
I had a go at updating it on Fedora 14 when I broke it by updating xen 
to 4.x . I managed to get it to build but I couldn''t get it to work. It
sounds as if it might be worth trying again.

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel