Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp1747413imm; Tue, 22 May 2018 08:41:51 -0700 (PDT) X-Google-Smtp-Source: AB8JxZq3+TfP26yWqkNBP+TlbI2ks0167XpBAGetYCuEVu5270ZCo+vcAGPDRYHi6/J+1xF09kye X-Received: by 2002:a17:902:bf4a:: with SMTP id u10-v6mr25801330pls.322.1527003711153; Tue, 22 May 2018 08:41:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527003711; cv=none; d=google.com; s=arc-20160816; b=iO7caszyIt6qtf3rG0VCGCRGOw9W0nxpfVkidIZlZ48kHxea4NpI1HVWOxztogLNVn u0s3ftkIvJ9PVY5o2rHbQttMl0zcJZq+L61w/kS3rGQ298BhSZGgDVx8hZSZz2xyrvFo jjqZI8Tu3ZplwEMRPPKR0mnLIv4YM43Q6KM1Bd3g1AbayG5mitLaN27M2zSKpA2LIBO1 HmltGFG5lehdOu220QssFyZXHIFqWUlZ/vHTNW/ieK+abn22muQK8LkanWekfa1tkjmC 97KvooXj4iuothdbAHMP6vze5ZsNQsYXX8G1WERduUEUU92lginhA/hhw0Fh214jOEOs TMoA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:arc-authentication-results; bh=MXVAWNEFM5SEpdV90N+Cv2nhEy8WmLiJL6URc+tF9EQ=; b=kfQRhhz2ijpAdL7UZhjuAs1mH4hgiW3o4jod2Mf+iN+1WCGoo21TiknDkRTGOrYUbS JFpf7fzWpNYThBvDCCWFbg81Re73X+fzQ3A06TT/HzkDhP9+HvLexO46PVaGy7Ifyb0f g+d83G87hc4768h25kP65dY6ratNpGephM/F69W6oXDaLf3gqfHQ55pAstUEPGD+HXa+ ljJOPKc3L9gW3fdjmtzl9YgCFZ4eeYbQ3kGK8exVHReCinOlVKTVjUQkCHI/sFqyg4CG cbU7HWCJ5TMwYjx7+JN6PcM5SjYLCSl5+u2xJv7vPNvSh7HnAyqt36tVlwGcuDh5a9qJ McSw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p66-v6si16384434pfg.329.2018.05.22.08.41.35; Tue, 22 May 2018 08:41:51 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751374AbeEVPl0 (ORCPT + 99 others); Tue, 22 May 2018 11:41:26 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:34390 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751196AbeEVPlY (ORCPT ); Tue, 22 May 2018 11:41:24 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E953B859AC; Tue, 22 May 2018 15:41:23 +0000 (UTC) Received: from gondolin (dhcp-192-222.str.redhat.com [10.33.192.222]) by smtp.corp.redhat.com (Postfix) with ESMTP id E4B09215CDA7; Tue, 22 May 2018 15:41:22 +0000 (UTC) Date: Tue, 22 May 2018 17:41:20 +0200 From: Cornelia Huck To: Pierre Morel Cc: Dong Jia Shi , Dong Jia Shi , pasic@linux.vnet.ibm.com, linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org Subject: Re: [PATCH 04/10] vfio: ccw: replace IO_REQ event with SSCH_REQ event Message-ID: <20180522174120.2a56adb7.cohuck@redhat.com> In-Reply-To: <8c75acd1-c00b-4d7f-ea4b-d32e9b05989b@linux.vnet.ibm.com> References: <1524149293-12658-1-git-send-email-pmorel@linux.vnet.ibm.com> <1524149293-12658-5-git-send-email-pmorel@linux.vnet.ibm.com> <20180426073053.GZ12194@bjsdjshi@linux.vnet.ibm.com> <20180426074806.GB12194@bjsdjshi@linux.vnet.ibm.com> <20180430173305.632faa80.cohuck@redhat.com> <20180502074622.GV5428@bjsdjshi@linux.vnet.ibm.com> <5816643d-5406-06b9-0727-fdcd771aba63@linux.vnet.ibm.com> <20180504011916.GA26081@bjsdjshi@linux.ibm.com> <8c75acd1-c00b-4d7f-ea4b-d32e9b05989b@linux.vnet.ibm.com> Organization: Red Hat GmbH MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Tue, 22 May 2018 15:41:24 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Tue, 22 May 2018 15:41:24 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'cohuck@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 4 May 2018 13:02:36 +0200 Pierre Morel wrote: > On 04/05/2018 03:19, Dong Jia Shi wrote: > > * Pierre Morel [2018-05-03 16:26:29 +0200]: > > > >> On 02/05/2018 09:46, Dong Jia Shi wrote: > >>> * Cornelia Huck [2018-04-30 17:33:05 +0200]: > >>> > >>>> On Thu, 26 Apr 2018 15:48:06 +0800 > >>>> Dong Jia Shi wrote: > >>>> > >>>>> * Dong Jia Shi [2018-04-26 15:30:54 +0800]: > >>>>> > >>>>> [...] > >>>>> > >>>>>>> @@ -179,7 +160,7 @@ static int fsm_irq(struct vfio_ccw_private *private, > >>>>>>> if (private->io_trigger) > >>>>>>> eventfd_signal(private->io_trigger, 1); > >>>>>>> > >>>>>>> - return private->state; > >>>>>>> + return VFIO_CCW_STATE_IDLE; > >>>>>> This is not right. For example, if we are in STANDBY state (subch driver > >>>>>> is probed, but mdev device is not created), we can not jump to IDLE > >>>>>> state. > >>>>> I see my problem, for STANDBY state, we should introduce another event > >>>>> callback for VFIO_CCW_EVENT_INTERRUPT. It doesn't make sense to call > >>>>> fsm_irq() which tries to signal userspace with interrupt notification > >>>>> when mdev is not created yet... So we'd need a separated fix for this > >>>>> issue too. > >>>> But how do we even get into that situation when we don't have an mdev > >>>> yet? > >>>> > >>> We cann't... So let's assign fsm_nop() as the interrupt callback for > >>> STANDBY state? > >>> > >> :) Isn't it exactly what my patch series handle? > > As far as I see, that's not true. ;) > > > > After this series applied, > > vfio_ccw_jumptable[VFIO_CCW_STATE_STANDBY][VFIO_CCW_EVENT_INTERRUPT] is > > still fsm_irq(). > > > > > What I mean is, this code tries to handle design problems > without changing too much of the original code at first. > > The problem here is not that the fsm_irq function is called on interrupt, > if we have an interrupt it must be signaled to user land. > The problem is that this state is entered at the wrong moment. > > STANDBY should be entered, during the mdev_open when we realize the QEMU > device, > and not during the probe, in which we should stay in NOT_OPER until we > get the QEMU device. > > The probe() and mdev_open() function should be modified, not the state > table. So, the takeaway is that we should handle starting via the init callbacks and not via the state machine?