From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] ioeventfd: Introduce KVM_IOEVENTFD_FLAG_PIPE Date: Mon, 04 Jul 2011 13:57:16 +0300 Message-ID: <4E119C8C.60808@redhat.com> References: <1309712689-4290-1-git-send-email-levinsasha928@gmail.com> <4E10A3E6.1070606@redhat.com> <1309715091.4117.16.camel@sasha> <4E1195A1.10103@redhat.com> <20110704104905.GC11386@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sasha Levin , kvm@vger.kernel.org, Ingo Molnar , Marcelo Tosatti , Pekka Enberg To: "Michael S. Tsirkin" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:52663 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752415Ab1GDK50 (ORCPT ); Mon, 4 Jul 2011 06:57:26 -0400 In-Reply-To: <20110704104905.GC11386@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 07/04/2011 01:49 PM, Michael S. Tsirkin wrote: > On Mon, Jul 04, 2011 at 01:27:45PM +0300, Avi Kivity wrote: > > 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. > > > > >> Is the write guaranteed atomic? We probably need serialization here. > > > > > >afaik vfs_write is just a wrapper to the write() function of the > > >underlying fs so it should be atomic, no? > > > > write() isn't atomic in general. It is for pipes under certain > > circumstances, but there is no guarantee that the circumstances > > apply, or that the fd is in fact a pipe. > > So the above makes it tricky to pass structured data > which is> 1 byte in size over a pipe. We could build an in-kernel API > (not sure how useful it would be for userspace) to do > an atomic write or fail (instead of a partial write), > but we'll still need to handle failures. We don't need atomicity after a failure, just under normal operation, and that can be provided by a mutex. It's not trivial since a single fd might be associated with several region. -- error compiling committee.c: too many arguments to function