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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
