From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Qemu (host) <-> host userspace signaling? Date: Mon, 01 Jun 2009 10:51:08 +0300 Message-ID: <4A23886C.7020809@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: pav Return-path: Received: from mx2.redhat.com ([66.187.237.31]:59705 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751953AbZFAHvM (ORCPT ); Mon, 1 Jun 2009 03:51:12 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: pav wrote: > Hello, > > I am looking for a simple way to get a bidirectional event notification > interface between qemu/kvm and host userspace processes. Just a "kick", > messages/data not required. > > > What I basically need is a way to have an interested host process > informed by a custom qemu device that something happened (i.e. after a > MMIO write) and the other way around - to allow similar notifications > from the process to the qemu device. Of course I do not want qemu to > sleep. > Instant reaction to such events is not required. > > > I understand I could use a unix socket and qemu_chr_open() and friends > for this, but isn't a full-blown socket a bit of an overkill for a simple > "kick" interface? > Not at all. Send a byte to have the other side wake up. > From what I understand qemu would then act as a server and sleep just > after starting (or later?), waiting for connections? Or maybe there is a > way to reverse it, have qemu be the client, although that could still > make qemu sleep?. > I guess it could use some kind of poll/select, but I am not sure where in > qemu should such code be put in though... > You can have have qemu act as a client or as server, and wait for connections or not. > Or maybe there is something else for this in qemu already? I had thought > iosignalfd or eventfd were made for that, but if I understand correctly, > they communicate with the guest and are for something different? > iosiginalfd and irqfd are slightly more efficient, but you need to make them available to another process by passing them over a unix domain socket with SCM_RIGHTS. So they are more cumbersome to set up. irqfd also requires MSI support in the guest. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.