On Wed, Jan 16, 2013 at 08:58:50PM +0100, Matthias Leinweber wrote:
> i try to implement a virtual device/driver, but i ran into some
> trouble using the virtio api.
> My implementation looks as follows:
> A kthread exposes memory via add_buf, kicks and sleeps. If a callback
> is issued he is woken up and takes the filled buffer back via get_buf.
> (No other kthread, process or whatever works on this vq in the
> kernel).
> In qemu a qemu_thread waits for some shared memory and tries to pop
> elements from the vq and copies some data into the guest accessible
> memory. Not all elements are necessarily poped before fill flush and
> notify are called. If a pop returns with < 0 the thread goes to sleep
> until the handler routine for this vq wakes the thread up again.
>
> from time to time (after several 100k gets,adds and pops) i get: id %u
> is not a head!.
> virtio_ring.c:
> if (unlikely(i >= vq->vring.num)) {
> BAD_RING(vq, "id %u out of range\n", i);
> return NULL;
>
> I have no idea what i am doing wrong. Is synchronization needed
> between add pop and get or am i not allowed to use a qemu_thread when
> working on a vq?
Hard to tell exactly what is going on without seeing the code.
QEMU has a global mutex and therefore does not need to do much explicit
locking...except if you spawn your own thread. The hw/virtio.c code in
QEMU is not thread-safe. You cannot use it from a thread without
holding the QEMU global mutex.
It's fine to do I/O handling in worker threads, but you must use a BH,
event notifier, or some other mechanism of kicking the QEMU iothread and
process the virtqueue completion in a callback there.
Stefan
--
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
