Re: [Qemu-devel] [PATCH 0/9] introduce virtio net dataplane

[Stefan Hajnoczi]

On Thu, Feb 21, 2013 at 06:05:44PM +0100, Paolo Bonzini wrote:
> Il 21/02/2013 17:33, Stefan Hajnoczi ha scritto:
> > This especially means things like adding live
> > migration support or solving other limitations.  The limitations are
> > there to motivate core QEMU refactoring, so that core QEMU code can be
> > used directly instead of reimplementing it.
> > 
> > Here's my TODO list:
> >  * Thread pool <-> AioContext
> > 
> >    The thread pool uses an EventNotifier to invoke callbacks.  In a
> >    multiple event loop world we need to invoke callbacks in the event
> >    loop that they are associated with.
> > 
> >    Worker threads are also started using a BH so that the thread
> >    inherits the iothread CPU affinity and other characteristics.  I
> >    think this can stay.
> 
> It can and should stay. :)  BHs are tied to an AioContext.  Running
> thread-creation BHs from the AioContext's main thread ensures that the
> worker threads inherit the right attributes for e.g. real-time.

When I say "this can stay" I mean that worker threads will be spawned
from the QEMU iothread, not from the caller's thread.  Why?

Because if we decide to change this then we can no longer have a global
set of worker threads and a single work queue.  It would make worker
threads scoped to just one AioContext.

Do we really want to go there?  It kind of defeats the purpose of a
thread-pool to have one thread-pool per AioContext (i.e. per virtio-blk
device).

> >  * BlockDriverState <-> AioContext
> > 
> >    It probably makes sense to bind a BlockDriverState to an AioContext
> >    in which its file descriptors and aio activity happens.
> 
> ... and have the full chain of BlockDriverStates (bs->file,
> bs->backing_file and any others as in the vmdk driver) bound to a single
> AioContext.  We will use two BlockDriverStates if the same backing file
> happens to be shared by two disks (BTW, anybody ever checked what kind
> of havoc happens if you commit to such a BDS? :)).

AFAIK we don't share backing file BlockDriverStates today.

> >  * Thread-friendly interrupt API
> 
> What is this?

Raising interrupts, I think we're already okay using irqfd today but
maybe it's nicer to make the regular QEMU irq APIs support this instead
of manually using irqfd.

> What's still missing here is TCG support.  Perhaps you can emulate
> ioeventfd at the hw/virtio.c level and always going through a host
> notifier.  In retrospect, perhaps it was a mistake to make ioeventfd a
> non-experimental option.

That's true.  We need to emulate ioeventfd.  For virtio-pci we can cheat
by simply notifying the EventNotifier from the virtqueue kick handler.
But really we should implement an ioeventfd equivalent at the pio/mmio
emulation level in QEMU.

Stefan