Re: [PATCH] ioeventfd: Introduce KVM_IOEVENTFD_FLAG_PIPE

[Sasha Levin <levinsasha928@gmail.com>]

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.