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=-14.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 CB908C4338F for ; Wed, 28 Jul 2021 10:40:41 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 996D060C3F for ; Wed, 28 Jul 2021 10:40:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 996D060C3F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; 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=hxKLmuVJn1qYajyhKJMTzv75C4e6wA/mtLwx9o54J38=; b=EFCp+1lWoRuCK5 bcUqEifd3SIuOTbcXz8tjqQUs+FYlRmKZzq62tfcSfZyQTI9UirT9rr3SHNWzArdeVvwerTQJ50vL /SF7GqcpeP5TKibE9QqMGZ1igbySrJbbj2NHRfx0MAFoh4tWf05p36RCy0TZi72cFVo5noowtEt4e wOFOUH6rPPLbv8D8eLpsP6ExrucG7zSEE1I6+fxruKSqL+IRzCBN38p8mpB5WpFxvORWjom9XFaDq 97usoc9r8uM+qbUeS15ggXaFxgX0qZrVWmCFE+k1pTG1nuvUAH+DYzlV5qnU3vlyIgdFIS4D3tkjc yHCEGjn37qK+EI8fEfeQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1m8gxW-000QYX-HY; Wed, 28 Jul 2021 10:38:42 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1m8gxS-000QXK-2a for linux-arm-kernel@lists.infradead.org; Wed, 28 Jul 2021 10:38:39 +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 D598C60F9B; Wed, 28 Jul 2021 10:38:37 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] 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 1m8gxP-001VeA-OZ; Wed, 28 Jul 2021 11:38:35 +0100 Date: Wed, 28 Jul 2021 11:38:35 +0100 Message-ID: <87wnpad8pg.wl-maz@kernel.org> From: Marc Zyngier To: Will Deacon Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, qperret@google.com, dbrazdil@google.com, Srivatsa Vaddagiri , Shanker R Donthineni , James Morse , Suzuki K Poulose , Alexandru Elisei , kernel-team@android.com Subject: Re: [PATCH 06/16] KVM: arm64: Force a full unmap on vpcu reinit In-Reply-To: <20210727181132.GE19173@willie-the-truck> References: <20210715163159.1480168-1-maz@kernel.org> <20210715163159.1480168-7-maz@kernel.org> <20210727181132.GE19173@willie-the-truck> 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: 185.219.108.64 X-SA-Exim-Rcpt-To: will@kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, qperret@google.com, dbrazdil@google.com, vatsa@codeaurora.org, sdonthineni@nvidia.com, james.morse@arm.com, suzuki.poulose@arm.com, alexandru.elisei@arm.com, 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-20210728_033838_191357_56AEA421 X-CRM114-Status: GOOD ( 32.74 ) 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 Tue, 27 Jul 2021 19:11:33 +0100, Will Deacon wrote: > > On Thu, Jul 15, 2021 at 05:31:49PM +0100, Marc Zyngier wrote: > > As we now keep information in the S2PT, we must be careful not > > to keep it across a VM reboot, which could otherwise lead to > > interesting problems. > > > > Make sure that the S2 is completely discarded on reset of > > a vcpu, and remove the flag that enforces the MMIO check. > > > > Signed-off-by: Marc Zyngier > > --- > > arch/arm64/kvm/arm.c | 8 +++++++- > > 1 file changed, 7 insertions(+), 1 deletion(-) > > > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c > > index 97ab1512c44f..b0d2225190d2 100644 > > --- a/arch/arm64/kvm/arm.c > > +++ b/arch/arm64/kvm/arm.c > > @@ -1096,12 +1096,18 @@ static int kvm_arch_vcpu_ioctl_vcpu_init(struct kvm_vcpu *vcpu, > > * ensuring that the data side is always coherent. We still > > * need to invalidate the I-cache though, as FWB does *not* > > * imply CTR_EL0.DIC. > > + * > > + * If the MMIO guard was enabled, we pay the price of a full > > + * unmap to get back to a sane state (and clear the flag). > > */ > > if (vcpu->arch.has_run_once) { > > - if (!cpus_have_final_cap(ARM64_HAS_STAGE2_FWB)) > > + if (!cpus_have_final_cap(ARM64_HAS_STAGE2_FWB) || > > + test_bit(KVM_ARCH_FLAG_MMIO_GUARD, &vcpu->kvm->arch.flags)) > > stage2_unmap_vm(vcpu->kvm); > > else > > icache_inval_all_pou(); > > + > > + clear_bit(KVM_ARCH_FLAG_MMIO_GUARD, &vcpu->kvm->arch.flags); > > What prevents this racing with another vCPU trying to set the bit? Not much. We could take the kvm lock on both ends to serialize it, but that's pretty ugly. And should we care? What is the semantic of resetting a vcpu while another is still running? If we want to support this sort of behaviour, then our tracking is totally bogus, because it is VM-wide. And you don't even have to play with that bit from another vcpu: all the information is lost at the point where we unmap the S2 PTs. Maybe an alternative is to move this to the halt/reboot PSCI handlers, making it clearer what we expect? 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