Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp4574871imu; Tue, 8 Jan 2019 02:36:20 -0800 (PST) X-Google-Smtp-Source: ALg8bN6sRUwRANkHiluWfb3nSFNMOU2EF97YXmMOg/iLzYOe0Dsj5Ns/DHiIENn+xKJaBZK7OHY3 X-Received: by 2002:a63:b105:: with SMTP id r5mr1033332pgf.442.1546943780589; Tue, 08 Jan 2019 02:36:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546943780; cv=none; d=google.com; s=arc-20160816; b=FSDC7IQcYtF8xDAp3c+xx/r/y85zBwzStna2DqjMYkD9QbGLZmB7uxJ9YBxLmDJENZ f1oIJOoJDGZRq0hGe+oHuiPFB+FS3samedEowMRcihda5MIBpHnzKZNGD9s39HBR9pBo AOF2H2/j95Uf/qgZUxY5M+C7RqujnF25IuKNUbY3xbsQ1Jtub7ywDzWR9EUYMxoPqiwi tWR8b+cX3UuVQQOXW4Q2/7KiqfdTv3KZ/so/m+cyTNdJ1PEtOMUcgylTwucfmLBiGDry P8kwY5hEEhVmjelwi9y95Zuv3I3GNX6w6NUXNuhB1QrdeL/mny3uA9VGII8GWf/MqPJF eYBg== 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; bh=tpOY7ZQDnDkrpyr/GqQkSsTjWdSZjwby95GwLTdGQGY=; b=EQXBzHRQcWfxLrxccrE9+bv99Vt3TwsD0l6lT7xq/H43RbsKOviNHMUKhkKRb+1+Zc XJ74mkNF8ZAKiPPxyWGtPRJ8E2zKIRRFoTDT73X8gA7rPX2pczVXu738F5IrOdb/A54X 4jYXsi88dqFwYbBXLLfPvTrIOGcSdJndv6quCOy7FuRNkcVUuqrBpoiKz+SMlUjsJNMi uOeY2OQkfyXngZkXRlOPgIwQ3yMOwd5yHo49PN/zzOntpTHb7rUH8FR3fFttIMgJEeHi ZoDHl5ehK35k67YOkoiYX5+UqsHl1G0KR10FHjAkIm8d1F0K+2m4q59Cdx4FWtZrKRDM yPLQ== 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 z186si16855283pgd.90.2019.01.08.02.36.05; Tue, 08 Jan 2019 02:36:20 -0800 (PST) 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 S1728243AbfAHKew (ORCPT + 99 others); Tue, 8 Jan 2019 05:34:52 -0500 Received: from mx1.redhat.com ([209.132.183.28]:42838 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727368AbfAHKew (ORCPT ); Tue, 8 Jan 2019 05:34:52 -0500 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8104F7F6CB; Tue, 8 Jan 2019 10:34:51 +0000 (UTC) Received: from gondolin (dhcp-192-222.str.redhat.com [10.33.192.222]) by smtp.corp.redhat.com (Postfix) with ESMTP id D6CC15C21C; Tue, 8 Jan 2019 10:34:46 +0000 (UTC) Date: Tue, 8 Jan 2019 11:34:44 +0100 From: Cornelia Huck To: Michael Mueller Cc: Pierre Morel , KVM Mailing List , Linux-S390 Mailing List , linux-kernel@vger.kernel.org, Martin Schwidefsky , Heiko Carstens , Christian Borntraeger , Janosch Frank , David Hildenbrand , Halil Pasic Subject: Re: [PATCH v5 10/15] KVM: s390: add functions to (un)register GISC with GISA Message-ID: <20190108113444.56e76f13.cohuck@redhat.com> In-Reply-To: References: <20181219191756.57973-1-mimu@linux.ibm.com> <20181219191756.57973-11-mimu@linux.ibm.com> <20190104141836.0ca98a77.cohuck@redhat.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.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Tue, 08 Jan 2019 10:34:51 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 7 Jan 2019 18:38:02 +0100 Michael Mueller wrote: > On 04.01.19 14:19, Cornelia Huck wrote: > > On Wed, 2 Jan 2019 18:29:00 +0100 > > Pierre Morel wrote: > > > >> On 19/12/2018 20:17, Michael Mueller wrote: > >>> Add the IAM (Interruption Alert Mask) to the architecture specific > >>> kvm struct. This mask in the GISA is used to define for which ISC > >>> a GIB alert can be issued. > >>> > >>> The functions kvm_s390_gisc_register() and kvm_s390_gisc_unregister() > >>> are used to (un)register a GISC (guest ISC) with a virtual machine and > >>> its GISA. > >>> > >>> Upon successful completion, kvm_s390_gisc_register() returns the > >>> ISC to be used for GIB alert interruptions. A negative return code > >>> indicates an error during registration. > >>> > >>> Theses functions will be used by other adapter types like AP and PCI to > >>> request pass-through interruption support. > >>> > >>> Signed-off-by: Michael Mueller > >>> --- > >>> arch/s390/include/asm/kvm_host.h | 9 ++++++ > >>> arch/s390/kvm/interrupt.c | 66 ++++++++++++++++++++++++++++++++++++++++ > >>> 2 files changed, 75 insertions(+) > >>> > > > >>> +int kvm_s390_gisc_register(struct kvm *kvm, u32 gisc) > >>> +{ > >>> + if (!kvm->arch.gib_in_use) > >>> + return -ENODEV; > >>> + if (gisc > MAX_ISC) > >>> + return -ERANGE; > >>> + > >>> + spin_lock(&kvm->arch.iam_ref_lock); > >>> + if (kvm->arch.iam_ref_count[gisc] == 0) > >>> + kvm->arch.iam |= 0x80 >> gisc; > >>> + kvm->arch.iam_ref_count[gisc]++; > >>> + if (kvm->arch.iam_ref_count[gisc] == 1) > >>> + set_iam(kvm->arch.gisa, kvm->arch.iam); > >> > >> testing the set_iam return value? > >> Even it should be fine if the caller works correctly, this is done > >> before GISA is ever used. > > There is a rc but a check here is not required. > > There are three cases: > > a) This is the first ISC that gets registered, then the GISA is > not in use and IAM is set in the GISA. > > b) A second ISC gets registered and the GISA is *not* in the > alert list. Then the IAM is set here as well. > > c) A second ISC gets registered and the GISA is in the > alert list. Then the IAM is intentionally not set here > by set_iam(). It will be restored by get_ipm() with > the new IAM value by the gib alert processing code. > > > > > > My feeling is that checking the return code is a good idea, even if it > > Should Never Fail(tm). > > > >> > >>> + spin_unlock(&kvm->arch.iam_ref_lock); > >>> + > >>> + return gib->nisc; > >>> +} > >>> +EXPORT_SYMBOL_GPL(kvm_s390_gisc_register); > >>> + > >>> +int kvm_s390_gisc_unregister(struct kvm *kvm, u32 gisc) > >>> +{ > >>> + int rc = 0; > >>> + > >>> + if (!kvm->arch.gib_in_use) > >>> + return -ENODEV; > >>> + if (gisc > MAX_ISC) > >>> + return -ERANGE; > >>> + > >>> + spin_lock(&kvm->arch.iam_ref_lock); > >>> + if (kvm->arch.iam_ref_count[gisc] == 0) { > >>> + rc = -EINVAL; > >>> + goto out; > >>> + } > >>> + kvm->arch.iam_ref_count[gisc]--; > >>> + if (kvm->arch.iam_ref_count[gisc] == 0) { > >>> + kvm->arch.iam &= ~(0x80 >> gisc); > >>> + set_iam(kvm->arch.gisa, kvm->arch.iam); > > > > Any chance of this function failing here? If yes, would there be any > > implications? > > It is the same here. I'm not sure that I follow: This is the reverse operation (unregistering the gisc). Can we rely on get_ipm() to do any fixup later? Is that a problem for the caller? Apologies if I sound confused (well, that's because I probably am); this is hard to review without access to the hardware specification. > > > > >>> + } > >>> +out: > >>> + spin_unlock(&kvm->arch.iam_ref_lock); > >>> + > >>> + return rc; > >>> +} > >>> +EXPORT_SYMBOL_GPL(kvm_s390_gisc_unregister); > >>> + > >>> void kvm_s390_gib_destroy(void) > >>> { > >>> if (!gib) > >>> > >> > >> > > >