From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48256) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gUvXj-0007QQ-KR for qemu-devel@nongnu.org; Thu, 06 Dec 2018 10:26:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gUvXg-0005kv-Fd for qemu-devel@nongnu.org; Thu, 06 Dec 2018 10:26:23 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:52169 helo=mx0a-001b2d01.pphosted.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gUvXg-0005kR-92 for qemu-devel@nongnu.org; Thu, 06 Dec 2018 10:26:20 -0500 Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id wB6FLVr5016103 for ; Thu, 6 Dec 2018 10:26:19 -0500 Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by mx0a-001b2d01.pphosted.com with ESMTP id 2p75skaw5y-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 06 Dec 2018 10:26:19 -0500 Received: from localhost by e34.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 6 Dec 2018 15:26:18 -0000 References: <20181122165432.4437-1-cohuck@redhat.com> <20181204133810.66e8cfe5@oc2783563651> <20181204141130.06496b9b.cohuck@redhat.com> <20181204160236.54de2784@oc2783563651> <20181205135402.33c2b22d.cohuck@redhat.com> <20181206153917.59e8e291.cohuck@redhat.com> From: Farhan Ali Date: Thu, 6 Dec 2018 10:26:12 -0500 MIME-Version: 1.0 In-Reply-To: <20181206153917.59e8e291.cohuck@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Message-Id: Subject: Re: [Qemu-devel] [PATCH 0/3] vfio-ccw: support hsch/csch (kernel part) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Cornelia Huck Cc: Halil Pasic , linux-s390@vger.kernel.org, Eric Farman , Alex Williamson , Pierre Morel , kvm@vger.kernel.org, qemu-devel@nongnu.org, qemu-s390x@nongnu.org, "Jason J . Herne" On 12/06/2018 09:39 AM, Cornelia Huck wrote: > On Wed, 5 Dec 2018 13:34:11 -0500 > Farhan Ali wrote: > >> On 12/05/2018 07:54 AM, Cornelia Huck wrote: >>>> Yeah, that is perfectly clear, but it ain't the complete story. E.g. >>>> are subsequent commands blocking until the preceding command finishes >>>> is part of the interface. And what is good implementation depends on the >>>> answer. What I mean, I first need to understand how things are supposed >>>> to work (together) so I can double check that against the >>>> implementation. Otherwise all I can do is nitpicking. >>>> >>>> To get more tangible: we are in the middle of processing an SSCH request >>>> (e.g. doing the translation) when a HSCH comes in. What should happen? >>>> Should we start processing HSCH after he instruction part of SSCH is >>>> done -- which currently includes translation? Or should we -EBUSY? Or do >>>> we abort START related activities and do the HALT stuff? >>> I think most of the sorting-out-the-operations stuff should be done by >>> the hardware itself, and we should not really try to enforce anything >>> special in our vfio code. >>> >>> For your example, it might be best if a hsch is always accepted and >>> send on towards the hardware. Probably best to reflect back -EAGAIN if >>> we're currently processing another instruction from another vcpu, so >>> that the user space caller can retry. Same for ssch, if another ssch is >>> already being processed. We*could* reflect cc 2 if the fctl bit is >>> already set, but that won't do for csch, so it is probably best to have >>> the hardware figure that out in any case. >>> >>> If I read the code correctly, we currently reflect -EBUSY and not >>> -EAGAIN if we get a ssch request while already processing another one. >>> QEMU hands that back to the guest as a cc 2, which is not 100% correct. >>> In practice, we don't see this with Linux guests due to locking. >>> >> >> If we have a ssch and a csch immediately afterwards from userspace, will >> we end up issuing csch first and then ssch to the hardware? >> >> If I understand correctly, the ccw translation as part of the ssch can >> be a slow operation so it might be possible we issue the csch first? >> In that case we won't actually clear the original start function as >> intended. > > When we start processing the ssch request (translation and so on), we > set the state to BUSY. This means that any csch request will get a > -EBUSY, no overtaking possible. (I think maybe I'll need to check what > this series looks like if I rebase it on top of Pierre's rework, as he > did some changes in the state machine.) I think you meant the state is set to BOXED? otherwise the patch 3 says if state is BUSY and CLEAR event request comes in, we issue the clear instruction, no? > > My idea above was to return -EAGAIN instead of -EBUSY, so that user > space can retry the operation. > >