From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:41440)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <famz@redhat.com>) id 1cBfiQ-0006Xz-Lb
	for qemu-devel@nongnu.org; Tue, 29 Nov 2016 05:32:47 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <famz@redhat.com>) id 1cBfiK-0006Dk-8L
	for qemu-devel@nongnu.org; Tue, 29 Nov 2016 05:32:46 -0500
Received: from mx1.redhat.com ([209.132.183.28]:46944)
	by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
	(Exim 4.71) (envelope-from <famz@redhat.com>) id 1cBfiJ-0006D2-Vb
	for qemu-devel@nongnu.org; Tue, 29 Nov 2016 05:32:40 -0500
Date: Tue, 29 Nov 2016 18:32:36 +0800
From: Fam Zheng <famz@redhat.com>
Message-ID: <20161129103236.GE15786@lemon>
References: <20161124151225.GA11963@stefanha-x1.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161124151225.GA11963@stefanha-x1.localdomain>
Subject: Re: [Qemu-devel] Linux kernel polling for QEMU
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel/>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: qemu-devel@nongnu.org, Jens Axboe <axboe@fb.com>, Christoph Hellwig <hch@lst.de>, Eliezer Tamir <eliezer.tamir@linux.intel.com>, Davide Libenzi <davidel@xmailserver.org>, "Michael S. Tsirkin" <mst@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>, Christian Borntraeger <borntraeger@de.ibm.com>

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