[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 0/9] introduce virtio net dataplane
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] [PATCH 0/9] introduce virtio net dataplane |
Date: |
Fri, 22 Feb 2013 11:43:38 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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
Re: [Qemu-devel] [PATCH 0/9] introduce virtio net dataplane, Stefan Hajnoczi, 2013/02/21
- Re: [Qemu-devel] [PATCH 0/9] introduce virtio net dataplane, Paolo Bonzini, 2013/02/21
- Re: [Qemu-devel] [PATCH 0/9] introduce virtio net dataplane, mdroth, 2013/02/21
- Re: [Qemu-devel] [PATCH 0/9] introduce virtio net dataplane, Paolo Bonzini, 2013/02/21
- Re: [Qemu-devel] [PATCH 0/9] introduce virtio net dataplane, mdroth, 2013/02/21
- Re: [Qemu-devel] [PATCH 0/9] introduce virtio net dataplane, Paolo Bonzini, 2013/02/22
- Re: [Qemu-devel] [PATCH 0/9] introduce virtio net dataplane, Stefan Hajnoczi, 2013/02/22
Re: [Qemu-devel] [PATCH 0/9] introduce virtio net dataplane,
Stefan Hajnoczi <=
Re: [Qemu-devel] [PATCH 0/9] introduce virtio net dataplane, Paolo Bonzini, 2013/02/22
Re: [Qemu-devel] [PATCH 0/9] introduce virtio net dataplane, Kevin Wolf, 2013/02/22
Re: [Qemu-devel] [PATCH 0/9] introduce virtio net dataplane, Paolo Bonzini, 2013/02/22