Messages in this thread | | | Date | Fri, 20 Oct 2006 09:36:23 +0200 | From | Avi Kivity <> | Subject | Re: [PATCH 1/7] KVM: userspace interface |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |