From: Sasha Levin <levinsasha928@gmail.com>
To: Avi Kivity <avi@redhat.com>
Cc: kvm@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
Marcelo Tosatti <mtosatti@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Pekka Enberg <penberg@kernel.org>
Subject: Re: [PATCH] ioeventfd: Introduce KVM_IOEVENTFD_FLAG_PIPE
Date: Mon, 04 Jul 2011 17:52:14 +0300 [thread overview]
Message-ID: <1309791134.4117.27.camel@sasha> (raw)
In-Reply-To: <4E11D20F.9020509@redhat.com>
On Mon, 2011-07-04 at 17:45 +0300, Avi Kivity wrote:
> On 07/04/2011 05:38 PM, Sasha Levin wrote:
> > >
> > > 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?
>
> Yes. Register a range and support all sizes.
>
> Perhaps it merits a separate ioctl.
>
> > 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?
>
> I can't really see that as useful. eventfds destroy information;
> without datamatch, you have no idea what value was written. Even with
> datamatch, you have no idea how many times it was written. With a
> range, you also have no idea which address was written. It's pretty
> meaningless.
>
It is pretty useless, but I didn't want the ioctl to behave differently
when passing a socket or an eventfd.
If we do go for a new ioctl as you suggested then yes, problem solved.
--
Sasha.
next prev parent reply other threads:[~2011-07-04 14:52 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-03 17:04 [PATCH] ioeventfd: Introduce KVM_IOEVENTFD_FLAG_PIPE Sasha Levin
2011-07-03 17:16 ` Avi Kivity
2011-07-03 17:44 ` Sasha Levin
2011-07-03 17:57 ` Pekka Enberg
2011-07-04 10:27 ` Avi Kivity
2011-07-04 10:49 ` Michael S. Tsirkin
2011-07-04 10:57 ` Avi Kivity
2011-07-04 14:38 ` Sasha Levin
2011-07-04 14:45 ` Avi Kivity
2011-07-04 14:52 ` Sasha Levin [this message]
2011-07-04 14:59 ` Avi Kivity
2011-07-06 4:37 ` Sasha Levin
2011-07-06 11:30 ` Avi Kivity
2011-07-04 10:32 ` Michael S. Tsirkin
2011-07-04 10:45 ` Avi Kivity
2011-07-04 11:07 ` Michael S. Tsirkin
2011-07-04 11:19 ` Avi Kivity
2011-07-04 11:45 ` Michael S. Tsirkin
2011-07-04 11:49 ` Avi Kivity
2011-07-04 12:12 ` Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1309791134.4117.27.camel@sasha \
--to=levinsasha928@gmail.com \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mst@redhat.com \
--cc=mtosatti@redhat.com \
--cc=penberg@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox