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

Avi Kivity
2011-07-25T12:16:33Z

On 07/25/2011 03:10 PM, Sasha Levin wrote:
> 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.

You can't block when a signal is pending. You can block, however, after
you've exited with -EINTR and re-entered.

We need to document that if a vcpu exited with -EINTR, then any socket
memory transactions need to be flushed before the vcpu's state can be
considered stable (for live migration). In fact it's true for any kind
of exit.

--
error compiling committee.c: too many arguments to function