On 12/07/2009 07:33 PM, Joanna Rutkowska wrote:
AFAIK VT-d is only supported in Xen for fully virtualized guests. Maybe
it changed while I wasn't watching, though.
Negative. VT-d can be used to contain PV DomUs as well. We actually
verified it.
Ah, good for them.
It can use read() and write() (and shared memory) to communicate, just
like Xen stub domains.
Well, but the read() and write() syscalls, on a system like Linux, it's
a gate to *lots* of code. These are very powerful system calls.
But you control all the file descriptors. A minimal system would just
consist of a pair of eventfd fds for signalling and shared memory (the
Xen equivalent is event channels and grant tables).
It's a lot of surgery, but it can be done.
And then you have the code with whom this qemu communicates (e.g. the
network stack). You said we could somehow use IPC to delegate it to some
VM (that would have VT-d assigned NIC). But then this VM would need to
use qemu again (of course this time not for net emulation). Looks
non-trivial.
It doesn't really need to be a VM. Once the seccomp constrained qemu
processes the guest actions, the result is a fairly simple event stream.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
