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