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

Sasha Levin
2011-07-25T12:26:40Z

On Mon, 2011-07-25 at 15:16 +0300, Avi Kivity wrote:
> 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.
>

What would happen with the MMIO then? I need to provide an answer before
I leave the read/write functions to exit with -EINTR, no?

> 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.
>

--

Sasha.