Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp4787719imu; Tue, 29 Jan 2019 07:31:36 -0800 (PST) X-Google-Smtp-Source: ALg8bN7mL0EayUxSKj6uS9c+chlvjHlkvCW6ZSB1owuaJUeUD9DhUo23QUX/u26askKWWkkbPNwF X-Received: by 2002:a62:1212:: with SMTP id a18mr27468424pfj.217.1548775895954; Tue, 29 Jan 2019 07:31:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548775895; cv=none; d=google.com; s=arc-20160816; b=T9gL1EgXILHoxKPKwWmcf/mS/dmHYJsJ7iOj2Xjt//1dX9h+4EvNQQFAb6SfBzoO0j aNKrNI4dV4seOYKZ+8+jI4ZcdWZuHFDTrjDu5UhKdt9v74CuM0tpDx3ENGnJE1fbvNby HmYSpCkGAXGaF3+O9/fHg3z6xTj4/44PBUeuDkg5IXPm/SLNLOiPY9+FP9EZcODrETof ygy5eK7/KmnGmGO5E7EfsPn8WpKuuvJs7Wv4sdA4UtH1cQ5sTAKOGfHXJRMk2YlDyEh0 K4kAVWRI6nKlDDhEGOSmFfTykGd0ZFWSqPFLI59h/T6gbuZ895P4ALir1jdEIxDAR7OG B6mA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :organization:from:references:cc:to:subject:reply-to; bh=m8Z3bq/zIlegP+pz06PlDZcnjuWnR8RJxCFgsMD+184=; b=bDbEQBi9Kj1LU7HkFVeSKdffplrTNsmhvgSReUChQCm24wjp7gNJYROSfNi+IMS38y xQHVWQQ55n5ZY7RzDUrqRwo4slraswbAjzz00x8kzP4J7JJA7JYeWYgrB7Y+gNhiX7cU F9VJc7Qhz91vMongEUZep4fAUcfLeO8FchKmkXgF7MoesssIKu94Z2ADO8BSzT8C7F/t oCkM0IcjneqfAw8fM0k/KV8JzPY+VOUZZb0yzCgvpHywOt6CwKPyEpWB+o1Zd1X7tCk7 2cm1qKnHwN/jffZwppne3HTuUjDFBFbZpeT1Je0HRECmbahHCSu+bah6lQap4KyfiLY6 yNXw== 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=ibm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g4si37139848pfm.85.2019.01.29.07.31.20; Tue, 29 Jan 2019 07:31:35 -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=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727824AbfA2P3t (ORCPT + 99 others); Tue, 29 Jan 2019 10:29:49 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:33016 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725788AbfA2P3t (ORCPT ); Tue, 29 Jan 2019 10:29:49 -0500 Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x0TFT3fD051903 for ; Tue, 29 Jan 2019 10:29:48 -0500 Received: from e06smtp05.uk.ibm.com (e06smtp05.uk.ibm.com [195.75.94.101]) by mx0a-001b2d01.pphosted.com with ESMTP id 2qaqsyes4y-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 29 Jan 2019 10:29:48 -0500 Received: from localhost by e06smtp05.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 29 Jan 2019 15:29:45 -0000 Received: from b06cxnps4074.portsmouth.uk.ibm.com (9.149.109.196) by e06smtp05.uk.ibm.com (192.168.101.135) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Tue, 29 Jan 2019 15:29:42 -0000 Received: from d06av23.portsmouth.uk.ibm.com (d06av23.portsmouth.uk.ibm.com [9.149.105.59]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x0TFTfPn8782080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 29 Jan 2019 15:29:41 GMT Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E2D78A4040; Tue, 29 Jan 2019 15:29:40 +0000 (GMT) Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 71B98A4055; Tue, 29 Jan 2019 15:29:40 +0000 (GMT) Received: from [9.152.224.122] (unknown [9.152.224.122]) by d06av23.portsmouth.uk.ibm.com (Postfix) with ESMTP; Tue, 29 Jan 2019 15:29:40 +0000 (GMT) Reply-To: mimu@linux.ibm.com Subject: Re: [PATCH v6 12/13] KVM: s390: add gib_alert_irq_handler() To: Halil Pasic Cc: KVM Mailing List , Linux-S390 Mailing List , linux-kernel@vger.kernel.org, Martin Schwidefsky , Heiko Carstens , Christian Borntraeger , Janosch Frank , David Hildenbrand , Cornelia Huck , Pierre Morel References: <20190124125939.130763-1-mimu@linux.ibm.com> <20190124125939.130763-13-mimu@linux.ibm.com> <20190129142642.3a94a5f1@oc2783563651> From: Michael Mueller Organization: IBM Date: Tue, 29 Jan 2019 16:29:40 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190129142642.3a94a5f1@oc2783563651> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 19012915-0020-0000-0000-0000030D5F20 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19012915-0021-0000-0000-0000215E6459 Message-Id: <3819a46e-b2cf-96e3-b3b8-6cdf35eeb616@linux.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-01-29_10:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901290116 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 29.01.19 14:26, Halil Pasic wrote: > On Thu, 24 Jan 2019 13:59:38 +0100 > Michael Mueller wrote: > >> The patch implements a handler for GIB alert interruptions >> on the host. Its task is to alert guests that interrupts are >> pending for them. >> >> A GIB alert interrupt statistic counter is added as well: >> >> $ cat /proc/interrupts >> CPU0 CPU1 >> ... >> GAL: 23 37 [I/O] GIB Alert >> ... >> >> Signed-off-by: Michael Mueller > [..] >> +/** >> + * gisa_get_ipm_or_restore_iam - return IPM or restore GISA IAM >> + * >> + * @gi: gisa interrupt struct to work on >> + * >> + * Atomically restores the interruption alert mask if none of the >> + * relevant ISCs are pending and return the IPM. > > The word 'relevant' probably reflects some previous state. It does not > bother me too much. "relevant" refers to the ISCs handled by the GAL mechanism, i.e those registered in the kvm->arch.gisa_int.alert.mask. > > [..] > >> >> +static void __airqs_kick_single_vcpu(struct kvm *kvm, u8 deliverable_mask) >> +{ >> + int vcpu_id, online_vcpus = atomic_read(&kvm->online_vcpus); >> + struct kvm_s390_gisa_interrupt *gi = &kvm->arch.gisa_int; >> + struct kvm_vcpu *vcpu; >> + >> + for_each_set_bit(vcpu_id, kvm->arch.idle_mask, online_vcpus) { >> + vcpu = kvm_get_vcpu(kvm, vcpu_id); >> + if (psw_ioint_disabled(vcpu)) >> + continue; >> + deliverable_mask &= (u8)(vcpu->arch.sie_block->gcr[6] >> 24); >> + if (deliverable_mask) { >> + /* lately kicked but not yet running */ > > How about /* was kicked but didn't run yet */? what is the difference here... > >> + if (test_and_set_bit(vcpu_id, gi->kicked_mask)) >> + return; >> + kvm_s390_vcpu_wakeup(vcpu); >> + return; >> + } >> + } >> +} >> + > > [..] > >> +static void process_gib_alert_list(void) >> +{ >> + struct kvm_s390_gisa_interrupt *gi; >> + struct kvm_s390_gisa *gisa; >> + struct kvm *kvm; >> + u32 final, origin = 0UL; >> + >> + do { >> + /* >> + * If the NONE_GISA_ADDR is still stored in the alert list >> + * origin, we will leave the outer loop. No further GISA has >> + * been added to the alert list by millicode while processing >> + * the current alert list. >> + */ >> + final = (origin & NONE_GISA_ADDR); >> + /* >> + * Cut off the alert list and store the NONE_GISA_ADDR in the >> + * alert list origin to avoid further GAL interruptions. >> + * A new alert list can be build up by millicode in parallel >> + * for guests not in the yet cut-off alert list. When in the >> + * final loop, store the NULL_GISA_ADDR instead. This will re- >> + * enable GAL interruptions on the host again. >> + */ >> + origin = xchg(&gib->alert_list_origin, >> + (!final) ? NONE_GISA_ADDR : NULL_GISA_ADDR); >> + /* >> + * Loop through the just cut-off alert list and start the >> + * gisa timers to kick idle vcpus to consume the pending >> + * interruptions asap. >> + */ >> + while (origin & GISA_ADDR_MASK) { >> + gisa = (struct kvm_s390_gisa *)(u64)origin; >> + origin = gisa->next_alert; >> + gisa->next_alert = (u32)(u64)gisa; >> + kvm = container_of(gisa, struct sie_page2, gisa)->kvm; >> + gi = &kvm->arch.gisa_int; >> + if (hrtimer_active(&gi->timer)) >> + hrtimer_cancel(&gi->timer); >> + hrtimer_start(&gi->timer, 0, HRTIMER_MODE_REL); >> + } >> + } while (!final); >> + >> +} >> + >> void kvm_s390_gisa_clear(struct kvm *kvm) >> { >> struct kvm_s390_gisa_interrupt *gi = &kvm->arch.gisa_int; >> >> if (!gi->origin) >> return; >> - memset(gi->origin, 0, sizeof(struct kvm_s390_gisa)); >> - gi->origin->next_alert = (u32)(u64)gi->origin; >> + gisa_clear_ipm(gi->origin); > > This could be a separate patch. I would like little more explanation > to this. I can break at out as I had before... ;) > >> VM_EVENT(kvm, 3, "gisa 0x%pK cleared", gi->origin); >> } >> >> @@ -2940,13 +3078,25 @@ void kvm_s390_gisa_init(struct kvm *kvm) >> gi->origin = &kvm->arch.sie_page2->gisa; >> gi->alert.mask = 0; >> spin_lock_init(&gi->alert.ref_lock); >> - kvm_s390_gisa_clear(kvm); >> + gi->expires = 50 * 1000; /* 50 usec */ > > I blindly trust your choice here ;) You know I will increase it to 1 ms together with the change that I proposed. (gisa_get_ipm_or_restore_iam() in kvm_s390_handle_wait()). > >> + hrtimer_init(&gi->timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL); >> + gi->timer.function = gisa_vcpu_kicker; >> + memset(gi->origin, 0, sizeof(struct kvm_s390_gisa)); >> + gi->origin->next_alert = (u32)(u64)gi->origin; >> VM_EVENT(kvm, 3, "gisa 0x%pK initialized", gi->origin); >> } >> >> void kvm_s390_gisa_destroy(struct kvm *kvm) >> { >> - kvm->arch.gisa_int.origin = NULL; >> + struct kvm_s390_gisa_interrupt *gi = &kvm->arch.gisa_int; >> + >> + if (!gi->origin) >> + return; >> + hrtimer_cancel(&gi->timer); > > I'm not sure this cancel here is sufficient. > >> + WRITE_ONCE(gi->alert.mask, 0); >> + while (gisa_in_alert_list(gi->origin)) >> + cpu_relax(); > > If you end up waiting here, I guess, it's likely that a new > timer is going to get set up right after we do > gisa->next_alert = (u32)(u64)gisa; > in process_gib_alert_list(). There will be no vcpus available anymore at this time, whence none will be kicked by the timer function. Thus canceling the timer will be sufficient after the loop. I have addressed the message as well, but will write it into the KVM trace. void kvm_s390_gisa_destroy(struct kvm *kvm) { - kvm->arch.gisa_int.origin = NULL; + struct kvm_s390_gisa_interrupt *gi = &kvm->arch.gisa_int; + + if (!gi->origin) + return; + if (gi->alert.mask) + KVM_EVENT(3, "vm 0x%pK has unexpected iam 0x%02x", + kvm, gi->alert.mask); + while (gisa_in_alert_list(gi->origin)) + cpu_relax(); + hrtimer_cancel(&gi->timer); + gi->origin = NULL; } > >> + gi->origin = NULL; >> } >> >> /** >> @@ -3037,11 +3187,23 @@ int kvm_s390_gisc_unregister(struct kvm *kvm, u32 gisc) >> } >> EXPORT_SYMBOL_GPL(kvm_s390_gisc_unregister); >> > > > Overall, there are couple of things I would prefer done differently, > but better something working today that something prefect in 6 months. > In that sense, provided my comment regarding destroy is addressed: > > Acked-by: Halil Pasic > Michael