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: Wed, 13 Jul 2011 13:26:50 +0300 Message-ID: <1310552810.14379.1.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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: "Michael S. Tsirkin" , kvm@vger.kernel.org, Avi Kivity , Ingo Molnar , Marcelo Tosatti To: Pekka Enberg Return-path: Received: from mail-fx0-f52.google.com ([209.85.161.52]:50520 "EHLO mail-fx0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965169Ab1GMK1F (ORCPT ); Wed, 13 Jul 2011 06:27:05 -0400 Received: by fxd18 with SMTP id 18so5821201fxd.11 for ; Wed, 13 Jul 2011 03:27:03 -0700 (PDT) In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Wed, 2011-07-13 at 13:04 +0300, Pekka Enberg wrote: > On Wed, Jul 13, 2011 at 10:51 AM, Pekka Enberg wrote: > > On Sun, Jul 10, 2011 at 8:34 AM, Sasha Levin wrote: > >> After working on that solution a bit I saw it's adding a lot of code and > >> complexity for this small issue, and I'm now thinking we may be better > >> off with just handling reads twice in case of a signal just between > >> socket_write() and socket_read() - once through the socket and once > >> through a regular MMIO exit. > > > > I don't really understand the issue so can you elaborate where the > > complexity comes from? Why can't we just switch to non-blocking read > > and return -ENOSUPP if there's signal_pending() after socket_write()? > > AFAICT, we can just let callers of kvm_iodevice_write() and > > kvm_iodevice_read() deal with exits, no? > > Oh, re-reading Michael's explanation, signal_pending() is irrelevant > here and all we need to do is return -ENOSUPP if either the read or > write fails. What's the part I'm totally missing here? The problem is that if we received a signal during the read notification the write and before receiving the read, we have to go back to userspace. This means that userspace will see same read request twice (once in the socket and once in the MMIO exit). -- Sasha.