On Thu, 11/24 15:12, Stefan Hajnoczi wrote:
> QEMU and KVM-specific polling
> -----------------------------
> There are a few QEMU/KVM-specific items that require polling support:
>
> QEMU's event loop aio_notify() mechanism wakes up the event loop from a
> blocking poll(2) or epoll call. It is used when another thread adds or
> changes an event loop resource (such as scheduling a BH). There is a
> userspace memory location (ctx->notified) that is written by
> aio_notify() as well as an eventfd that can be signalled.
I'm thinking about an alternative approach to achieve user space "idle polling"
like kvm_halt_poll_ns.
The kernel change will be a new prctl operation (should it be a different
syscall to extend?) to register a new type of eventfd called "idle eventfd":
prctl(PR_ADD_IDLE_EVENTFD, int eventfd);
prctl(PR_DEL_IDLE_EVENTFD, int eventfd);
It will be notified by kernel each time when the thread's local core has no
runnable threads (i.e., entering idle state).
QEMU can then add this eventfd to its event loop when it has events to poll, and
watch virtqueue/linux-aio memory from userspace in the fd handlers. Effectiely,
if a ppoll() would have blocked because there are no new events, it could now
return immediately because of idle_eventfd events, and do the idle polling.
Does that make any sense?
Fam
