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.0 required=3.0 tests=BAYES_00,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 4A7E8C4338F for ; Wed, 28 Jul 2021 09:57:39 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id BC3D660F9D for ; Wed, 28 Jul 2021 09:57:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org BC3D660F9D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 493714066E; Wed, 28 Jul 2021 05:57:38 -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 BMZbaMN8tW1v; Wed, 28 Jul 2021 05:57:36 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id E0A1D4029F; Wed, 28 Jul 2021 05:57:36 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 6C7A64B086 for ; Wed, 28 Jul 2021 05:57:35 -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 SPYeylcT7HEI for ; Wed, 28 Jul 2021 05:57:34 -0400 (EDT) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 3E17B4A95C for ; Wed, 28 Jul 2021 05:57:34 -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 4623360E78; Wed, 28 Jul 2021 09:57:33 +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 1m8gJf-001V9M-4p; Wed, 28 Jul 2021 10:57:31 +0100 Date: Wed, 28 Jul 2021 10:57:30 +0100 Message-ID: <8735ryep6d.wl-maz@kernel.org> From: Marc Zyngier To: Will Deacon Subject: Re: [PATCH 04/16] KVM: arm64: Add MMIO checking infrastructure In-Reply-To: <20210727181107.GC19173@willie-the-truck> References: <20210715163159.1480168-1-maz@kernel.org> <20210715163159.1480168-5-maz@kernel.org> <20210727181107.GC19173@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 Cc: kvm@vger.kernel.org, kernel-team@android.com, Srivatsa Vaddagiri , linux-kernel@vger.kernel.org, Shanker R Donthineni , 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 Tue, 27 Jul 2021 19:11:08 +0100, Will Deacon wrote: > > On Thu, Jul 15, 2021 at 05:31:47PM +0100, Marc Zyngier wrote: > > Introduce the infrastructure required to identify an IPA region > > that is expected to be used as an MMIO window. > > > > This include mapping, unmapping and checking the regions. Nothing > > calls into it yet, so no expected functional change. > > > > Signed-off-by: Marc Zyngier > > --- > > arch/arm64/include/asm/kvm_host.h | 2 + > > arch/arm64/include/asm/kvm_mmu.h | 5 ++ > > arch/arm64/kvm/mmu.c | 115 ++++++++++++++++++++++++++++++ > > 3 files changed, 122 insertions(+) > > > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h > > index 4add6c27251f..914c1b7bb3ad 100644 > > --- a/arch/arm64/include/asm/kvm_host.h > > +++ b/arch/arm64/include/asm/kvm_host.h > > @@ -125,6 +125,8 @@ struct kvm_arch { > > #define KVM_ARCH_FLAG_RETURN_NISV_IO_ABORT_TO_USER 0 > > /* Memory Tagging Extension enabled for the guest */ > > #define KVM_ARCH_FLAG_MTE_ENABLED 1 > > + /* Gues has bought into the MMIO guard extension */ > > +#define KVM_ARCH_FLAG_MMIO_GUARD 2 > > unsigned long flags; > > > > /* > > diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h > > index b52c5c4b9a3d..f6b8fc1671b3 100644 > > --- a/arch/arm64/include/asm/kvm_mmu.h > > +++ b/arch/arm64/include/asm/kvm_mmu.h > > @@ -170,6 +170,11 @@ phys_addr_t kvm_mmu_get_httbr(void); > > phys_addr_t kvm_get_idmap_vector(void); > > int kvm_mmu_init(u32 *hyp_va_bits); > > > > +/* MMIO guard */ > > +bool kvm_install_ioguard_page(struct kvm_vcpu *vcpu, gpa_t ipa); > > +bool kvm_remove_ioguard_page(struct kvm_vcpu *vcpu, gpa_t ipa); > > +bool kvm_check_ioguard_page(struct kvm_vcpu *vcpu, gpa_t ipa); > > + > > static inline void *__kvm_vector_slot2addr(void *base, > > enum arm64_hyp_spectre_vector slot) > > { > > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c > > index 3155c9e778f0..638827c8842b 100644 > > --- a/arch/arm64/kvm/mmu.c > > +++ b/arch/arm64/kvm/mmu.c > > @@ -1120,6 +1120,121 @@ static void handle_access_fault(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa) > > kvm_set_pfn_accessed(pte_pfn(pte)); > > } > > > > +#define MMIO_NOTE ('M' << 24 | 'M' << 16 | 'I' << 8 | '0') > > Although this made me smile, maybe we should carve up the bit space a bit > more carefully ;) Also, you know somebody clever will "fix" that typo to > 'O'! They'll get to keep the pieces when the whole thing breaks! More seriously, happy to have a more elaborate allocation scheme. For the purpose of this series, it really doesn't matter. > Quentin, as the other user of this stuff at the moment, how do you see the > annotation space being allocated? Feels like we should have some 'type' > bits which decide how to parse the rest of the entry. > > > + > > +bool kvm_install_ioguard_page(struct kvm_vcpu *vcpu, gpa_t ipa) > > +{ > > + struct kvm_mmu_memory_cache *memcache; > > + struct kvm_memory_slot *memslot; > > + int ret, idx; > > + > > + if (!test_bit(KVM_ARCH_FLAG_MMIO_GUARD, &vcpu->kvm->arch.flags)) > > + return false; > > + > > + /* Must be page-aligned */ > > + if (ipa & ~PAGE_MASK) > > + return false; > > + > > + /* > > + * The page cannot be in a memslot. At some point, this will > > + * have to deal with device mappings though. > > + */ > > + idx = srcu_read_lock(&vcpu->kvm->srcu); > > + memslot = gfn_to_memslot(vcpu->kvm, ipa >> PAGE_SHIFT); > > + srcu_read_unlock(&vcpu->kvm->srcu, idx); > > What does this memslot check achieve? A new memslot could be added after > you've checked, no? If you start allowing S2 annotations to coexist with potential memory mappings, you're in for trouble. The faulting logic will happily overwrite the annotation, and that's probably not what you want. As for new (or moving) memslots, I guess they should be checked against existing annotations. > > > +/* Assumes mmu_lock taken */ > > You can use a lockdep assertion for that! Sure. 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