Re: LuaJIT-on-Xen?
- From: Antti Kantee <pooka@xxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Mon, 06 May 2013 16:31:40 +0200
On 06.05.2013 14:01, Justin Cormack wrote:
If anyone skims over the manpage and notices any reason why it would cause
problems for LuaJIT, I'd like to know ASAP, because I want to set that
interface in stone in the next few days. (don't get hung up on the "create
thread" hypercall. you can implement that with coroutines. I did something
similar for a userspace file system framework I wrote years ago -- in case
someone wants to know, I used coroutines because I was going through my
"threads are evil" phase)
And of course once the rump kernel is running on top of LuaJIT, the drivers
provided by it will be available anywhere that LuaJIT runs, be it POSIX,
Xen, or something more imaginative.
I can't see any immediate issues. There is an overhead if you
implement the hypercall implementation in LuaJIT as calling from C to
Lua has an overhead. I don't think this is a real issue though as the
overhead is not huge and you would probably implement most of it in C
anyway (eg the mutexes).
Thank you for the input.
Specifically about mutexes, if we assume coroutines, we don't really
have to implement mutexes at all apart from variable assignment and a
yield in case the mutex was taken. In fact, there's even an alternative
locking layer inside the rump kernel which optimizes away all of the
in-kernel mutex calls for the uncontended case. I wrote it originally
as a uniprocessor optimization to counter the "all operating systems
must now be written from scratch in a single-threaded, message-passing
manner" fad .. but what are coroutines if not uniprocessor?
http://nxr.netbsd.org/xref/src/sys/rump/librump/rumpkern/locks_up.c
(hmm, i should update that file. it's not compiled by default)
I agree with you that any other optimizations we can safely categorize
as "cross that hurdle if some profiling suggests we should".
It is not immediately obvious from the man pages how the hypercall
interface provides a backend for a network device, the examples show
you can use a native Linux interface but I haven't worked out how that
works yet...
Ah, well spotted. The virtual nic driver uses a few additional
hypercalls. I've worked with three different network backends for a
rump kernel, two kinds of tuntap+bridge (one from userspace, one from
inside the linux kernel), and one direct interface to a packet
processor. They all could use the same rump kernel side of the driver,
but needed non-generic hypercalls to be able to communicate with the
backend. Since I saw no use for such hypercalls beyond the nic driver,
I made those hypercalls private to the driver (in the NetBSD tree there
are three other drivers with private hypercalls, none of which I assume
are relevant for you: shmif, sockin and ugenhc).
Here's the virtif hypercall implementation for userspace (Linux, NetBSD,
DragonFly):
http://nxr.netbsd.org/xref/src/sys/rump/net/lib/libvirtif/rumpcomp_user.c
And here's the implementation in the Linux kernel:
https://github.com/anttikantee/rumpuser-linuxkernel/blob/master/hypervisor-virtif.c
So it's essentially "open device", "read packet(s)", "write packet(s)".
I should update the virt(4) manual page to mention this.
- antti
Other related posts:
