Re: [PATCH 1/7] KVM: userspace interface

From: Avi Kivity
Date: Fri Oct 20 2006 - 03:36:48 EST


Anthony Liguori wrote:
Avi Kivity wrote:
Anthony Liguori wrote:

ioctls are probably wrong here though. Ideally, you would want to be able to support an SMP guest. This means you need to have two virtual processors executing in kernel space. If you use ioctls, it forces you to have two separate threads in userspace. This would be hard for something like QEMU which is currently single threaded (and not at all thread safe).


Since we're using the Linux scheduler, we need a task per virtual cpu anyway, so a thread per vcpu is not a problem.


You miss my point I think. Using ioctls *requires* a thread per-vcpu in userspace. This is unnecessary since you could simply provide a char-device based read/write interface. You could then multiplex events and poll.


Yes, ioctl()s require userspace threads, but that's okay, because they're free for us, since we need a kernel thread for each vcpu.

On the other hand, a single device model thread polling the vcpus is guaranteed to be on the wrong physical cpu for half of the time (assuming 2 cpus and 2 vcpus), requiring IPIs and suspending a vcpu in order to run.

If for nothing else, you have to be able to run timers in userspace and interrupt the kernel execution (to signal DMA completion for instance). Even in the UP case, this gets ugly quickly.


The timers aren't pretty (we use signals), yes. But avoiding the extra thread is critical for performance IMO.

read/write is really just a much cleaner interface for anything that has blocking semantics.


Ah, but scheduling a vcpu doesn't just block, it consumes the physical cpu.

All other uses of read() yield the cpu apart from setup and copying of the data.


--
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 linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/