Re: [Qemu-devel] Linux kernel polling for QEMU

[Fam Zheng <famz@redhat.com>]

On Tue, 11/29 20:43, Stefan Hajnoczi wrote:
> On Tue, Nov 29, 2016 at 1:24 PM, Fam Zheng <famz@redhat.com> wrote:
> > On Tue, 11/29 12:17, Paolo Bonzini wrote:
> >> On 29/11/2016 11:32, Fam Zheng wrote:
> >> * it still needs a system call before polling is entered.  Ideally, QEMU
> >> could run without any system call while in polling mode.
> >>
> >> Another possibility is to add a system call for single_task_running().
> >> It should be simple enough that you can implement it in the vDSO and
> >> avoid a context switch.  There are convenient hooking points in
> >> add_nr_running and sub_nr_running.
> >
> > That sounds good!
> 
> With this solution QEMU can either poll virtqueues or the host kernel
> can poll NIC and storage controller descriptor rings, but not both at
> the same time in one thread.  This is one of the reasons why I think
> exploring polling in the kernel makes more sense.

That's true. I have one question though: controller rings are in a different
layer in the kernel, I wonder what the syscall interface looks like to ask
kernel to poll both hardware rings and memory locations in the same loop? It's
not obvious to me after reading your eventfd patch.

> 
> The disadvantage of the kernel approach is that you must make the
> ppoll(2)/epoll_wait(2) syscall even for polling, and you probably need
> to do eventfd reads afterwards so the minimum event loop iteration
> latency is higher than doing polling in userspace.

And userspace drivers powered by dpdk or vfio will still want to do polling in
userspace anyway, we may want to take that into account as well.

Fam