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=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 00542C433B4 for ; Wed, 7 Apr 2021 10:20:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CC17F6113B for ; Wed, 7 Apr 2021 10:20:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350877AbhDGKUV (ORCPT ); Wed, 7 Apr 2021 06:20:21 -0400 Received: from foss.arm.com ([217.140.110.172]:54784 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350875AbhDGKUU (ORCPT ); Wed, 7 Apr 2021 06:20:20 -0400 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 9CAA01FB; Wed, 7 Apr 2021 03:20:10 -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 E77E23F694; Wed, 7 Apr 2021 03:20:07 -0700 (PDT) Subject: Re: [PATCH v10 2/6] arm64: kvm: Introduce MTE VM feature To: Catalin Marinas Cc: David Hildenbrand , Mark Rutland , Peter Maydell , "Dr. David Alan Gilbert" , Andrew Jones , Haibo Xu , Suzuki K Poulose , qemu-devel@nongnu.org, Marc Zyngier , Juan Quintela , Richard Henderson , linux-kernel@vger.kernel.org, Dave Martin , James Morse , linux-arm-kernel@lists.infradead.org, Thomas Gleixner , Will Deacon , kvmarm@lists.cs.columbia.edu, Julien Thierry References: <20210312151902.17853-1-steven.price@arm.com> <20210312151902.17853-3-steven.price@arm.com> <20210327152324.GA28167@arm.com> <20210328122131.GB17535@arm.com> <20210330103013.GD18075@arm.com> <8977120b-841d-4882-2472-6e403bc9c797@redhat.com> <20210331092109.GA21921@arm.com> <86a968c8-7a0e-44a4-28c3-bac62c2b7d65@arm.com> <20210331184311.GA10737@arm.com> From: Steven Price Message-ID: Date: Wed, 7 Apr 2021 11:20:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <20210331184311.GA10737@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 31/03/2021 19:43, Catalin Marinas wrote: > On Wed, Mar 31, 2021 at 11:41:20AM +0100, Steven Price wrote: >> On 31/03/2021 10:32, David Hildenbrand wrote: >>> On 31.03.21 11:21, Catalin Marinas wrote: >>>> On Wed, Mar 31, 2021 at 09:34:44AM +0200, David Hildenbrand wrote: >>>>> On 30.03.21 12:30, Catalin Marinas wrote: >>>>>> On Mon, Mar 29, 2021 at 05:06:51PM +0100, Steven Price wrote: >>>>>>> On 28/03/2021 13:21, Catalin Marinas wrote: >>>>>>>> However, the bigger issue is that Stage 2 cannot disable >>>>>>>> tagging for Stage 1 unless the memory is Non-cacheable or >>>>>>>> Device at S2. Is there a way to detect what gets mapped in >>>>>>>> the guest as Normal Cacheable memory and make sure it's >>>>>>>> only early memory or hotplug but no ZONE_DEVICE (or >>>>>>>> something else like on-chip memory)?� If we can't >>>>>>>> guarantee that all Cacheable memory given to a guest >>>>>>>> supports tags, we should disable the feature altogether. >>>>>>> >>>>>>> In stage 2 I believe we only have two types of mapping - >>>>>>> 'normal' or DEVICE_nGnRE (see stage2_map_set_prot_attr()). >>>>>>> Filtering out the latter is a case of checking the 'device' >>>>>>> variable, and makes sense to avoid the overhead you >>>>>>> describe. >>>>>>> >>>>>>> This should also guarantee that all stage-2 cacheable >>>>>>> memory supports tags, >>>>>>> as kvm_is_device_pfn() is simply !pfn_valid(), and >>>>>>> pfn_valid() should only >>>>>>> be true for memory that Linux considers "normal". >>>>> >>>>> If you think "normal" == "normal System RAM", that's wrong; see >>>>> below. >>>> >>>> By "normal" I think both Steven and I meant the Normal Cacheable memory >>>> attribute (another being the Device memory attribute). >> >> Sadly there's no good standardised terminology here. Aarch64 provides the >> "normal (cacheable)" definition. Memory which is mapped as "Normal >> Cacheable" is implicitly MTE capable when shared with a guest (because the >> stage 2 mappings don't allow restricting MTE other than mapping it as Device >> memory). >> >> So MTE also forces us to have a definition of memory which is "bog standard >> memory"[1] separate from the mapping attributes. This is the main memory >> which fully supports MTE. >> >> Separate from the "bog standard" we have the "special"[1] memory, e.g. >> ZONE_DEVICE memory may be mapped as "Normal Cacheable" at stage 1 but that >> memory may not support MTE tags. This memory can only be safely shared with >> a guest in the following situations: >> >> 1. MTE is completely disabled for the guest >> >> 2. The stage 2 mappings are 'device' (e.g. DEVICE_nGnRE) >> >> 3. We have some guarantee that guest MTE access are in some way safe. >> >> (1) is the situation today (without this patch series). But it prevents the >> guest from using MTE in any form. >> >> (2) is pretty terrible for general memory, but is the get-out clause for >> mapping devices into the guest. >> >> (3) isn't something we have any architectural way of discovering. We'd need >> to know what the device did with the MTE accesses (and any caches between >> the CPU and the device) to ensure there aren't any side-channels or h/w >> lockup issues. We'd also need some way of describing this memory to the >> guest. >> >> So at least for the time being the approach is to avoid letting a guest with >> MTE enabled have access to this sort of memory. > > When a slot is added by the VMM, if it asked MTE in guest (I guess > that's an opt-in by the VMM, haven't checked the other patches), can we > reject it if it's is going to be mapped as Normal Cacheable but it is a > ZONE_DEVICE (i.e. !kvm_is_device_pfn() + one of David's suggestions to > check for ZONE_DEVICE)? This way we don't need to do more expensive > checks in set_pte_at(). The problem is that KVM allows the VMM to change the memory backing a slot while the guest is running. This is obviously useful for the likes of migration, but ultimately means that even if you were to do checks at the time of slot creation, you would need to repeat the checks at set_pte_at() time to ensure a mischievous VMM didn't swap the page for a problematic one. > We could simplify the set_pte_at() further if we require that the VMM > has a PROT_MTE mapping. This does not mean it cannot have two mappings, > the other without PROT_MTE. But at least we get a set_pte_at() when > swapping in which has PROT_MTE. That is certainly an option - but from what I've seen of trying to implement a VMM to support MTE, the PROT_MTE mapping is not what you actually want in user space. Two mappings is possible but is likely to complicate the VMM. > We could add another PROT_TAGGED or something which means PG_mte_tagged > set but still mapped as Normal Untagged. It's just that we are short of > pte bits for another flag. That could help here - although it's slightly odd as you're asking the kernel to track the tags, but not allowing user space (direct) access to them. Like you say using us the precious bits for this seems like it might be short-sighted. > Can we somehow identify when the S2 pte is set and can we get access to > the prior swap pte? This way we could avoid changes to set_pte_at() for > S2 faults. > Unless I'm misunderstanding the code the swap information is (only) stored in the stage 1 user-space VMM PTE. When we get a stage 2 fault this triggers a corresponding access attempt to the VMM's address space. It's at this point when populating the VMM's page tables that the swap information is discovered. The problem at the moment is a mismatch regarding whether the page needs tags or not. The VMM's mapping can (currently) be !PROT_MTE which means we wouldn't normally require restoring/zeroing the tags. However the stage 2 access requires that the tags be preserved. Requiring PROT_MTE (or PROT_TAGGED as above) would certainly simplify the handling in the kernel. Of course I did propose the 'requiring PROT_MTE' approach before which led to a conversation[1] ending with a conclusion[2] that: I'd much rather the kernel just provided us with an API for what we want, which is (1) the guest RAM as just RAM with no tag checking and separately (2) some mechanism yet-to-be-designed which lets us bulk copy a page's worth of tags for migration. Which is what I've implemented ;) Do you think it's worth investigating the PROT_TAGGED approach as a middle ground? My gut feeling is that it's a waste of a VM flag, but I agree it would certainly make the code cleaner. Steve [1] https://lore.kernel.org/kvmarm/CAFEAcA85fiqA206FuFANKbV_3GkfY1F8Gv7MP58BgTT81bs9kA@mail.gmail.com/ [2] https://lore.kernel.org/kvmarm/CAFEAcA_K47jKSp46DFK-AKWv6MD1pkrEB6FNz=HNGdxmBDCSbw@mail.gmail.com/ 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=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 26CC2C433ED for ; Wed, 7 Apr 2021 10:21:50 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (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 92F376139C for ; Wed, 7 Apr 2021 10:21:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 92F376139C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:48572 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lU5Jk-0001DB-C3 for qemu-devel@archiver.kernel.org; Wed, 07 Apr 2021 06:21:48 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52234) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lU5IR-00005Z-Dh for qemu-devel@nongnu.org; Wed, 07 Apr 2021 06:20:28 -0400 Received: from foss.arm.com ([217.140.110.172]:47446) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lU5ID-0002Oj-HO for qemu-devel@nongnu.org; Wed, 07 Apr 2021 06:20:24 -0400 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 9CAA01FB; Wed, 7 Apr 2021 03:20:10 -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 E77E23F694; Wed, 7 Apr 2021 03:20:07 -0700 (PDT) Subject: Re: [PATCH v10 2/6] arm64: kvm: Introduce MTE VM feature To: Catalin Marinas References: <20210312151902.17853-1-steven.price@arm.com> <20210312151902.17853-3-steven.price@arm.com> <20210327152324.GA28167@arm.com> <20210328122131.GB17535@arm.com> <20210330103013.GD18075@arm.com> <8977120b-841d-4882-2472-6e403bc9c797@redhat.com> <20210331092109.GA21921@arm.com> <86a968c8-7a0e-44a4-28c3-bac62c2b7d65@arm.com> <20210331184311.GA10737@arm.com> From: Steven Price Message-ID: Date: Wed, 7 Apr 2021 11:20:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <20210331184311.GA10737@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=217.140.110.172; envelope-from=steven.price@arm.com; helo=foss.arm.com X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Peter Maydell , Andrew Jones , Haibo Xu , David Hildenbrand , Marc Zyngier , Suzuki K Poulose , Richard Henderson , "Dr. David Alan Gilbert" , qemu-devel@nongnu.org, Juan Quintela , James Morse , linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, Thomas Gleixner , Julien Thierry , Will Deacon , Dave Martin , linux-kernel@vger.kernel.org Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On 31/03/2021 19:43, Catalin Marinas wrote: > On Wed, Mar 31, 2021 at 11:41:20AM +0100, Steven Price wrote: >> On 31/03/2021 10:32, David Hildenbrand wrote: >>> On 31.03.21 11:21, Catalin Marinas wrote: >>>> On Wed, Mar 31, 2021 at 09:34:44AM +0200, David Hildenbrand wrote: >>>>> On 30.03.21 12:30, Catalin Marinas wrote: >>>>>> On Mon, Mar 29, 2021 at 05:06:51PM +0100, Steven Price wrote: >>>>>>> On 28/03/2021 13:21, Catalin Marinas wrote: >>>>>>>> However, the bigger issue is that Stage 2 cannot disable >>>>>>>> tagging for Stage 1 unless the memory is Non-cacheable or >>>>>>>> Device at S2. Is there a way to detect what gets mapped in >>>>>>>> the guest as Normal Cacheable memory and make sure it's >>>>>>>> only early memory or hotplug but no ZONE_DEVICE (or >>>>>>>> something else like on-chip memory)?� If we can't >>>>>>>> guarantee that all Cacheable memory given to a guest >>>>>>>> supports tags, we should disable the feature altogether. >>>>>>> >>>>>>> In stage 2 I believe we only have two types of mapping - >>>>>>> 'normal' or DEVICE_nGnRE (see stage2_map_set_prot_attr()). >>>>>>> Filtering out the latter is a case of checking the 'device' >>>>>>> variable, and makes sense to avoid the overhead you >>>>>>> describe. >>>>>>> >>>>>>> This should also guarantee that all stage-2 cacheable >>>>>>> memory supports tags, >>>>>>> as kvm_is_device_pfn() is simply !pfn_valid(), and >>>>>>> pfn_valid() should only >>>>>>> be true for memory that Linux considers "normal". >>>>> >>>>> If you think "normal" == "normal System RAM", that's wrong; see >>>>> below. >>>> >>>> By "normal" I think both Steven and I meant the Normal Cacheable memory >>>> attribute (another being the Device memory attribute). >> >> Sadly there's no good standardised terminology here. Aarch64 provides the >> "normal (cacheable)" definition. Memory which is mapped as "Normal >> Cacheable" is implicitly MTE capable when shared with a guest (because the >> stage 2 mappings don't allow restricting MTE other than mapping it as Device >> memory). >> >> So MTE also forces us to have a definition of memory which is "bog standard >> memory"[1] separate from the mapping attributes. This is the main memory >> which fully supports MTE. >> >> Separate from the "bog standard" we have the "special"[1] memory, e.g. >> ZONE_DEVICE memory may be mapped as "Normal Cacheable" at stage 1 but that >> memory may not support MTE tags. This memory can only be safely shared with >> a guest in the following situations: >> >> 1. MTE is completely disabled for the guest >> >> 2. The stage 2 mappings are 'device' (e.g. DEVICE_nGnRE) >> >> 3. We have some guarantee that guest MTE access are in some way safe. >> >> (1) is the situation today (without this patch series). But it prevents the >> guest from using MTE in any form. >> >> (2) is pretty terrible for general memory, but is the get-out clause for >> mapping devices into the guest. >> >> (3) isn't something we have any architectural way of discovering. We'd need >> to know what the device did with the MTE accesses (and any caches between >> the CPU and the device) to ensure there aren't any side-channels or h/w >> lockup issues. We'd also need some way of describing this memory to the >> guest. >> >> So at least for the time being the approach is to avoid letting a guest with >> MTE enabled have access to this sort of memory. > > When a slot is added by the VMM, if it asked MTE in guest (I guess > that's an opt-in by the VMM, haven't checked the other patches), can we > reject it if it's is going to be mapped as Normal Cacheable but it is a > ZONE_DEVICE (i.e. !kvm_is_device_pfn() + one of David's suggestions to > check for ZONE_DEVICE)? This way we don't need to do more expensive > checks in set_pte_at(). The problem is that KVM allows the VMM to change the memory backing a slot while the guest is running. This is obviously useful for the likes of migration, but ultimately means that even if you were to do checks at the time of slot creation, you would need to repeat the checks at set_pte_at() time to ensure a mischievous VMM didn't swap the page for a problematic one. > We could simplify the set_pte_at() further if we require that the VMM > has a PROT_MTE mapping. This does not mean it cannot have two mappings, > the other without PROT_MTE. But at least we get a set_pte_at() when > swapping in which has PROT_MTE. That is certainly an option - but from what I've seen of trying to implement a VMM to support MTE, the PROT_MTE mapping is not what you actually want in user space. Two mappings is possible but is likely to complicate the VMM. > We could add another PROT_TAGGED or something which means PG_mte_tagged > set but still mapped as Normal Untagged. It's just that we are short of > pte bits for another flag. That could help here - although it's slightly odd as you're asking the kernel to track the tags, but not allowing user space (direct) access to them. Like you say using us the precious bits for this seems like it might be short-sighted. > Can we somehow identify when the S2 pte is set and can we get access to > the prior swap pte? This way we could avoid changes to set_pte_at() for > S2 faults. > Unless I'm misunderstanding the code the swap information is (only) stored in the stage 1 user-space VMM PTE. When we get a stage 2 fault this triggers a corresponding access attempt to the VMM's address space. It's at this point when populating the VMM's page tables that the swap information is discovered. The problem at the moment is a mismatch regarding whether the page needs tags or not. The VMM's mapping can (currently) be !PROT_MTE which means we wouldn't normally require restoring/zeroing the tags. However the stage 2 access requires that the tags be preserved. Requiring PROT_MTE (or PROT_TAGGED as above) would certainly simplify the handling in the kernel. Of course I did propose the 'requiring PROT_MTE' approach before which led to a conversation[1] ending with a conclusion[2] that: I'd much rather the kernel just provided us with an API for what we want, which is (1) the guest RAM as just RAM with no tag checking and separately (2) some mechanism yet-to-be-designed which lets us bulk copy a page's worth of tags for migration. Which is what I've implemented ;) Do you think it's worth investigating the PROT_TAGGED approach as a middle ground? My gut feeling is that it's a waste of a VM flag, but I agree it would certainly make the code cleaner. Steve [1] https://lore.kernel.org/kvmarm/CAFEAcA85fiqA206FuFANKbV_3GkfY1F8Gv7MP58BgTT81bs9kA@mail.gmail.com/ [2] https://lore.kernel.org/kvmarm/CAFEAcA_K47jKSp46DFK-AKWv6MD1pkrEB6FNz=HNGdxmBDCSbw@mail.gmail.com/ 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=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 786AFC43460 for ; Wed, 7 Apr 2021 10:20:16 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id D6BDB6139C for ; Wed, 7 Apr 2021 10:20:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D6BDB6139C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com 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 462204B8A8; Wed, 7 Apr 2021 06:20:15 -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 4XCIUozNn4-Q; Wed, 7 Apr 2021 06:20:13 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id BF6834B877; Wed, 7 Apr 2021 06:20:13 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id A70AC4B7AE for ; Wed, 7 Apr 2021 06:20:12 -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 ijAvzMhUEUoZ for ; Wed, 7 Apr 2021 06:20:11 -0400 (EDT) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 10F874B775 for ; Wed, 7 Apr 2021 06:20:11 -0400 (EDT) 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 9CAA01FB; Wed, 7 Apr 2021 03:20:10 -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 E77E23F694; Wed, 7 Apr 2021 03:20:07 -0700 (PDT) Subject: Re: [PATCH v10 2/6] arm64: kvm: Introduce MTE VM feature To: Catalin Marinas References: <20210312151902.17853-1-steven.price@arm.com> <20210312151902.17853-3-steven.price@arm.com> <20210327152324.GA28167@arm.com> <20210328122131.GB17535@arm.com> <20210330103013.GD18075@arm.com> <8977120b-841d-4882-2472-6e403bc9c797@redhat.com> <20210331092109.GA21921@arm.com> <86a968c8-7a0e-44a4-28c3-bac62c2b7d65@arm.com> <20210331184311.GA10737@arm.com> From: Steven Price Message-ID: Date: Wed, 7 Apr 2021 11:20:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <20210331184311.GA10737@arm.com> Content-Language: en-GB Cc: David Hildenbrand , Marc Zyngier , Richard Henderson , "Dr. David Alan Gilbert" , qemu-devel@nongnu.org, Juan Quintela , linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, Thomas Gleixner , Will Deacon , Dave Martin , linux-kernel@vger.kernel.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-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu T24gMzEvMDMvMjAyMSAxOTo0MywgQ2F0YWxpbiBNYXJpbmFzIHdyb3RlOgo+IE9uIFdlZCwgTWFy IDMxLCAyMDIxIGF0IDExOjQxOjIwQU0gKzAxMDAsIFN0ZXZlbiBQcmljZSB3cm90ZToKPj4gT24g MzEvMDMvMjAyMSAxMDozMiwgRGF2aWQgSGlsZGVuYnJhbmQgd3JvdGU6Cj4+PiBPbiAzMS4wMy4y MSAxMToyMSwgQ2F0YWxpbiBNYXJpbmFzIHdyb3RlOgo+Pj4+IE9uIFdlZCwgTWFyIDMxLCAyMDIx IGF0IDA5OjM0OjQ0QU0gKzAyMDAsIERhdmlkIEhpbGRlbmJyYW5kIHdyb3RlOgo+Pj4+PiBPbiAz MC4wMy4yMSAxMjozMCwgQ2F0YWxpbiBNYXJpbmFzIHdyb3RlOgo+Pj4+Pj4gT24gTW9uLCBNYXIg MjksIDIwMjEgYXQgMDU6MDY6NTFQTSArMDEwMCwgU3RldmVuIFByaWNlIHdyb3RlOgo+Pj4+Pj4+ IE9uIDI4LzAzLzIwMjEgMTM6MjEsIENhdGFsaW4gTWFyaW5hcyB3cm90ZToKPj4+Pj4+Pj4gSG93 ZXZlciwgdGhlIGJpZ2dlciBpc3N1ZSBpcyB0aGF0IFN0YWdlIDIgY2Fubm90IGRpc2FibGUKPj4+ Pj4+Pj4gdGFnZ2luZyBmb3IgU3RhZ2UgMSB1bmxlc3MgdGhlIG1lbW9yeSBpcyBOb24tY2FjaGVh YmxlIG9yCj4+Pj4+Pj4+IERldmljZSBhdCBTMi4gSXMgdGhlcmUgYSB3YXkgdG8gZGV0ZWN0IHdo YXQgZ2V0cyBtYXBwZWQgaW4KPj4+Pj4+Pj4gdGhlIGd1ZXN0IGFzIE5vcm1hbCBDYWNoZWFibGUg bWVtb3J5IGFuZCBtYWtlIHN1cmUgaXQncwo+Pj4+Pj4+PiBvbmx5IGVhcmx5IG1lbW9yeSBvciBo b3RwbHVnIGJ1dCBubyBaT05FX0RFVklDRSAob3IKPj4+Pj4+Pj4gc29tZXRoaW5nIGVsc2UgbGlr ZSBvbi1jaGlwIG1lbW9yeSk/w6/Cv8K9IElmIHdlIGNhbid0Cj4+Pj4+Pj4+IGd1YXJhbnRlZSB0 aGF0IGFsbCBDYWNoZWFibGUgbWVtb3J5IGdpdmVuIHRvIGEgZ3Vlc3QKPj4+Pj4+Pj4gc3VwcG9y dHMgdGFncywgd2Ugc2hvdWxkIGRpc2FibGUgdGhlIGZlYXR1cmUgYWx0b2dldGhlci4KPj4+Pj4+ Pgo+Pj4+Pj4+IEluIHN0YWdlIDIgSSBiZWxpZXZlIHdlIG9ubHkgaGF2ZSB0d28gdHlwZXMgb2Yg bWFwcGluZyAtCj4+Pj4+Pj4gJ25vcm1hbCcgb3IgREVWSUNFX25HblJFIChzZWUgc3RhZ2UyX21h cF9zZXRfcHJvdF9hdHRyKCkpLgo+Pj4+Pj4+IEZpbHRlcmluZyBvdXQgdGhlIGxhdHRlciBpcyBh IGNhc2Ugb2YgY2hlY2tpbmcgdGhlICdkZXZpY2UnCj4+Pj4+Pj4gdmFyaWFibGUsIGFuZCBtYWtl cyBzZW5zZSB0byBhdm9pZCB0aGUgb3ZlcmhlYWQgeW91Cj4+Pj4+Pj4gZGVzY3JpYmUuCj4+Pj4+ Pj4KPj4+Pj4+PiBUaGlzIHNob3VsZCBhbHNvIGd1YXJhbnRlZSB0aGF0IGFsbCBzdGFnZS0yIGNh Y2hlYWJsZQo+Pj4+Pj4+IG1lbW9yeSBzdXBwb3J0cyB0YWdzLAo+Pj4+Pj4+IGFzIGt2bV9pc19k ZXZpY2VfcGZuKCkgaXMgc2ltcGx5ICFwZm5fdmFsaWQoKSwgYW5kCj4+Pj4+Pj4gcGZuX3ZhbGlk KCkgc2hvdWxkIG9ubHkKPj4+Pj4+PiBiZSB0cnVlIGZvciBtZW1vcnkgdGhhdCBMaW51eCBjb25z aWRlcnMgIm5vcm1hbCIuCj4+Pj4+Cj4+Pj4+IElmIHlvdSB0aGluayAibm9ybWFsIiA9PSAibm9y bWFsIFN5c3RlbSBSQU0iLCB0aGF0J3Mgd3Jvbmc7IHNlZQo+Pj4+PiBiZWxvdy4KPj4+Pgo+Pj4+ IEJ5ICJub3JtYWwiIEkgdGhpbmsgYm90aCBTdGV2ZW4gYW5kIEkgbWVhbnQgdGhlIE5vcm1hbCBD YWNoZWFibGUgbWVtb3J5Cj4+Pj4gYXR0cmlidXRlIChhbm90aGVyIGJlaW5nIHRoZSBEZXZpY2Ug bWVtb3J5IGF0dHJpYnV0ZSkuCj4+Cj4+IFNhZGx5IHRoZXJlJ3Mgbm8gZ29vZCBzdGFuZGFyZGlz ZWQgdGVybWlub2xvZ3kgaGVyZS4gQWFyY2g2NCBwcm92aWRlcyB0aGUKPj4gIm5vcm1hbCAoY2Fj aGVhYmxlKSIgZGVmaW5pdGlvbi4gTWVtb3J5IHdoaWNoIGlzIG1hcHBlZCBhcyAiTm9ybWFsCj4+ IENhY2hlYWJsZSIgaXMgaW1wbGljaXRseSBNVEUgY2FwYWJsZSB3aGVuIHNoYXJlZCB3aXRoIGEg Z3Vlc3QgKGJlY2F1c2UgdGhlCj4+IHN0YWdlIDIgbWFwcGluZ3MgZG9uJ3QgYWxsb3cgcmVzdHJp Y3RpbmcgTVRFIG90aGVyIHRoYW4gbWFwcGluZyBpdCBhcyBEZXZpY2UKPj4gbWVtb3J5KS4KPj4K Pj4gU28gTVRFIGFsc28gZm9yY2VzIHVzIHRvIGhhdmUgYSBkZWZpbml0aW9uIG9mIG1lbW9yeSB3 aGljaCBpcyAiYm9nIHN0YW5kYXJkCj4+IG1lbW9yeSJbMV0gc2VwYXJhdGUgZnJvbSB0aGUgbWFw cGluZyBhdHRyaWJ1dGVzLiBUaGlzIGlzIHRoZSBtYWluIG1lbW9yeQo+PiB3aGljaCBmdWxseSBz dXBwb3J0cyBNVEUuCj4+Cj4+IFNlcGFyYXRlIGZyb20gdGhlICJib2cgc3RhbmRhcmQiIHdlIGhh dmUgdGhlICJzcGVjaWFsIlsxXSBtZW1vcnksIGUuZy4KPj4gWk9ORV9ERVZJQ0UgbWVtb3J5IG1h eSBiZSBtYXBwZWQgYXMgIk5vcm1hbCBDYWNoZWFibGUiIGF0IHN0YWdlIDEgYnV0IHRoYXQKPj4g bWVtb3J5IG1heSBub3Qgc3VwcG9ydCBNVEUgdGFncy4gVGhpcyBtZW1vcnkgY2FuIG9ubHkgYmUg c2FmZWx5IHNoYXJlZCB3aXRoCj4+IGEgZ3Vlc3QgaW4gdGhlIGZvbGxvd2luZyBzaXR1YXRpb25z Ogo+Pgo+PiAgIDEuIE1URSBpcyBjb21wbGV0ZWx5IGRpc2FibGVkIGZvciB0aGUgZ3Vlc3QKPj4K Pj4gICAyLiBUaGUgc3RhZ2UgMiBtYXBwaW5ncyBhcmUgJ2RldmljZScgKGUuZy4gREVWSUNFX25H blJFKQo+Pgo+PiAgIDMuIFdlIGhhdmUgc29tZSBndWFyYW50ZWUgdGhhdCBndWVzdCBNVEUgYWNj ZXNzIGFyZSBpbiBzb21lIHdheSBzYWZlLgo+Pgo+PiAoMSkgaXMgdGhlIHNpdHVhdGlvbiB0b2Rh eSAod2l0aG91dCB0aGlzIHBhdGNoIHNlcmllcykuIEJ1dCBpdCBwcmV2ZW50cyB0aGUKPj4gZ3Vl c3QgZnJvbSB1c2luZyBNVEUgaW4gYW55IGZvcm0uCj4+Cj4+ICgyKSBpcyBwcmV0dHkgdGVycmli bGUgZm9yIGdlbmVyYWwgbWVtb3J5LCBidXQgaXMgdGhlIGdldC1vdXQgY2xhdXNlIGZvcgo+PiBt YXBwaW5nIGRldmljZXMgaW50byB0aGUgZ3Vlc3QuCj4+Cj4+ICgzKSBpc24ndCBzb21ldGhpbmcg d2UgaGF2ZSBhbnkgYXJjaGl0ZWN0dXJhbCB3YXkgb2YgZGlzY292ZXJpbmcuIFdlJ2QgbmVlZAo+ PiB0byBrbm93IHdoYXQgdGhlIGRldmljZSBkaWQgd2l0aCB0aGUgTVRFIGFjY2Vzc2VzIChhbmQg YW55IGNhY2hlcyBiZXR3ZWVuCj4+IHRoZSBDUFUgYW5kIHRoZSBkZXZpY2UpIHRvIGVuc3VyZSB0 aGVyZSBhcmVuJ3QgYW55IHNpZGUtY2hhbm5lbHMgb3IgaC93Cj4+IGxvY2t1cCBpc3N1ZXMuIFdl J2QgYWxzbyBuZWVkIHNvbWUgd2F5IG9mIGRlc2NyaWJpbmcgdGhpcyBtZW1vcnkgdG8gdGhlCj4+ IGd1ZXN0Lgo+Pgo+PiBTbyBhdCBsZWFzdCBmb3IgdGhlIHRpbWUgYmVpbmcgdGhlIGFwcHJvYWNo IGlzIHRvIGF2b2lkIGxldHRpbmcgYSBndWVzdCB3aXRoCj4+IE1URSBlbmFibGVkIGhhdmUgYWNj ZXNzIHRvIHRoaXMgc29ydCBvZiBtZW1vcnkuCj4gCj4gV2hlbiBhIHNsb3QgaXMgYWRkZWQgYnkg dGhlIFZNTSwgaWYgaXQgYXNrZWQgTVRFIGluIGd1ZXN0IChJIGd1ZXNzCj4gdGhhdCdzIGFuIG9w dC1pbiBieSB0aGUgVk1NLCBoYXZlbid0IGNoZWNrZWQgdGhlIG90aGVyIHBhdGNoZXMpLCBjYW4g d2UKPiByZWplY3QgaXQgaWYgaXQncyBpcyBnb2luZyB0byBiZSBtYXBwZWQgYXMgTm9ybWFsIENh Y2hlYWJsZSBidXQgaXQgaXMgYQo+IFpPTkVfREVWSUNFIChpLmUuICFrdm1faXNfZGV2aWNlX3Bm bigpICsgb25lIG9mIERhdmlkJ3Mgc3VnZ2VzdGlvbnMgdG8KPiBjaGVjayBmb3IgWk9ORV9ERVZJ Q0UpPyBUaGlzIHdheSB3ZSBkb24ndCBuZWVkIHRvIGRvIG1vcmUgZXhwZW5zaXZlCj4gY2hlY2tz IGluIHNldF9wdGVfYXQoKS4KClRoZSBwcm9ibGVtIGlzIHRoYXQgS1ZNIGFsbG93cyB0aGUgVk1N IHRvIGNoYW5nZSB0aGUgbWVtb3J5IGJhY2tpbmcgYSAKc2xvdCB3aGlsZSB0aGUgZ3Vlc3QgaXMg cnVubmluZy4gVGhpcyBpcyBvYnZpb3VzbHkgdXNlZnVsIGZvciB0aGUgbGlrZXMgCm9mIG1pZ3Jh dGlvbiwgYnV0IHVsdGltYXRlbHkgbWVhbnMgdGhhdCBldmVuIGlmIHlvdSB3ZXJlIHRvIGRvIGNo ZWNrcyBhdCAKdGhlIHRpbWUgb2Ygc2xvdCBjcmVhdGlvbiwgeW91IHdvdWxkIG5lZWQgdG8gcmVw ZWF0IHRoZSBjaGVja3MgYXQgCnNldF9wdGVfYXQoKSB0aW1lIHRvIGVuc3VyZSBhIG1pc2NoaWV2 b3VzIFZNTSBkaWRuJ3Qgc3dhcCB0aGUgcGFnZSBmb3IgYSAKcHJvYmxlbWF0aWMgb25lLgoKPiBX ZSBjb3VsZCBzaW1wbGlmeSB0aGUgc2V0X3B0ZV9hdCgpIGZ1cnRoZXIgaWYgd2UgcmVxdWlyZSB0 aGF0IHRoZSBWTU0KPiBoYXMgYSBQUk9UX01URSBtYXBwaW5nLiBUaGlzIGRvZXMgbm90IG1lYW4g aXQgY2Fubm90IGhhdmUgdHdvIG1hcHBpbmdzLAo+IHRoZSBvdGhlciB3aXRob3V0IFBST1RfTVRF LiBCdXQgYXQgbGVhc3Qgd2UgZ2V0IGEgc2V0X3B0ZV9hdCgpIHdoZW4KPiBzd2FwcGluZyBpbiB3 aGljaCBoYXMgUFJPVF9NVEUuCgpUaGF0IGlzIGNlcnRhaW5seSBhbiBvcHRpb24gLSBidXQgZnJv bSB3aGF0IEkndmUgc2VlbiBvZiB0cnlpbmcgdG8gCmltcGxlbWVudCBhIFZNTSB0byBzdXBwb3J0 IE1URSwgdGhlIFBST1RfTVRFIG1hcHBpbmcgaXMgbm90IHdoYXQgeW91IAphY3R1YWxseSB3YW50 IGluIHVzZXIgc3BhY2UuIFR3byBtYXBwaW5ncyBpcyBwb3NzaWJsZSBidXQgaXMgbGlrZWx5IHRv IApjb21wbGljYXRlIHRoZSBWTU0uCgo+IFdlIGNvdWxkIGFkZCBhbm90aGVyIFBST1RfVEFHR0VE IG9yIHNvbWV0aGluZyB3aGljaCBtZWFucyBQR19tdGVfdGFnZ2VkCj4gc2V0IGJ1dCBzdGlsbCBt YXBwZWQgYXMgTm9ybWFsIFVudGFnZ2VkLiBJdCdzIGp1c3QgdGhhdCB3ZSBhcmUgc2hvcnQgb2YK PiBwdGUgYml0cyBmb3IgYW5vdGhlciBmbGFnLgoKVGhhdCBjb3VsZCBoZWxwIGhlcmUgLSBhbHRo b3VnaCBpdCdzIHNsaWdodGx5IG9kZCBhcyB5b3UncmUgYXNraW5nIHRoZSAKa2VybmVsIHRvIHRy YWNrIHRoZSB0YWdzLCBidXQgbm90IGFsbG93aW5nIHVzZXIgc3BhY2UgKGRpcmVjdCkgYWNjZXNz IHRvIAp0aGVtLiBMaWtlIHlvdSBzYXkgdXNpbmcgdXMgdGhlIHByZWNpb3VzIGJpdHMgZm9yIHRo aXMgc2VlbXMgbGlrZSBpdCAKbWlnaHQgYmUgc2hvcnQtc2lnaHRlZC4KCj4gQ2FuIHdlIHNvbWVo b3cgaWRlbnRpZnkgd2hlbiB0aGUgUzIgcHRlIGlzIHNldCBhbmQgY2FuIHdlIGdldCBhY2Nlc3Mg dG8KPiB0aGUgcHJpb3Igc3dhcCBwdGU/IFRoaXMgd2F5IHdlIGNvdWxkIGF2b2lkIGNoYW5nZXMg dG8gc2V0X3B0ZV9hdCgpIGZvcgo+IFMyIGZhdWx0cy4KPiAKClVubGVzcyBJJ20gbWlzdW5kZXJz dGFuZGluZyB0aGUgY29kZSB0aGUgc3dhcCBpbmZvcm1hdGlvbiBpcyAob25seSkgCnN0b3JlZCBp biB0aGUgc3RhZ2UgMSB1c2VyLXNwYWNlIFZNTSBQVEUuIFdoZW4gd2UgZ2V0IGEgc3RhZ2UgMiBm YXVsdCAKdGhpcyB0cmlnZ2VycyBhIGNvcnJlc3BvbmRpbmcgYWNjZXNzIGF0dGVtcHQgdG8gdGhl IFZNTSdzIGFkZHJlc3Mgc3BhY2UuIApJdCdzIGF0IHRoaXMgcG9pbnQgd2hlbiBwb3B1bGF0aW5n IHRoZSBWTU0ncyBwYWdlIHRhYmxlcyB0aGF0IHRoZSBzd2FwIAppbmZvcm1hdGlvbiBpcyBkaXNj b3ZlcmVkLgoKVGhlIHByb2JsZW0gYXQgdGhlIG1vbWVudCBpcyBhIG1pc21hdGNoIHJlZ2FyZGlu ZyB3aGV0aGVyIHRoZSBwYWdlIG5lZWRzIAp0YWdzIG9yIG5vdC4gVGhlIFZNTSdzIG1hcHBpbmcg Y2FuIChjdXJyZW50bHkpIGJlICFQUk9UX01URSB3aGljaCBtZWFucyAKd2Ugd291bGRuJ3Qgbm9y bWFsbHkgcmVxdWlyZSByZXN0b3JpbmcvemVyb2luZyB0aGUgdGFncy4gSG93ZXZlciB0aGUgCnN0 YWdlIDIgYWNjZXNzIHJlcXVpcmVzIHRoYXQgdGhlIHRhZ3MgYmUgcHJlc2VydmVkLiBSZXF1aXJp bmcgUFJPVF9NVEUgCihvciBQUk9UX1RBR0dFRCBhcyBhYm92ZSkgd291bGQgY2VydGFpbmx5IHNp bXBsaWZ5IHRoZSBoYW5kbGluZyBpbiB0aGUgCmtlcm5lbC4KCk9mIGNvdXJzZSBJIGRpZCBwcm9w b3NlIHRoZSAncmVxdWlyaW5nIFBST1RfTVRFJyBhcHByb2FjaCBiZWZvcmUgd2hpY2ggCmxlZCB0 byBhIGNvbnZlcnNhdGlvblsxXSBlbmRpbmcgd2l0aCBhIGNvbmNsdXNpb25bMl0gdGhhdDoKCiAg ICBJJ2QgbXVjaCByYXRoZXIgdGhlIGtlcm5lbCBqdXN0CiAgICBwcm92aWRlZCB1cyB3aXRoIGFu IEFQSSBmb3Igd2hhdCB3ZSB3YW50LCB3aGljaCBpcyAoMSkgdGhlIGd1ZXN0CiAgICBSQU0gYXMg anVzdCBSQU0gd2l0aCBubyB0YWcgY2hlY2tpbmcgYW5kIHNlcGFyYXRlbHkgKDIpIHNvbWUKICAg IG1lY2hhbmlzbSB5ZXQtdG8tYmUtZGVzaWduZWQgd2hpY2ggbGV0cyB1cyBidWxrIGNvcHkgYSBw YWdlJ3MKICAgIHdvcnRoIG9mIHRhZ3MgZm9yIG1pZ3JhdGlvbi4KCldoaWNoIGlzIHdoYXQgSSd2 ZSBpbXBsZW1lbnRlZCA7KQoKRG8geW91IHRoaW5rIGl0J3Mgd29ydGggaW52ZXN0aWdhdGluZyB0 aGUgUFJPVF9UQUdHRUQgYXBwcm9hY2ggYXMgYSAKbWlkZGxlIGdyb3VuZD8gTXkgZ3V0IGZlZWxp bmcgaXMgdGhhdCBpdCdzIGEgd2FzdGUgb2YgYSBWTSBmbGFnLCBidXQgSSAKYWdyZWUgaXQgd291 bGQgY2VydGFpbmx5IG1ha2UgdGhlIGNvZGUgY2xlYW5lci4KClN0ZXZlCgpbMV0gCmh0dHBzOi8v bG9yZS5rZXJuZWwub3JnL2t2bWFybS9DQUZFQWNBODVmaXFBMjA2RnVGQU5LYlZfM0drZlkxRjhH djdNUDU4QmdUVDgxYnM5a0FAbWFpbC5nbWFpbC5jb20vClsyXSAKaHR0cHM6Ly9sb3JlLmtlcm5l bC5vcmcva3ZtYXJtL0NBRkVBY0FfSzQ3aktTcDQ2REZLLUFLV3Y2TUQxcGtyRUI2Rk56PUhOR2R4 bUJEQ1Nid0BtYWlsLmdtYWlsLmNvbS8KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18Ka3ZtYXJtIG1haWxpbmcgbGlzdAprdm1hcm1AbGlzdHMuY3MuY29sdW1i aWEuZWR1Cmh0dHBzOi8vbGlzdHMuY3MuY29sdW1iaWEuZWR1L21haWxtYW4vbGlzdGluZm8va3Zt YXJtCg== 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=-5.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 C51B8C433B4 for ; Wed, 7 Apr 2021 10:22:19 +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 206FE6139C for ; Wed, 7 Apr 2021 10:22:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 206FE6139C 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-Type: Content-Transfer-Encoding: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=Einhk1nETIYnNPhHl1Dwq4Zsg1j4QCIA9s6cN5bAaJI=; b=l7va5kil56GrqKpvHbJ+3Kizj ENJsfXpugcgw8X5X3/JwXRergWhrsTAWPa929T62X1pFoMBqDtV7lKa13sbKyQsqFByI/LRrr/sQG NKcnBsWvnTHQhOUDHxE2d5X6ONh3EJc6VIDdhGFDdjlM4c1dfETRayoK1fxL8AN2c6gFAXNQj2wgh 1C3ooN94a21bmjAQbKMbzYpl/5sK1VCc4znkon8Yigytsm6Mjn9ijh2/D17CJGMWcn9jkZH1pJ7rG fd0i7Rb2BdNkU7NgbcD5LsPYGy79js4G0g6sWyYyj7DTVlKf8S0KC7vHKZQnAyWsRJx3xjwmJaA0i rESzlZwUA==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lU5IM-004i7Y-8E; Wed, 07 Apr 2021 10:20:22 +0000 Received: from foss.arm.com ([217.140.110.172]) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lU5ID-004i6j-JK for linux-arm-kernel@lists.infradead.org; Wed, 07 Apr 2021 10:20:18 +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 9CAA01FB; Wed, 7 Apr 2021 03:20:10 -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 E77E23F694; Wed, 7 Apr 2021 03:20:07 -0700 (PDT) Subject: Re: [PATCH v10 2/6] arm64: kvm: Introduce MTE VM feature To: Catalin Marinas Cc: David Hildenbrand , Mark Rutland , Peter Maydell , "Dr. David Alan Gilbert" , Andrew Jones , Haibo Xu , Suzuki K Poulose , qemu-devel@nongnu.org, Marc Zyngier , Juan Quintela , Richard Henderson , linux-kernel@vger.kernel.org, Dave Martin , James Morse , linux-arm-kernel@lists.infradead.org, Thomas Gleixner , Will Deacon , kvmarm@lists.cs.columbia.edu, Julien Thierry References: <20210312151902.17853-1-steven.price@arm.com> <20210312151902.17853-3-steven.price@arm.com> <20210327152324.GA28167@arm.com> <20210328122131.GB17535@arm.com> <20210330103013.GD18075@arm.com> <8977120b-841d-4882-2472-6e403bc9c797@redhat.com> <20210331092109.GA21921@arm.com> <86a968c8-7a0e-44a4-28c3-bac62c2b7d65@arm.com> <20210331184311.GA10737@arm.com> From: Steven Price Message-ID: Date: Wed, 7 Apr 2021 11:20:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <20210331184311.GA10737@arm.com> Content-Language: en-GB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210407_112015_960295_076994B2 X-CRM114-Status: GOOD ( 46.59 ) 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-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org T24gMzEvMDMvMjAyMSAxOTo0MywgQ2F0YWxpbiBNYXJpbmFzIHdyb3RlOgo+IE9uIFdlZCwgTWFy IDMxLCAyMDIxIGF0IDExOjQxOjIwQU0gKzAxMDAsIFN0ZXZlbiBQcmljZSB3cm90ZToKPj4gT24g MzEvMDMvMjAyMSAxMDozMiwgRGF2aWQgSGlsZGVuYnJhbmQgd3JvdGU6Cj4+PiBPbiAzMS4wMy4y MSAxMToyMSwgQ2F0YWxpbiBNYXJpbmFzIHdyb3RlOgo+Pj4+IE9uIFdlZCwgTWFyIDMxLCAyMDIx IGF0IDA5OjM0OjQ0QU0gKzAyMDAsIERhdmlkIEhpbGRlbmJyYW5kIHdyb3RlOgo+Pj4+PiBPbiAz MC4wMy4yMSAxMjozMCwgQ2F0YWxpbiBNYXJpbmFzIHdyb3RlOgo+Pj4+Pj4gT24gTW9uLCBNYXIg MjksIDIwMjEgYXQgMDU6MDY6NTFQTSArMDEwMCwgU3RldmVuIFByaWNlIHdyb3RlOgo+Pj4+Pj4+ IE9uIDI4LzAzLzIwMjEgMTM6MjEsIENhdGFsaW4gTWFyaW5hcyB3cm90ZToKPj4+Pj4+Pj4gSG93 ZXZlciwgdGhlIGJpZ2dlciBpc3N1ZSBpcyB0aGF0IFN0YWdlIDIgY2Fubm90IGRpc2FibGUKPj4+ Pj4+Pj4gdGFnZ2luZyBmb3IgU3RhZ2UgMSB1bmxlc3MgdGhlIG1lbW9yeSBpcyBOb24tY2FjaGVh YmxlIG9yCj4+Pj4+Pj4+IERldmljZSBhdCBTMi4gSXMgdGhlcmUgYSB3YXkgdG8gZGV0ZWN0IHdo YXQgZ2V0cyBtYXBwZWQgaW4KPj4+Pj4+Pj4gdGhlIGd1ZXN0IGFzIE5vcm1hbCBDYWNoZWFibGUg bWVtb3J5IGFuZCBtYWtlIHN1cmUgaXQncwo+Pj4+Pj4+PiBvbmx5IGVhcmx5IG1lbW9yeSBvciBo b3RwbHVnIGJ1dCBubyBaT05FX0RFVklDRSAob3IKPj4+Pj4+Pj4gc29tZXRoaW5nIGVsc2UgbGlr ZSBvbi1jaGlwIG1lbW9yeSk/w6/Cv8K9IElmIHdlIGNhbid0Cj4+Pj4+Pj4+IGd1YXJhbnRlZSB0 aGF0IGFsbCBDYWNoZWFibGUgbWVtb3J5IGdpdmVuIHRvIGEgZ3Vlc3QKPj4+Pj4+Pj4gc3VwcG9y dHMgdGFncywgd2Ugc2hvdWxkIGRpc2FibGUgdGhlIGZlYXR1cmUgYWx0b2dldGhlci4KPj4+Pj4+ Pgo+Pj4+Pj4+IEluIHN0YWdlIDIgSSBiZWxpZXZlIHdlIG9ubHkgaGF2ZSB0d28gdHlwZXMgb2Yg bWFwcGluZyAtCj4+Pj4+Pj4gJ25vcm1hbCcgb3IgREVWSUNFX25HblJFIChzZWUgc3RhZ2UyX21h cF9zZXRfcHJvdF9hdHRyKCkpLgo+Pj4+Pj4+IEZpbHRlcmluZyBvdXQgdGhlIGxhdHRlciBpcyBh IGNhc2Ugb2YgY2hlY2tpbmcgdGhlICdkZXZpY2UnCj4+Pj4+Pj4gdmFyaWFibGUsIGFuZCBtYWtl cyBzZW5zZSB0byBhdm9pZCB0aGUgb3ZlcmhlYWQgeW91Cj4+Pj4+Pj4gZGVzY3JpYmUuCj4+Pj4+ Pj4KPj4+Pj4+PiBUaGlzIHNob3VsZCBhbHNvIGd1YXJhbnRlZSB0aGF0IGFsbCBzdGFnZS0yIGNh Y2hlYWJsZQo+Pj4+Pj4+IG1lbW9yeSBzdXBwb3J0cyB0YWdzLAo+Pj4+Pj4+IGFzIGt2bV9pc19k ZXZpY2VfcGZuKCkgaXMgc2ltcGx5ICFwZm5fdmFsaWQoKSwgYW5kCj4+Pj4+Pj4gcGZuX3ZhbGlk KCkgc2hvdWxkIG9ubHkKPj4+Pj4+PiBiZSB0cnVlIGZvciBtZW1vcnkgdGhhdCBMaW51eCBjb25z aWRlcnMgIm5vcm1hbCIuCj4+Pj4+Cj4+Pj4+IElmIHlvdSB0aGluayAibm9ybWFsIiA9PSAibm9y bWFsIFN5c3RlbSBSQU0iLCB0aGF0J3Mgd3Jvbmc7IHNlZQo+Pj4+PiBiZWxvdy4KPj4+Pgo+Pj4+ IEJ5ICJub3JtYWwiIEkgdGhpbmsgYm90aCBTdGV2ZW4gYW5kIEkgbWVhbnQgdGhlIE5vcm1hbCBD YWNoZWFibGUgbWVtb3J5Cj4+Pj4gYXR0cmlidXRlIChhbm90aGVyIGJlaW5nIHRoZSBEZXZpY2Ug bWVtb3J5IGF0dHJpYnV0ZSkuCj4+Cj4+IFNhZGx5IHRoZXJlJ3Mgbm8gZ29vZCBzdGFuZGFyZGlz ZWQgdGVybWlub2xvZ3kgaGVyZS4gQWFyY2g2NCBwcm92aWRlcyB0aGUKPj4gIm5vcm1hbCAoY2Fj aGVhYmxlKSIgZGVmaW5pdGlvbi4gTWVtb3J5IHdoaWNoIGlzIG1hcHBlZCBhcyAiTm9ybWFsCj4+ IENhY2hlYWJsZSIgaXMgaW1wbGljaXRseSBNVEUgY2FwYWJsZSB3aGVuIHNoYXJlZCB3aXRoIGEg Z3Vlc3QgKGJlY2F1c2UgdGhlCj4+IHN0YWdlIDIgbWFwcGluZ3MgZG9uJ3QgYWxsb3cgcmVzdHJp Y3RpbmcgTVRFIG90aGVyIHRoYW4gbWFwcGluZyBpdCBhcyBEZXZpY2UKPj4gbWVtb3J5KS4KPj4K Pj4gU28gTVRFIGFsc28gZm9yY2VzIHVzIHRvIGhhdmUgYSBkZWZpbml0aW9uIG9mIG1lbW9yeSB3 aGljaCBpcyAiYm9nIHN0YW5kYXJkCj4+IG1lbW9yeSJbMV0gc2VwYXJhdGUgZnJvbSB0aGUgbWFw cGluZyBhdHRyaWJ1dGVzLiBUaGlzIGlzIHRoZSBtYWluIG1lbW9yeQo+PiB3aGljaCBmdWxseSBz dXBwb3J0cyBNVEUuCj4+Cj4+IFNlcGFyYXRlIGZyb20gdGhlICJib2cgc3RhbmRhcmQiIHdlIGhh dmUgdGhlICJzcGVjaWFsIlsxXSBtZW1vcnksIGUuZy4KPj4gWk9ORV9ERVZJQ0UgbWVtb3J5IG1h eSBiZSBtYXBwZWQgYXMgIk5vcm1hbCBDYWNoZWFibGUiIGF0IHN0YWdlIDEgYnV0IHRoYXQKPj4g bWVtb3J5IG1heSBub3Qgc3VwcG9ydCBNVEUgdGFncy4gVGhpcyBtZW1vcnkgY2FuIG9ubHkgYmUg c2FmZWx5IHNoYXJlZCB3aXRoCj4+IGEgZ3Vlc3QgaW4gdGhlIGZvbGxvd2luZyBzaXR1YXRpb25z Ogo+Pgo+PiAgIDEuIE1URSBpcyBjb21wbGV0ZWx5IGRpc2FibGVkIGZvciB0aGUgZ3Vlc3QKPj4K Pj4gICAyLiBUaGUgc3RhZ2UgMiBtYXBwaW5ncyBhcmUgJ2RldmljZScgKGUuZy4gREVWSUNFX25H blJFKQo+Pgo+PiAgIDMuIFdlIGhhdmUgc29tZSBndWFyYW50ZWUgdGhhdCBndWVzdCBNVEUgYWNj ZXNzIGFyZSBpbiBzb21lIHdheSBzYWZlLgo+Pgo+PiAoMSkgaXMgdGhlIHNpdHVhdGlvbiB0b2Rh eSAod2l0aG91dCB0aGlzIHBhdGNoIHNlcmllcykuIEJ1dCBpdCBwcmV2ZW50cyB0aGUKPj4gZ3Vl c3QgZnJvbSB1c2luZyBNVEUgaW4gYW55IGZvcm0uCj4+Cj4+ICgyKSBpcyBwcmV0dHkgdGVycmli bGUgZm9yIGdlbmVyYWwgbWVtb3J5LCBidXQgaXMgdGhlIGdldC1vdXQgY2xhdXNlIGZvcgo+PiBt YXBwaW5nIGRldmljZXMgaW50byB0aGUgZ3Vlc3QuCj4+Cj4+ICgzKSBpc24ndCBzb21ldGhpbmcg d2UgaGF2ZSBhbnkgYXJjaGl0ZWN0dXJhbCB3YXkgb2YgZGlzY292ZXJpbmcuIFdlJ2QgbmVlZAo+ PiB0byBrbm93IHdoYXQgdGhlIGRldmljZSBkaWQgd2l0aCB0aGUgTVRFIGFjY2Vzc2VzIChhbmQg YW55IGNhY2hlcyBiZXR3ZWVuCj4+IHRoZSBDUFUgYW5kIHRoZSBkZXZpY2UpIHRvIGVuc3VyZSB0 aGVyZSBhcmVuJ3QgYW55IHNpZGUtY2hhbm5lbHMgb3IgaC93Cj4+IGxvY2t1cCBpc3N1ZXMuIFdl J2QgYWxzbyBuZWVkIHNvbWUgd2F5IG9mIGRlc2NyaWJpbmcgdGhpcyBtZW1vcnkgdG8gdGhlCj4+ IGd1ZXN0Lgo+Pgo+PiBTbyBhdCBsZWFzdCBmb3IgdGhlIHRpbWUgYmVpbmcgdGhlIGFwcHJvYWNo IGlzIHRvIGF2b2lkIGxldHRpbmcgYSBndWVzdCB3aXRoCj4+IE1URSBlbmFibGVkIGhhdmUgYWNj ZXNzIHRvIHRoaXMgc29ydCBvZiBtZW1vcnkuCj4gCj4gV2hlbiBhIHNsb3QgaXMgYWRkZWQgYnkg dGhlIFZNTSwgaWYgaXQgYXNrZWQgTVRFIGluIGd1ZXN0IChJIGd1ZXNzCj4gdGhhdCdzIGFuIG9w dC1pbiBieSB0aGUgVk1NLCBoYXZlbid0IGNoZWNrZWQgdGhlIG90aGVyIHBhdGNoZXMpLCBjYW4g d2UKPiByZWplY3QgaXQgaWYgaXQncyBpcyBnb2luZyB0byBiZSBtYXBwZWQgYXMgTm9ybWFsIENh Y2hlYWJsZSBidXQgaXQgaXMgYQo+IFpPTkVfREVWSUNFIChpLmUuICFrdm1faXNfZGV2aWNlX3Bm bigpICsgb25lIG9mIERhdmlkJ3Mgc3VnZ2VzdGlvbnMgdG8KPiBjaGVjayBmb3IgWk9ORV9ERVZJ Q0UpPyBUaGlzIHdheSB3ZSBkb24ndCBuZWVkIHRvIGRvIG1vcmUgZXhwZW5zaXZlCj4gY2hlY2tz IGluIHNldF9wdGVfYXQoKS4KClRoZSBwcm9ibGVtIGlzIHRoYXQgS1ZNIGFsbG93cyB0aGUgVk1N IHRvIGNoYW5nZSB0aGUgbWVtb3J5IGJhY2tpbmcgYSAKc2xvdCB3aGlsZSB0aGUgZ3Vlc3QgaXMg cnVubmluZy4gVGhpcyBpcyBvYnZpb3VzbHkgdXNlZnVsIGZvciB0aGUgbGlrZXMgCm9mIG1pZ3Jh dGlvbiwgYnV0IHVsdGltYXRlbHkgbWVhbnMgdGhhdCBldmVuIGlmIHlvdSB3ZXJlIHRvIGRvIGNo ZWNrcyBhdCAKdGhlIHRpbWUgb2Ygc2xvdCBjcmVhdGlvbiwgeW91IHdvdWxkIG5lZWQgdG8gcmVw ZWF0IHRoZSBjaGVja3MgYXQgCnNldF9wdGVfYXQoKSB0aW1lIHRvIGVuc3VyZSBhIG1pc2NoaWV2 b3VzIFZNTSBkaWRuJ3Qgc3dhcCB0aGUgcGFnZSBmb3IgYSAKcHJvYmxlbWF0aWMgb25lLgoKPiBX ZSBjb3VsZCBzaW1wbGlmeSB0aGUgc2V0X3B0ZV9hdCgpIGZ1cnRoZXIgaWYgd2UgcmVxdWlyZSB0 aGF0IHRoZSBWTU0KPiBoYXMgYSBQUk9UX01URSBtYXBwaW5nLiBUaGlzIGRvZXMgbm90IG1lYW4g aXQgY2Fubm90IGhhdmUgdHdvIG1hcHBpbmdzLAo+IHRoZSBvdGhlciB3aXRob3V0IFBST1RfTVRF LiBCdXQgYXQgbGVhc3Qgd2UgZ2V0IGEgc2V0X3B0ZV9hdCgpIHdoZW4KPiBzd2FwcGluZyBpbiB3 aGljaCBoYXMgUFJPVF9NVEUuCgpUaGF0IGlzIGNlcnRhaW5seSBhbiBvcHRpb24gLSBidXQgZnJv bSB3aGF0IEkndmUgc2VlbiBvZiB0cnlpbmcgdG8gCmltcGxlbWVudCBhIFZNTSB0byBzdXBwb3J0 IE1URSwgdGhlIFBST1RfTVRFIG1hcHBpbmcgaXMgbm90IHdoYXQgeW91IAphY3R1YWxseSB3YW50 IGluIHVzZXIgc3BhY2UuIFR3byBtYXBwaW5ncyBpcyBwb3NzaWJsZSBidXQgaXMgbGlrZWx5IHRv IApjb21wbGljYXRlIHRoZSBWTU0uCgo+IFdlIGNvdWxkIGFkZCBhbm90aGVyIFBST1RfVEFHR0VE IG9yIHNvbWV0aGluZyB3aGljaCBtZWFucyBQR19tdGVfdGFnZ2VkCj4gc2V0IGJ1dCBzdGlsbCBt YXBwZWQgYXMgTm9ybWFsIFVudGFnZ2VkLiBJdCdzIGp1c3QgdGhhdCB3ZSBhcmUgc2hvcnQgb2YK PiBwdGUgYml0cyBmb3IgYW5vdGhlciBmbGFnLgoKVGhhdCBjb3VsZCBoZWxwIGhlcmUgLSBhbHRo b3VnaCBpdCdzIHNsaWdodGx5IG9kZCBhcyB5b3UncmUgYXNraW5nIHRoZSAKa2VybmVsIHRvIHRy YWNrIHRoZSB0YWdzLCBidXQgbm90IGFsbG93aW5nIHVzZXIgc3BhY2UgKGRpcmVjdCkgYWNjZXNz IHRvIAp0aGVtLiBMaWtlIHlvdSBzYXkgdXNpbmcgdXMgdGhlIHByZWNpb3VzIGJpdHMgZm9yIHRo aXMgc2VlbXMgbGlrZSBpdCAKbWlnaHQgYmUgc2hvcnQtc2lnaHRlZC4KCj4gQ2FuIHdlIHNvbWVo b3cgaWRlbnRpZnkgd2hlbiB0aGUgUzIgcHRlIGlzIHNldCBhbmQgY2FuIHdlIGdldCBhY2Nlc3Mg dG8KPiB0aGUgcHJpb3Igc3dhcCBwdGU/IFRoaXMgd2F5IHdlIGNvdWxkIGF2b2lkIGNoYW5nZXMg dG8gc2V0X3B0ZV9hdCgpIGZvcgo+IFMyIGZhdWx0cy4KPiAKClVubGVzcyBJJ20gbWlzdW5kZXJz dGFuZGluZyB0aGUgY29kZSB0aGUgc3dhcCBpbmZvcm1hdGlvbiBpcyAob25seSkgCnN0b3JlZCBp biB0aGUgc3RhZ2UgMSB1c2VyLXNwYWNlIFZNTSBQVEUuIFdoZW4gd2UgZ2V0IGEgc3RhZ2UgMiBm YXVsdCAKdGhpcyB0cmlnZ2VycyBhIGNvcnJlc3BvbmRpbmcgYWNjZXNzIGF0dGVtcHQgdG8gdGhl IFZNTSdzIGFkZHJlc3Mgc3BhY2UuIApJdCdzIGF0IHRoaXMgcG9pbnQgd2hlbiBwb3B1bGF0aW5n IHRoZSBWTU0ncyBwYWdlIHRhYmxlcyB0aGF0IHRoZSBzd2FwIAppbmZvcm1hdGlvbiBpcyBkaXNj b3ZlcmVkLgoKVGhlIHByb2JsZW0gYXQgdGhlIG1vbWVudCBpcyBhIG1pc21hdGNoIHJlZ2FyZGlu ZyB3aGV0aGVyIHRoZSBwYWdlIG5lZWRzIAp0YWdzIG9yIG5vdC4gVGhlIFZNTSdzIG1hcHBpbmcg Y2FuIChjdXJyZW50bHkpIGJlICFQUk9UX01URSB3aGljaCBtZWFucyAKd2Ugd291bGRuJ3Qgbm9y bWFsbHkgcmVxdWlyZSByZXN0b3JpbmcvemVyb2luZyB0aGUgdGFncy4gSG93ZXZlciB0aGUgCnN0 YWdlIDIgYWNjZXNzIHJlcXVpcmVzIHRoYXQgdGhlIHRhZ3MgYmUgcHJlc2VydmVkLiBSZXF1aXJp bmcgUFJPVF9NVEUgCihvciBQUk9UX1RBR0dFRCBhcyBhYm92ZSkgd291bGQgY2VydGFpbmx5IHNp bXBsaWZ5IHRoZSBoYW5kbGluZyBpbiB0aGUgCmtlcm5lbC4KCk9mIGNvdXJzZSBJIGRpZCBwcm9w b3NlIHRoZSAncmVxdWlyaW5nIFBST1RfTVRFJyBhcHByb2FjaCBiZWZvcmUgd2hpY2ggCmxlZCB0 byBhIGNvbnZlcnNhdGlvblsxXSBlbmRpbmcgd2l0aCBhIGNvbmNsdXNpb25bMl0gdGhhdDoKCiAg ICBJJ2QgbXVjaCByYXRoZXIgdGhlIGtlcm5lbCBqdXN0CiAgICBwcm92aWRlZCB1cyB3aXRoIGFu IEFQSSBmb3Igd2hhdCB3ZSB3YW50LCB3aGljaCBpcyAoMSkgdGhlIGd1ZXN0CiAgICBSQU0gYXMg anVzdCBSQU0gd2l0aCBubyB0YWcgY2hlY2tpbmcgYW5kIHNlcGFyYXRlbHkgKDIpIHNvbWUKICAg IG1lY2hhbmlzbSB5ZXQtdG8tYmUtZGVzaWduZWQgd2hpY2ggbGV0cyB1cyBidWxrIGNvcHkgYSBw YWdlJ3MKICAgIHdvcnRoIG9mIHRhZ3MgZm9yIG1pZ3JhdGlvbi4KCldoaWNoIGlzIHdoYXQgSSd2 ZSBpbXBsZW1lbnRlZCA7KQoKRG8geW91IHRoaW5rIGl0J3Mgd29ydGggaW52ZXN0aWdhdGluZyB0 aGUgUFJPVF9UQUdHRUQgYXBwcm9hY2ggYXMgYSAKbWlkZGxlIGdyb3VuZD8gTXkgZ3V0IGZlZWxp bmcgaXMgdGhhdCBpdCdzIGEgd2FzdGUgb2YgYSBWTSBmbGFnLCBidXQgSSAKYWdyZWUgaXQgd291 bGQgY2VydGFpbmx5IG1ha2UgdGhlIGNvZGUgY2xlYW5lci4KClN0ZXZlCgpbMV0gCmh0dHBzOi8v bG9yZS5rZXJuZWwub3JnL2t2bWFybS9DQUZFQWNBODVmaXFBMjA2RnVGQU5LYlZfM0drZlkxRjhH djdNUDU4QmdUVDgxYnM5a0FAbWFpbC5nbWFpbC5jb20vClsyXSAKaHR0cHM6Ly9sb3JlLmtlcm5l bC5vcmcva3ZtYXJtL0NBRkVBY0FfSzQ3aktTcDQ2REZLLUFLV3Y2TUQxcGtyRUI2Rk56PUhOR2R4 bUJEQ1Nid0BtYWlsLmdtYWlsLmNvbS8KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCmxpbnV4LWFybS1rZXJuZWwgbWFpbGluZyBsaXN0CmxpbnV4LWFybS1r ZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWls bWFuL2xpc3RpbmZvL2xpbnV4LWFybS1rZXJuZWwK