From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 15FE4C433ED for ; Mon, 10 May 2021 17:44:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D98E361481 for ; Mon, 10 May 2021 17:44:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232760AbhEJRp5 (ORCPT ); Mon, 10 May 2021 13:45:57 -0400 Received: from mail.kernel.org ([198.145.29.99]:51320 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232617AbhEJRp4 (ORCPT ); Mon, 10 May 2021 13:45:56 -0400 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D84DF611C9; Mon, 10 May 2021 17:44:51 +0000 (UTC) Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1lg9xZ-000W26-OP; Mon, 10 May 2021 18:44:49 +0100 Date: Mon, 10 May 2021 18:44:49 +0100 Message-ID: <87sg2uo54e.wl-maz@kernel.org> From: Marc Zyngier To: Mark Rutland Cc: linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, James Morse , Suzuki K Poulose , Alexandru Elisei , Eric Auger , Hector Martin , kernel-team@android.com Subject: Re: [PATCH v3 3/9] KVM: arm64: vgic: Be tolerant to the lack of maintenance interrupt In-Reply-To: <20210510161907.GD92897@C02TD0UTHF1T.local> References: <20210510134824.1910399-1-maz@kernel.org> <20210510134824.1910399-4-maz@kernel.org> <20210510161907.GD92897@C02TD0UTHF1T.local> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: mark.rutland@arm.com, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, james.morse@arm.com, suzuki.poulose@arm.com, alexandru.elisei@arm.com, eric.auger@redhat.com, marcan@marcan.st, kernel-team@android.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Mon, 10 May 2021 17:19:07 +0100, Mark Rutland wrote: > > On Mon, May 10, 2021 at 02:48:18PM +0100, Marc Zyngier wrote: > > As it turns out, not all the interrupt controllers are able to > > expose a vGIC maintenance interrupt as a distrete signal. > > And to be fair, it doesn't really matter as all we require is > > for *something* to kick us out of guest mode out way or another. > > > > On systems that do not expose a maintenance interrupt as such, > > there are two outcomes: > > > > - either the virtual CPUIF does generate an interrupt, and > > by the time we are back to the host the interrupt will have long > > been disabled (as we set ICH_HCR_EL2.EN to 0 on exit). In this case, > > interrupt latency is as good as it gets. > > > > - or some other event (physical timer) will take us out of the guest > > anyway, and the only drawback is a bad interrupt latency. > > IIRC we won't have a a guaranteed schedular tick for NO_HZ_FULL, so in > that case we'll either need to set a period software maintenance > interrupt, or reject this combination at runtime (either when trying to > isolate the dynticks CPUs, or when trying to create a VM). That's a good point. On sensible systems, the maintenance interrupt is a standard GIC PPI that requires enabling, and that is all that KVM requires (the maintenance interrupt is only used as an exit mechanism and will be disabled before reaching the handler). On the M1, owing to the lack of a per-CPU interrupt controller, there is nothing to enable. The virtual CPU interface will fire at will and take us out of the guest in a timely manner. So maybe instead of relaxing the requirement for a maintenance interrupt, we should only bypass the checks if the root interrupt controller advertises that it is safe to do so, making it a M1-specific hack. Thanks, M. -- Without deviation from the norm, progress is not possible. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7893EC433B4 for ; Mon, 10 May 2021 17:44:59 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id DDE0060249 for ; Mon, 10 May 2021 17:44:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DDE0060249 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvmarm-bounces@lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 505944B396; Mon, 10 May 2021 13:44:58 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7X63tJzh9lav; Mon, 10 May 2021 13:44:55 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 9FAFB4B815; Mon, 10 May 2021 13:44:55 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 5B0644B7E8 for ; Mon, 10 May 2021 13:44:54 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22sBPkIyb3tF for ; Mon, 10 May 2021 13:44:53 -0400 (EDT) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 17D454B7B5 for ; Mon, 10 May 2021 13:44:53 -0400 (EDT) Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D84DF611C9; Mon, 10 May 2021 17:44:51 +0000 (UTC) Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1lg9xZ-000W26-OP; Mon, 10 May 2021 18:44:49 +0100 Date: Mon, 10 May 2021 18:44:49 +0100 Message-ID: <87sg2uo54e.wl-maz@kernel.org> From: Marc Zyngier To: Mark Rutland Subject: Re: [PATCH v3 3/9] KVM: arm64: vgic: Be tolerant to the lack of maintenance interrupt In-Reply-To: <20210510161907.GD92897@C02TD0UTHF1T.local> References: <20210510134824.1910399-1-maz@kernel.org> <20210510134824.1910399-4-maz@kernel.org> <20210510161907.GD92897@C02TD0UTHF1T.local> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: mark.rutland@arm.com, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, james.morse@arm.com, suzuki.poulose@arm.com, alexandru.elisei@arm.com, eric.auger@redhat.com, marcan@marcan.st, kernel-team@android.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Cc: kvm@vger.kernel.org, kernel-team@android.com, Hector Martin , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Mon, 10 May 2021 17:19:07 +0100, Mark Rutland wrote: > > On Mon, May 10, 2021 at 02:48:18PM +0100, Marc Zyngier wrote: > > As it turns out, not all the interrupt controllers are able to > > expose a vGIC maintenance interrupt as a distrete signal. > > And to be fair, it doesn't really matter as all we require is > > for *something* to kick us out of guest mode out way or another. > > > > On systems that do not expose a maintenance interrupt as such, > > there are two outcomes: > > > > - either the virtual CPUIF does generate an interrupt, and > > by the time we are back to the host the interrupt will have long > > been disabled (as we set ICH_HCR_EL2.EN to 0 on exit). In this case, > > interrupt latency is as good as it gets. > > > > - or some other event (physical timer) will take us out of the guest > > anyway, and the only drawback is a bad interrupt latency. > > IIRC we won't have a a guaranteed schedular tick for NO_HZ_FULL, so in > that case we'll either need to set a period software maintenance > interrupt, or reject this combination at runtime (either when trying to > isolate the dynticks CPUs, or when trying to create a VM). That's a good point. On sensible systems, the maintenance interrupt is a standard GIC PPI that requires enabling, and that is all that KVM requires (the maintenance interrupt is only used as an exit mechanism and will be disabled before reaching the handler). On the M1, owing to the lack of a per-CPU interrupt controller, there is nothing to enable. The virtual CPU interface will fire at will and take us out of the guest in a timely manner. So maybe instead of relaxing the requirement for a maintenance interrupt, we should only bypass the checks if the root interrupt controller advertises that it is safe to do so, making it a M1-specific hack. Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 66CD7C433B4 for ; Mon, 10 May 2021 18:05:09 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id CAC2661481 for ; Mon, 10 May 2021 18:05:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CAC2661481 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:Subject:Cc:To: From:Message-ID:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=o+nmNCnAWplKBjgIbn8OVe/h8qL2FpTUEAaM6NZeZZM=; b=Du5AZ/4EgVFl1mMNWbaHYyHvQ dipFoGR8r9CkRthB4Wl8d2U2Vj5kBJA5WzjkybsZJCVwwFhvCQp+pR95uYf60nZVSpifiVpeTtfGy AcyvPOm2Btu8VPY09yHRUxnZEgmmRz/CwmiKNNgwRSQQiMo5YAKWxgOg56P3XIFlFrIY0bL99I+6b 66sjQhbM/tlRw0XkVnUxBOH08WfhK7/3n/aNRT4oTLUvaTdAL43mbh3vhMq08AWb1GgfBC47mCQIZ IQlkozFLupxJ0PXxrS7f+EaDlRdRk7aXWYJVk6W0NFfpHE9EPiHfSPfYTXU0Wm3Shl0xucfm0GsHi 6dTPNkWRg==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lgAFp-00FLkh-Vh; Mon, 10 May 2021 18:03:42 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lg9xf-00FF8Z-U1 for linux-arm-kernel@desiato.infradead.org; Mon, 10 May 2021 17:44:55 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Type:MIME-Version:References: In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=yeFrlooFEmEvuihT5j1kZ77PCAofjOlBgt2amC0ujBg=; b=j4GodF3WiUBnkgi51Vw+SLXeqd NcC2HjjPOR8pbvjvaGspg0ucvLOU4Fo8NYezDkAlWQLv6MRypn8OGR9KqzJIrxeSfCwA6SUPsNPTk MAxdx2iW9Gi/47jvol7Fu7tZPuRR3l+mLlNvnm/+Egwd6UuOoFWvAXvjR3+7HQ5fKVQ9HChqWxKQs gM1NkW0ftNEQgfJDYXohG9SLjEzBoOjzvzxqx4Koo0Ed/0xFVhum/ArYcjSiBbsgGxO4F6lEO3Q7g CMpw2pDBCRXylkPy6paPJwF7DWW/mbcBrux/0J4gFBkkW9GaEXpAKETEoVDJblod2fxYIFjn7z8qv hEy2ToCw==; Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lg9xc-008zwK-9A for linux-arm-kernel@lists.infradead.org; Mon, 10 May 2021 17:44:54 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D84DF611C9; Mon, 10 May 2021 17:44:51 +0000 (UTC) Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1lg9xZ-000W26-OP; Mon, 10 May 2021 18:44:49 +0100 Date: Mon, 10 May 2021 18:44:49 +0100 Message-ID: <87sg2uo54e.wl-maz@kernel.org> From: Marc Zyngier To: Mark Rutland Cc: linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, James Morse , Suzuki K Poulose , Alexandru Elisei , Eric Auger , Hector Martin , kernel-team@android.com Subject: Re: [PATCH v3 3/9] KVM: arm64: vgic: Be tolerant to the lack of maintenance interrupt In-Reply-To: <20210510161907.GD92897@C02TD0UTHF1T.local> References: <20210510134824.1910399-1-maz@kernel.org> <20210510134824.1910399-4-maz@kernel.org> <20210510161907.GD92897@C02TD0UTHF1T.local> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: mark.rutland@arm.com, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, james.morse@arm.com, suzuki.poulose@arm.com, alexandru.elisei@arm.com, eric.auger@redhat.com, marcan@marcan.st, kernel-team@android.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210510_104452_366516_876D52B8 X-CRM114-Status: GOOD ( 28.99 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, 10 May 2021 17:19:07 +0100, Mark Rutland wrote: > > On Mon, May 10, 2021 at 02:48:18PM +0100, Marc Zyngier wrote: > > As it turns out, not all the interrupt controllers are able to > > expose a vGIC maintenance interrupt as a distrete signal. > > And to be fair, it doesn't really matter as all we require is > > for *something* to kick us out of guest mode out way or another. > > > > On systems that do not expose a maintenance interrupt as such, > > there are two outcomes: > > > > - either the virtual CPUIF does generate an interrupt, and > > by the time we are back to the host the interrupt will have long > > been disabled (as we set ICH_HCR_EL2.EN to 0 on exit). In this case, > > interrupt latency is as good as it gets. > > > > - or some other event (physical timer) will take us out of the guest > > anyway, and the only drawback is a bad interrupt latency. > > IIRC we won't have a a guaranteed schedular tick for NO_HZ_FULL, so in > that case we'll either need to set a period software maintenance > interrupt, or reject this combination at runtime (either when trying to > isolate the dynticks CPUs, or when trying to create a VM). That's a good point. On sensible systems, the maintenance interrupt is a standard GIC PPI that requires enabling, and that is all that KVM requires (the maintenance interrupt is only used as an exit mechanism and will be disabled before reaching the handler). On the M1, owing to the lack of a per-CPU interrupt controller, there is nothing to enable. The virtual CPU interface will fire at will and take us out of the guest in a timely manner. So maybe instead of relaxing the requirement for a maintenance interrupt, we should only bypass the checks if the root interrupt controller advertises that it is safe to do so, making it a M1-specific hack. Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel