Re: [PATCH 5/5] ioeventfd: Introduce KVM_IOEVENTFD_FLAG_SOCKET

[Sasha Levin <levinsasha928@gmail.com>]

On Wed, 2011-07-13 at 13:04 +0300, Pekka Enberg wrote:
> On Wed, Jul 13, 2011 at 10:51 AM, Pekka Enberg <penberg@kernel.org> wrote:
> > On Sun, Jul 10, 2011 at 8:34 AM, Sasha Levin <levinsasha928@gmail.com> wrote:
> >> After working on that solution a bit I saw it's adding a lot of code and
> >> complexity for this small issue, and I'm now thinking we may be better
> >> off with just handling reads twice in case of a signal just between
> >> socket_write() and socket_read() - once through the socket and once
> >> through a regular MMIO exit.
> >
> > I don't really understand the issue so can you elaborate where the
> > complexity comes from? Why can't we just switch to non-blocking read
> > and return -ENOSUPP if there's signal_pending() after socket_write()?
> > AFAICT, we can just let callers of kvm_iodevice_write() and
> > kvm_iodevice_read() deal with exits, no?
> 
> Oh, re-reading Michael's explanation, signal_pending() is irrelevant
> here and all we need to do is return -ENOSUPP if either the read or
> write fails. What's the part I'm totally missing here?

The problem is that if we received a signal during the read notification
the write and before receiving the read, we have to go back to
userspace.

This means that userspace will see same read request twice (once in the
socket and once in the MMIO exit).


-- 

Sasha.