From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 5/5] ioeventfd: Introduce KVM_IOEVENTFD_FLAG_SOCKET Date: Mon, 25 Jul 2011 15:16:22 +0300 Message-ID: <4E2D5E96.60806@redhat.com> References: <1309927078-5983-1-git-send-email-levinsasha928@gmail.com> <1309927078-5983-5-git-send-email-levinsasha928@gmail.com> <20110706114203.GA18368@redhat.com> <1309964506.15123.13.camel@sasha> <20110706155135.GA21638@redhat.com> <1310276083.2393.6.camel@sasha> <20110710080559.GC1630@redhat.com> <1310469824.2393.22.camel@sasha> <4E1C2F59.90600@redhat.com> <4E1D442E.6090308@redhat.com> <1311595829.10256.7.camel@lappy> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Pekka Enberg , "Michael S. Tsirkin" , kvm@vger.kernel.org, Ingo Molnar , Marcelo Tosatti To: Sasha Levin Return-path: Received: from mx1.redhat.com ([209.132.183.28]:41485 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750864Ab1GYMQd (ORCPT ); Mon, 25 Jul 2011 08:16:33 -0400 In-Reply-To: <1311595829.10256.7.camel@lappy> Sender: kvm-owner@vger.kernel.org List-ID: 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