Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp4743126imu; Tue, 8 Jan 2019 05:39:08 -0800 (PST) X-Google-Smtp-Source: ALg8bN4JOnraPwz5gesGsNo5SjmNXbzGXx7N/A1QLWzpQ2VMfI/pQLn+hMbyAn1fIukAJ9SveMoI X-Received: by 2002:a17:902:4681:: with SMTP id p1mr1877940pld.184.1546954748735; Tue, 08 Jan 2019 05:39:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546954748; cv=none; d=google.com; s=arc-20160816; b=Pn6YQE3+UmMszlfNuJS0hfM65W2hek7tp7JuG177/jze5yX4zytlVky2V1wdXafyIH W607yvIj0KiNK0S0A+rHzteICAZJLHcJxW+nCQ5TZDX1DqeCYX0jXkNHmso0c/bsrTIV vW/23o5dwbEkx8zdjqZtC/mj0Jm6SalZGA+WwCefcUkfx7aM1SYcjGmH29tYyeq7Cd37 F3EEruMCGWyCNke02y1mZKOWOYKJQd4RvQyomMJyDK0Hn3t+xIpt6KslhxKpGmC+w6Fr 7UbPqgr5ZdnBl8q2Ft2Rb+VwWB/kt0gqNY5B68MU1bi5KfEd+/08uqBYYnMisqX4JJy5 xGqA== 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=HDOlvsfYpoXS8Avu2zfPfvZF5WebTMybBxyF1swOOmc=; b=f1tksyXU78qQqDXc1qRbjK+11ERjwRvHfwaAgtuvdXf+hXPhQsHcu3vEGPs5yUPXzn fpzU2Iqt2mXmUqDoDhnV1xLLbsgP6x6E4oSeioHajRc2urcZQkKTM9DK6kOF8KY+iBr7 osN1cqFwIYDkR74ZHg6E+erDXwy/0H5cEgyGBERtBkOX7Qt+wvy72WayxMipJiTiQXpP q9ffVqhgTC5T3D2MmzOt2sQN/UpYd7Zcq7gtvkIU1RIQc3SnPYzcwpqTjsrBG15scoM7 ftzOfP76+ZUFEekp30q4Y0JknJfoPr5ZQ3i7X1ptBs0d7f6FavarWf+AnB1t1EfdIzzY uWKg== 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 w1si64004489pgi.66.2019.01.08.05.38.53; Tue, 08 Jan 2019 05:39:08 -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 S1728559AbfAHNfg (ORCPT + 99 others); Tue, 8 Jan 2019 08:35:36 -0500 Received: from mx1.redhat.com ([209.132.183.28]:48358 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727980AbfAHNff (ORCPT ); Tue, 8 Jan 2019 08:35:35 -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 6AD90142C00; Tue, 8 Jan 2019 13:35:35 +0000 (UTC) Received: from gondolin (dhcp-192-222.str.redhat.com [10.33.192.222]) by smtp.corp.redhat.com (Postfix) with ESMTP id BF5205C21E; Tue, 8 Jan 2019 13:35:29 +0000 (UTC) Date: Tue, 8 Jan 2019 14:35:27 +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: <20190108143527.7a727521.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> <20190108113444.56e76f13.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.38]); Tue, 08 Jan 2019 13:35:35 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 8 Jan 2019 14:07:06 +0100 Michael Mueller wrote: > On 08.01.19 11:34, Cornelia Huck wrote: > > 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. > > I think nothing will happen because the AP CLR IRQ call (Pierre?) > has already taken offline the last AP device. But doesn't that rely on behaviour by the caller? If the caller does weird and broken stuff, this function should return an error, shouldn't it? > > > > > >> > >>> > >>>>> + } > >>>>> +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) > >>>>> > >>>> > >>>> > >>> > >> > > >