From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sasha Levin Subject: Re: [PATCH 5/5] ioeventfd: Introduce KVM_IOEVENTFD_FLAG_SOCKET Date: Mon, 25 Jul 2011 15:26:06 +0300 Message-ID: <1311596766.10256.9.camel@lappy> 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> <4E2D5E96.60806@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Pekka Enberg , "Michael S. Tsirkin" , kvm@vger.kernel.org, Ingo Molnar , Marcelo Tosatti To: Avi Kivity Return-path: Received: from mail-wy0-f174.google.com ([74.125.82.174]:49757 "EHLO mail-wy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750864Ab1GYM0k (ORCPT ); Mon, 25 Jul 2011 08:26:40 -0400 Received: by wyg8 with SMTP id 8so2703129wyg.19 for ; Mon, 25 Jul 2011 05:26:39 -0700 (PDT) In-Reply-To: <4E2D5E96.60806@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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.