From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sasha Levin Subject: Re: [PATCH] ioeventfd: Introduce KVM_IOEVENTFD_FLAG_PIPE Date: Mon, 04 Jul 2011 17:38:27 +0300 Message-ID: <1309790307.4117.25.camel@sasha> References: <1309712689-4290-1-git-send-email-levinsasha928@gmail.com> <4E10A3E6.1070606@redhat.com> <1309715091.4117.16.camel@sasha> <4E1195A1.10103@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, Ingo Molnar , Marcelo Tosatti , "Michael S. Tsirkin" , Pekka Enberg To: Avi Kivity Return-path: Received: from mail-ww0-f44.google.com ([74.125.82.44]:60453 "EHLO mail-ww0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753380Ab1GDOij (ORCPT ); Mon, 4 Jul 2011 10:38:39 -0400 Received: by wwe5 with SMTP id 5so5138323wwe.1 for ; Mon, 04 Jul 2011 07:38:38 -0700 (PDT) In-Reply-To: <4E1195A1.10103@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, 2011-07-04 at 13:27 +0300, Avi Kivity wrote: > On 07/03/2011 08:44 PM, Sasha Levin wrote: > > On Sun, 2011-07-03 at 20:16 +0300, Avi Kivity wrote: > > > On 07/03/2011 08:04 PM, Sasha Levin wrote: > > > > > > > > - eventfd_signal(p->eventfd, 1); > > > > + if (p->pipe) > > > > + kernel_write(p->pipe, val, len, 0); > > > > > > You're writing potentially variable length data. > > > > > > We need a protocol containing address, data, length, and supporting read > > > accesses as well. > > > > > > > This can't be variable length. > > > > The user defines an ioeventfd as an address+length (with length being up > > to 8 bytes). The only time an ioeventfd is signaled is when the write to > > the guest memory is exactly at the specified address with exactly the > > specified length. > > > > It can be variable length if multiple ioeventfds reference the same pipe. > > > ioeventfds can be extended to handle more than 8 bytes, variable address > > offset and reads now that pipe support is added, but I'd rather do it in > > follow-up patches once basic pipe support is in. > > In general incremental development is great, but I don't want to > fragment the ABI. I'd like to be able to forward an entire PCI BAR over > a pipe. That means sending the address/data/length tuple, and both read > and write support. Would this mean that for sockets we want to remove the 8 byte limit? What about eventfds? We can remove the limit there and assume that if the user asked for more than 8 bytes he knows what he's doing? -- Sasha.