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

[Sasha Levin <levinsasha928@gmail.com>]

On Wed, 2011-07-13 at 10:07 +0300, Avi Kivity wrote:
> Second, introducing a new type of exit doesn't mean we see more exits.
> 
> Third, the new type of exit is probably not needed - we can use the 
> existing mmio/pio exits, and document that in certain cases the kernel 
> will fall back to these instead of delivering the I/O via the sockets 
> (userspace can then try writing itself).

Just waking this up since I want to send a new version and just want to
cover some things before that.

The problem with the original implementation was that if we receive a
signal while we wait for the host to provide a value to be read, we must
abort the operation and exit to do the signal.

What this caused was that read operations with side effects would break
(for example, when reading a byte would change the value in that byte).

The original plan was to notify the host that we ignored his answer via
the socket, and it should provide the response again via regular MMIO
exit, but I couldn't find a good way to pass it through the MMIO exit.
Also, This would complicate this operation on the host quite a bit.

What I did instead was to assume that if the socket write notifying the
host of a read operation went through ok, we can block on the socket
read request.

Does it sound ok? I know it's not what was originally planned, but to me
it looked like the most efficient approach.


-- 

Sasha.