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=-10.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 C537CC433ED for ; Thu, 20 May 2021 14:48:46 +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 33EA461184 for ; Thu, 20 May 2021 14:48:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 33EA461184 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com 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:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=1db3qKzONo7c2JJFHNoJfvQssAffgNCbYImCW2H8Eg8=; b=bXjpu98akqfI21fs58EiOxOq8w uitWLn9yASO1b3hE+2t12WC5VGanG0YX/5miSfS1eSuQsrg44QGq6ZmGrwxc2Z4TX21JkSePMyJ31 v9Ceda+i6YEgIjqnBbFxV3ZmokW6YfpZzO20mEvRrFCbne0+ZoilGkWS7mpK5I5u1XAFp3X+tZuAO azYm8Pzi5U74iFkBzxyx+JxPB8QgYBE++deJqhPZazmvuP2j3RScbl+EK5WrdLHdCP7mmlzMrcgqb YPDBPSzcHTz9cevP2qscFCWfzn+mUAvKS+0WOq8A+guBkQKUwEqU1jTNFEbQUnq8mxxHUS6y9y8Hq wWJMAGew==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ljjwz-001XAS-0w; Thu, 20 May 2021 14:47:01 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ljjww-001XAG-K0 for linux-arm-kernel@desiato.infradead.org; Thu, 20 May 2021 14:46:58 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Transfer-Encoding: Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To: Subject:Sender:Reply-To:Content-ID:Content-Description; bh=wkRxrvMMMzKAfDpJQBLTZtrQ8YP19CmBxsjy3Z1LCKE=; b=DTrkzMbF+dAE7lW/bP9VcuA3BP MR5rvjUGQzh478CMv+ZxSctSawxtvFYJYX4ApJ/7eEEWI/UfMGsKcfpr9VzxNIEOT2tdWw0pLkYqe JXyRjsB8kDSzUkndHkL/z3vHXhxA7yT45yaWYwPb77gRgGMEiSQ9BObvsJQwrGy41/rlIphsKFqcM H2Fz0/faT4RkWVvt7xnQPZpi/Z+cyHHn/5+aRl8WPedqXcejXlsYKzxEpr566uD5TNOVz+0K9cf7y /IvmRGqn41qqXJepIhlUz6L9FxMd4QWdPKACSpSqY4yRDVN7swifd/QpZ+t3cDb0OpA6JDGUbqz25 Vw+a/9xw==; Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1ljjwt-00GR7T-Ma for linux-arm-kernel@lists.infradead.org; Thu, 20 May 2021 14:46:57 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 1198DED1; Thu, 20 May 2021 07:46:52 -0700 (PDT) Received: from [192.168.1.179] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 11D393F73B; Thu, 20 May 2021 07:46:47 -0700 (PDT) Subject: Re: [PATCH v12 4/8] arm64: kvm: Introduce MTE VM feature To: Marc Zyngier Cc: Catalin Marinas , Will Deacon , James Morse , Julien Thierry , Suzuki K Poulose , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Dave Martin , Mark Rutland , Thomas Gleixner , qemu-devel@nongnu.org, Juan Quintela , "Dr. David Alan Gilbert" , Richard Henderson , Peter Maydell , Haibo Xu , Andrew Jones References: <20210517123239.8025-1-steven.price@arm.com> <20210517123239.8025-5-steven.price@arm.com> <87wnrxtikl.wl-maz@kernel.org> <60fc8939-36b7-35ce-837c-b69d0d40c9a4@arm.com> <875yzdvldb.wl-maz@kernel.org> From: Steven Price Message-ID: Date: Thu, 20 May 2021 15:46:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <875yzdvldb.wl-maz@kernel.org> Content-Language: en-GB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210520_074655_858949_9B51C71B X-CRM114-Status: GOOD ( 27.37 ) 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 20/05/2021 09:51, Marc Zyngier wrote: > On Wed, 19 May 2021 11:48:21 +0100, > Steven Price wrote: >> >> On 17/05/2021 17:45, Marc Zyngier wrote: >>> On Mon, 17 May 2021 13:32:35 +0100, >>> Steven Price wrote: [...] >>>> + } >>>> + } >>>> + >>>> + return 0; >>>> +} >>>> + >>>> static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, >>>> struct kvm_memory_slot *memslot, unsigned long hva, >>>> unsigned long fault_status) >>>> @@ -971,8 +996,13 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, >>>> if (writable) >>>> prot |= KVM_PGTABLE_PROT_W; >>>> >>>> - if (fault_status != FSC_PERM && !device) >>>> + if (fault_status != FSC_PERM && !device) { >>>> + ret = sanitise_mte_tags(kvm, vma_pagesize, pfn); >>>> + if (ret) >>>> + goto out_unlock; >>>> + >>>> clean_dcache_guest_page(pfn, vma_pagesize); >>>> + } >>>> >>>> if (exec_fault) { >>>> prot |= KVM_PGTABLE_PROT_X; >>>> @@ -1168,12 +1198,17 @@ bool kvm_unmap_gfn_range(struct kvm *kvm, struct kvm_gfn_range *range) >>>> bool kvm_set_spte_gfn(struct kvm *kvm, struct kvm_gfn_range *range) >>>> { >>>> kvm_pfn_t pfn = pte_pfn(range->pte); >>>> + int ret; >>>> >>>> if (!kvm->arch.mmu.pgt) >>>> return 0; >>>> >>>> WARN_ON(range->end - range->start != 1); >>>> >>>> + ret = sanitise_mte_tags(kvm, PAGE_SIZE, pfn); >>>> + if (ret) >>>> + return ret; >>> >>> Notice the change in return type? >> >> I do now - I was tricked by the use of '0' as false. Looks like false >> ('0') is actually the correct return here to avoid an unnecessary >> kvm_flush_remote_tlbs(). > > Yup. BTW, the return values have been fixed to proper boolean types in > the latest set of fixes. Thanks for the heads up - I'll return 'false' to avoid regressing that. >> >>>> + >>>> /* >>>> * We've moved a page around, probably through CoW, so let's treat it >>>> * just like a translation fault and clean the cache to the PoC. >>>> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c >>>> index 76ea2800c33e..24a844cb79ca 100644 >>>> --- a/arch/arm64/kvm/sys_regs.c >>>> +++ b/arch/arm64/kvm/sys_regs.c >>>> @@ -1047,6 +1047,9 @@ static u64 read_id_reg(const struct kvm_vcpu *vcpu, >>>> break; >>>> case SYS_ID_AA64PFR1_EL1: >>>> val &= ~FEATURE(ID_AA64PFR1_MTE); >>>> + if (kvm_has_mte(vcpu->kvm)) >>>> + val |= FIELD_PREP(FEATURE(ID_AA64PFR1_MTE), >>>> + ID_AA64PFR1_MTE); >>> >>> Shouldn't this be consistent with what the HW is capable of >>> (i.e. FEAT_MTE3 if available), and extracted from the sanitised view >>> of the feature set? >> >> Yes - however at the moment our sanitised view is either FEAT_MTE2 or >> nothing: >> >> { >> .desc = "Memory Tagging Extension", >> .capability = ARM64_MTE, >> .type = ARM64_CPUCAP_STRICT_BOOT_CPU_FEATURE, >> .matches = has_cpuid_feature, >> .sys_reg = SYS_ID_AA64PFR1_EL1, >> .field_pos = ID_AA64PFR1_MTE_SHIFT, >> .min_field_value = ID_AA64PFR1_MTE, >> .sign = FTR_UNSIGNED, >> .cpu_enable = cpu_enable_mte, >> }, >> >> When host support for FEAT_MTE3 is added then the KVM code will need >> revisiting to expose that down to the guest safely (AFAICS there's >> nothing extra to do here, but I haven't tested any of the MTE3 >> features). I don't think we want to expose newer versions to the guest >> than the host is aware of. (Or indeed expose FEAT_MTE if the host has >> MTE disabled because Linux requires at least FEAT_MTE2). > > What I was suggesting is to have something like this: > > pfr = read_sanitised_ftr_reg(SYS_ID_AA64PFR1_EL1); > mte = cpuid_feature_extract_unsigned_field(pfr, ID_AA64PFR1_MTE_SHIFT); > val |= FIELD_PREP(FEATURE(ID_AA64PFR1_MTE), mte); > > which does the trick nicely, and doesn't expose more than the host > supports. Ok, I have to admit to not fully understanding the sanitised register code - but wouldn't this expose higher MTE values if all CPUs support it, even though the host doesn't know what a hypothetical 'MTE4' adds? Or is there some magic in the sanitising that caps the value to what the host knows about? Thanks, Steve _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel