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 769FEC5519F for ; Fri, 20 Nov 2020 09:51:03 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 9D745204EF for ; Fri, 20 Nov 2020 09:51:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9D745204EF 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 D19234B4F8; Fri, 20 Nov 2020 04:51:01 -0500 (EST) 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 BbTp-80IsWoq; Fri, 20 Nov 2020 04:51:00 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 82BC74B3F3; Fri, 20 Nov 2020 04:51:00 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 5DF554B249 for ; Fri, 20 Nov 2020 04:50:59 -0500 (EST) 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 pOlXznVt3ndY for ; Fri, 20 Nov 2020 04:50:58 -0500 (EST) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by mm01.cs.columbia.edu (Postfix) with ESMTP id F23604A4CD for ; Fri, 20 Nov 2020 04:50:57 -0500 (EST) 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 7FF871042; Fri, 20 Nov 2020 01:50:57 -0800 (PST) Received: from [192.168.1.179] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1BD123F70D; Fri, 20 Nov 2020 01:50:54 -0800 (PST) Subject: Re: [PATCH v5 0/2] MTE support for KVM guest To: Marc Zyngier , Andrew Jones References: <20201119153901.53705-1-steven.price@arm.com> <20201119184248.4bycy6ouvaxqdiiy@kamzik.brq.redhat.com> From: Steven Price Message-ID: Date: Fri, 20 Nov 2020 09:50:53 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-GB Cc: Catalin Marinas , Juan Quintela , Richard Henderson , QEMU Developers , "Dr. David Alan Gilbert" , arm-mail-list , kvmarm , Thomas Gleixner , Will Deacon , Dave Martin , lkml - Kernel Mailing List 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 T24gMTkvMTEvMjAyMCAxOToxMSwgTWFyYyBaeW5naWVyIHdyb3RlOgo+IE9uIDIwMjAtMTEtMTkg MTg6NDIsIEFuZHJldyBKb25lcyB3cm90ZToKPj4gT24gVGh1LCBOb3YgMTksIDIwMjAgYXQgMDM6 NDU6NDBQTSArMDAwMCwgUGV0ZXIgTWF5ZGVsbCB3cm90ZToKPj4+IE9uIFRodSwgMTkgTm92IDIw MjAgYXQgMTU6MzksIFN0ZXZlbiBQcmljZSA8c3RldmVuLnByaWNlQGFybS5jb20+IHdyb3RlOgo+ Pj4gPiBUaGlzIHNlcmllcyBhZGRzIHN1cHBvcnQgZm9yIEFybSdzIE1lbW9yeSBUYWdnaW5nIEV4 dGVuc2lvbiAoTVRFKSB0bwo+Pj4gPiBLVk0sIGFsbG93aW5nIEtWTSBndWVzdHMgdG8gbWFrZSB1 c2Ugb2YgaXQuIFRoaXMgYnVpbGRzIG9uIHRoZSAKPj4+IGV4aXN0aW5nCj4+PiA+IHVzZXIgc3Bh Y2Ugc3VwcG9ydCBhbHJlYWR5IGluIHY1LjEwLXJjMSwgc2VlIFsxXSBmb3IgYW4gb3ZlcnZpZXcu Cj4+Pgo+Pj4gPiBUaGUgY2hhbmdlIHRvIHJlcXVpcmUgdGhlIFZNTSB0byBtYXAgYWxsIGd1ZXN0 IG1lbW9yeSBQUk9UX01URSBpcwo+Pj4gPiBzaWduaWZpY2FudCBhcyBpdCBtZWFucyB0aGF0IHRo ZSBWTU0gaGFzIHRvIGRlYWwgd2l0aCB0aGUgTVRFIHRhZ3MgCj4+PiBldmVuCj4+PiA+IGlmIGl0 IGRvZXNuJ3QgY2FyZSBhYm91dCB0aGVtIChlLmcuIGZvciB2aXJ0dWFsIGRldmljZXMgb3IgaWYg dGhlIFZNTQo+Pj4gPiBkb2Vzbid0IHN1cHBvcnQgbWlncmF0aW9uKS4gQWxzbyB1bmZvcnR1bmF0 ZWx5IGJlY2F1c2UgdGhlIFZNTSBjYW4KPj4+ID4gY2hhbmdlIHRoZSBtZW1vcnkgbGF5b3V0IGF0 IGFueSB0aW1lIHRoZSBjaGVjayBmb3IgUFJPVF9NVEUvVk1fTVRFIGhhcwo+Pj4gPiB0byBiZSBk b25lIHZlcnkgbGF0ZSAoYXQgdGhlIHBvaW50IG9mIGZhdWx0aW5nIHBhZ2VzIGludG8gc3RhZ2Ug MikuCj4+Pgo+Pj4gSSdtIGEgYml0IGR1YmlvdXMgYWJvdXQgcmVxdXJpbmcgdGhlIFZNTSB0byBt YXAgdGhlIGd1ZXN0IG1lbW9yeQo+Pj4gUFJPVF9NVEUgdW5sZXNzIHNvbWVib2R5J3MgZG9uZSBh dCBsZWFzdCBhIHNrZXRjaCBvZiB0aGUgZGVzaWduCj4+PiBmb3IgaG93IHRoaXMgd291bGQgd29y ayBvbiB0aGUgUUVNVSBzaWRlLiBDdXJyZW50bHkgUUVNVSBqdXN0Cj4+PiBhc3N1bWVzIHRoZSBn dWVzdCBtZW1vcnkgaXMgZ3Vlc3QgbWVtb3J5IGFuZCBpdCBjYW4gYWNjZXNzIGl0Cj4+PiB3aXRo b3V0IHNwZWNpYWwgcHJlY2F1dGlvbnMuLi4KPj4+Cj4+Cj4+IFRoZXJlIGFyZSB0d28gc3RhdGVt ZW50cyBiZWluZyBtYWRlIGhlcmU6Cj4+Cj4+IDEpIFJlcXVpcmluZyB0aGUgdXNlIG9mIFBST1Rf TVRFIHdoZW4gbWFwcGluZyBndWVzdCBtZW1vcnkgbWF5IG5vdCBmaXQKPj4gwqDCoCBRRU1VIHdl bGwuCj4+Cj4+IDIpIE5ldyBLVk0gZmVhdHVyZXMgc2hvdWxkIGJlIGFjY29tcGFuaWVkIHdpdGgg c3VwcG9ydGluZyBRRU1VIGNvZGUgaW4KPj4gwqDCoCBvcmRlciB0byBwcm92ZSB0aGF0IHRoZSBB UElzIG1ha2Ugc2Vuc2UuCj4+Cj4+IEkgc3Ryb25nbHkgYWdyZWUgd2l0aCAoMikuIFdoaWxlIGt2 bXRvb2wgc3VwcG9ydHMgc29tZSBxdWljayB0ZXN0aW5nLCBpdAo+PiBkb2Vzbid0IHN1cHBvcnQg bWlncmF0aW9uLiBXZSBtdXN0IHRlc3QgYWxsIG5ldyBmZWF0dXJlcyB3aXRoIGEgbWlncmF0aW9u Cj4+IHN1cHBvcnRpbmcgVk1NLgo+Pgo+PiBJJ20gbm90IHN1cmUgYWJvdXQgKDEpLiBJIGRvbid0 IGZlZWwgbGlrZSBpdCBzaG91bGQgYmUgYSBtYWpvciBwcm9ibGVtLAo+PiBidXQgKDIpLgoKKDEp IHNlZW1zIHRvIGJlIGNvbnRlbnRpb3VzIHdoaWNoZXZlciB3YXkgd2UgZ28uIEVpdGhlciBQUk9U X01URSBpc24ndCAKcmVxdWlyZWQgaW4gd2hpY2ggY2FzZSBpdCdzIGVhc3kgdG8gYWNjaWRlbnRh bGx5IHNjcmV3IHVwIG1pZ3JhdGlvbiwgb3IgCml0IGlzIHJlcXVpcmVkIGluIHdoaWNoIGNhc2Ug aXQncyBkaWZmaWN1bHQgdG8gaGFuZGxlIG5vcm1hbCBndWVzdCAKbWVtb3J5IGZyb20gdGhlIFZN TS4gSSBnZXQgdGhlIGltcHJlc3Npb24gdGhhdCBwcm9iYWJseSBJIHNob3VsZCBnbyBiYWNrIAp0 byB0aGUgcHJldmlvdXMgYXBwcm9hY2ggLSBzb3JyeSBmb3IgdGhlIGRpc3RyYWN0aW9uIHdpdGgg dGhpcyBjaGFuZ2UuCgooMikgaXNuJ3Qgc29tZXRoaW5nIEknbSB0cnlpbmcgdG8gc2tpcCwgYnV0 IEknbSBsaW1pdGVkIGluIHdoYXQgSSBjYW4gZG8gCm15c2VsZiBzbyB3b3VsZCBhcHByZWNpYXRl IGhlbHAgaGVyZS4gSGFpYm8gaXMgbG9va2luZyBpbnRvIHRoaXMuCgo+Pgo+PiBJJ2QgYmUgaGFw cHkgdG8gaGVscCB3aXRoIHRoZSBRRU1VIHByb3RvdHlwZSwgYnV0IHByZWZlcmFibHkgd2hlbiB0 aGVyZSdzCj4+IGhhcmR3YXJlIGF2YWlsYWJsZS4gSGFzIGFsbCB0aGUgY3VycmVudCBNVEUgdGVz dGluZyBqdXN0IGJlZW4gZG9uZSBvbgo+PiBzaW11bGF0b3JzPyBBbmQsIGlmIHNvLCBhcmUgdGhl cmUgcmVncmVzc2lvbiB0ZXN0cyByZWd1bGFybHkgcnVubmluZyBvbgo+PiB0aGUgc2ltdWxhdG9y cyB0b28/IEFuZCBjYW4gdGhleSB0ZXN0IG1pZ3JhdGlvbj8gSWYgaGFyZHdhcmUgZG9lc24ndAo+ PiBzaG93IHVwIHF1aWNrbHkgYW5kIHNpbXVsYXRvcnMgYXJlbid0IHVzZWQgZm9yIHJlZ3Jlc3Np b24gdGVzdHMsIHRoZW4KPj4gYWxsIHRoaXMgY29kZSB3aWxsIHN0YXJ0IHJvdHRpbmcgZnJvbSBk YXkgb25lLgoKQXMgTWFyYyBzYXlzLCBoYXJkd2FyZSBpc24ndCBhdmFpbGFibGUuIFRlc3Rpbmcg aXMgZWl0aGVyIHZpYSB0aGUgQXJtIApGVlAgbW9kZWwgKHRoYXQgSSd2ZSBiZWVuIHVzaW5nIGZv ciBtb3N0IG9mIG15IHRlc3RpbmcpIG9yIFFFTVUgZnVsbCAKc3lzdGVtIGVtdWxhdGlvbi4KCj4g Cj4gV2hpbGUgSSBhZ3JlZSB3aXRoIHRoZSBzZW50aW1lbnQsIHRoZSByZWFsaXR5IGlzIHByZXR0 eSBibGVhay4KPiAKPiBJJ20gcHJldHR5IHN1cmUgbm9ib2R5IHdpbGwgZXZlciBydW4gYSBtaWdy YXRpb24gb24gZW11bGF0aW9uLiBJIGFsc28gZG91YnQKPiB0aGVyZSBpcyBtdWNoIG92ZXJsYXAg YmV0d2VlbiBNVEUgdXNlcnMgYW5kIG1pZ3JhdGlvbiB1c2VycywgdW5mb3J0dW5hdGVseS4KPiAK PiBObyBIVyBpcyBhdmFpbGFibGUgdG9kYXksIGFuZCB3aGVuIGl0IGJlY29tZXMgYXZhaWxhYmxl LCBpdCB3aWxsIGJlIGluCj4gdGhlIGZvcm0gb2YgYSBjbG9zZWQgc3lzdGVtIG9uIHdoaWNoIFFF TVUgZG9lc24ndCBydW4sIGVpdGhlciBiZWNhdXNlCj4gd2UgYXJlIGxvY2tlZCBvdXQgb2YgRUwy IChhcyB1c3VhbCksIG9yIGJlY2F1c2UgbWlncmF0aW9uIGlzIG5vdCBwYXJ0IG9mCj4gdGhlIHVz ZSBjYXNlIChsaWtlIEtWTSBvbiBBbmRyb2lkLCBmb3IgZXhhbXBsZSkuCj4gCj4gU28gd2UgY2Fu IHdhaXQgYW5vdGhlciB0d28gKGZpdmU/KSB5ZWFycyB1bnRpbCBnZW5lcmFsIHB1cnBvc2UgSFcg YmVjb21lcwo+IGF2YWlsYWJsZSwgb3Igd2Ugc3RhcnQgbWVyZ2luZyB3aGF0IHdlIGNhbiB0ZXN0 IHRvZGF5LiBJJ20gaW5jbGluZWQgdG8KPiBkbyB0aGUgbGF0dGVyLgo+IAo+IEFuZCBJIHRoaW5r IGl0IGlzIGFic29sdXRlbHkgZmluZSBmb3IgUUVNVSB0byBzYXkgIm5vIE1URSBzdXBwb3J0IHdp dGggS1ZNIgo+ICh3ZSBjYW4gcmVtb3ZlIGFsbCB1c2Vyc3BhY2UgdmlzaWJpbGl0eSwgZXhjZXB0 IGZvciB0aGUgY2FwYWJpbGl0eSkuCgpXaGF0IEknbSB0cnlpbmcgdG8gYWNoaWV2ZSBpcyBhIHNp dHVhdGlvbiB3aGVyZSBLVk0rTVRFIHdpdGhvdXQgCm1pZ3JhdGlvbiB3b3JrcyBhbmQgd2UgbGVh dmUgb3Vyc2VsdmVzIGEgY2xlYXIgcGF0aCB3aGVyZSBtaWdyYXRpb24gY2FuIApiZSBhZGRlZC4g V2l0aCBoaW5kc2lnaHQgSSB0aGluayB0aGlzIHZlcnNpb24gb2YgdGhlIHNlcmllcyB3YXMgYSB3 cm9uZyAKdHVybiAtIGlmIHdlIHJldHVybiB0byBub3QgcmVxdWlyaW5nIFBST1RfTVRFIHRoZW4g d2UgaGF2ZSB0aGUgZm9sbG93aW5nIAp0d28gcG90ZW50aWFsIG9wdGlvbnMgdG8gZXhwbG9yZSBm b3IgbWlncmF0aW9uIGluIHRoZSBmdXR1cmU6CgogICogVGhlIFZNTSBjYW4gY2hvb3NlIHRvIGVu YWJsZSBQUk9UX01URSBpZiBpdCBuZWVkcyB0bywgYW5kIGlmIGRlc2lyZWQgCndlIGNhbiBhZGQg YSBmbGFnIHRvIGVuZm9yY2UgdGhpcyBpbiB0aGUga2VybmVsLgoKICAqIElmIG5lZWRlZCBhIG5l dyBrZXJuZWwgaW50ZXJmYWNlIGNhbiBiZSBwcm92aWRlZCB0byBmZXRjaC9zZXQgdGFncyAKZnJv bSBndWVzdCBtZW1vcnkgd2hpY2ggaXNuJ3QgbWFwcGVkIFBST1RfTVRFLgoKRG9lcyB0aGlzIHNv dW5kIHJlYXNvbmFibGU/CgpJJ2xsIGNsZWFuIHVwIHRoZSBzZXRfcHRlX2F0KCkgY2hhbmdlIGFu ZCBwb3N0IGEgdjYgbGF0ZXIgdG9kYXkuCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCmt2bWFybSBtYWlsaW5nIGxpc3QKa3ZtYXJtQGxpc3RzLmNzLmNvbHVt YmlhLmVkdQpodHRwczovL2xpc3RzLmNzLmNvbHVtYmlhLmVkdS9tYWlsbWFuL2xpc3RpbmZvL2t2 bWFybQo= 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 822EFC5519F for ; Fri, 20 Nov 2020 09:51:32 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 07A3F204EF for ; Fri, 20 Nov 2020 09:51:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="f42FCjwH" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 07A3F204EF 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=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=2Zgxo/RqnILmR+FRN2/RUlFm1gsC+bThbF9sr/VIg7E=; b=f42FCjwHSywnc/Mb0R44/KNRt 2kBV7A11l4FafC+9WSZtdSVug5SPgodUu/JP0PoB7aHd0Z4wGcuhzUqyNng9zerLFzlavic1JhZoj AuUE422R9ssbSFG7IrqKu8/mFwC6Uacw9eoxM1diekirpgr/TaX3gCrKMRwe+3MI3Q1qG+MLzGSG7 VXlViO+PRmTH/AqU7TQMvQsuNM8GlLYBW2HJEFQMipK6oxKJQVOyc/HGvFIrHC5K9OZeLTnMLUSQG rWOEWVtGpbtmIzB3aPPGAOfCy40gkdZhu1fhPlEqyABz/wUnYWb0O7iPJlk/uILIg0l3aYoEvAYDW 59QRPPZ+g==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kg34K-0005og-P8; Fri, 20 Nov 2020 09:51:04 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kg34H-0005nw-Qk for linux-arm-kernel@lists.infradead.org; Fri, 20 Nov 2020 09:51:02 +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 7FF871042; Fri, 20 Nov 2020 01:50:57 -0800 (PST) Received: from [192.168.1.179] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1BD123F70D; Fri, 20 Nov 2020 01:50:54 -0800 (PST) Subject: Re: [PATCH v5 0/2] MTE support for KVM guest To: Marc Zyngier , Andrew Jones References: <20201119153901.53705-1-steven.price@arm.com> <20201119184248.4bycy6ouvaxqdiiy@kamzik.brq.redhat.com> From: Steven Price Message-ID: Date: Fri, 20 Nov 2020 09:50:53 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-GB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201120_045102_000871_9FB0A8C1 X-CRM114-Status: GOOD ( 37.40 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Peter Maydell , Haibo Xu , Suzuki K Poulose , Catalin Marinas , Juan Quintela , Richard Henderson , QEMU Developers , "Dr. David Alan Gilbert" , James Morse , arm-mail-list , kvmarm , Thomas Gleixner , Julien Thierry , Will Deacon , Dave Martin , lkml - Kernel Mailing List 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 T24gMTkvMTEvMjAyMCAxOToxMSwgTWFyYyBaeW5naWVyIHdyb3RlOgo+IE9uIDIwMjAtMTEtMTkg MTg6NDIsIEFuZHJldyBKb25lcyB3cm90ZToKPj4gT24gVGh1LCBOb3YgMTksIDIwMjAgYXQgMDM6 NDU6NDBQTSArMDAwMCwgUGV0ZXIgTWF5ZGVsbCB3cm90ZToKPj4+IE9uIFRodSwgMTkgTm92IDIw MjAgYXQgMTU6MzksIFN0ZXZlbiBQcmljZSA8c3RldmVuLnByaWNlQGFybS5jb20+IHdyb3RlOgo+ Pj4gPiBUaGlzIHNlcmllcyBhZGRzIHN1cHBvcnQgZm9yIEFybSdzIE1lbW9yeSBUYWdnaW5nIEV4 dGVuc2lvbiAoTVRFKSB0bwo+Pj4gPiBLVk0sIGFsbG93aW5nIEtWTSBndWVzdHMgdG8gbWFrZSB1 c2Ugb2YgaXQuIFRoaXMgYnVpbGRzIG9uIHRoZSAKPj4+IGV4aXN0aW5nCj4+PiA+IHVzZXIgc3Bh Y2Ugc3VwcG9ydCBhbHJlYWR5IGluIHY1LjEwLXJjMSwgc2VlIFsxXSBmb3IgYW4gb3ZlcnZpZXcu Cj4+Pgo+Pj4gPiBUaGUgY2hhbmdlIHRvIHJlcXVpcmUgdGhlIFZNTSB0byBtYXAgYWxsIGd1ZXN0 IG1lbW9yeSBQUk9UX01URSBpcwo+Pj4gPiBzaWduaWZpY2FudCBhcyBpdCBtZWFucyB0aGF0IHRo ZSBWTU0gaGFzIHRvIGRlYWwgd2l0aCB0aGUgTVRFIHRhZ3MgCj4+PiBldmVuCj4+PiA+IGlmIGl0 IGRvZXNuJ3QgY2FyZSBhYm91dCB0aGVtIChlLmcuIGZvciB2aXJ0dWFsIGRldmljZXMgb3IgaWYg dGhlIFZNTQo+Pj4gPiBkb2Vzbid0IHN1cHBvcnQgbWlncmF0aW9uKS4gQWxzbyB1bmZvcnR1bmF0 ZWx5IGJlY2F1c2UgdGhlIFZNTSBjYW4KPj4+ID4gY2hhbmdlIHRoZSBtZW1vcnkgbGF5b3V0IGF0 IGFueSB0aW1lIHRoZSBjaGVjayBmb3IgUFJPVF9NVEUvVk1fTVRFIGhhcwo+Pj4gPiB0byBiZSBk b25lIHZlcnkgbGF0ZSAoYXQgdGhlIHBvaW50IG9mIGZhdWx0aW5nIHBhZ2VzIGludG8gc3RhZ2Ug MikuCj4+Pgo+Pj4gSSdtIGEgYml0IGR1YmlvdXMgYWJvdXQgcmVxdXJpbmcgdGhlIFZNTSB0byBt YXAgdGhlIGd1ZXN0IG1lbW9yeQo+Pj4gUFJPVF9NVEUgdW5sZXNzIHNvbWVib2R5J3MgZG9uZSBh dCBsZWFzdCBhIHNrZXRjaCBvZiB0aGUgZGVzaWduCj4+PiBmb3IgaG93IHRoaXMgd291bGQgd29y ayBvbiB0aGUgUUVNVSBzaWRlLiBDdXJyZW50bHkgUUVNVSBqdXN0Cj4+PiBhc3N1bWVzIHRoZSBn dWVzdCBtZW1vcnkgaXMgZ3Vlc3QgbWVtb3J5IGFuZCBpdCBjYW4gYWNjZXNzIGl0Cj4+PiB3aXRo b3V0IHNwZWNpYWwgcHJlY2F1dGlvbnMuLi4KPj4+Cj4+Cj4+IFRoZXJlIGFyZSB0d28gc3RhdGVt ZW50cyBiZWluZyBtYWRlIGhlcmU6Cj4+Cj4+IDEpIFJlcXVpcmluZyB0aGUgdXNlIG9mIFBST1Rf TVRFIHdoZW4gbWFwcGluZyBndWVzdCBtZW1vcnkgbWF5IG5vdCBmaXQKPj4gwqDCoCBRRU1VIHdl bGwuCj4+Cj4+IDIpIE5ldyBLVk0gZmVhdHVyZXMgc2hvdWxkIGJlIGFjY29tcGFuaWVkIHdpdGgg c3VwcG9ydGluZyBRRU1VIGNvZGUgaW4KPj4gwqDCoCBvcmRlciB0byBwcm92ZSB0aGF0IHRoZSBB UElzIG1ha2Ugc2Vuc2UuCj4+Cj4+IEkgc3Ryb25nbHkgYWdyZWUgd2l0aCAoMikuIFdoaWxlIGt2 bXRvb2wgc3VwcG9ydHMgc29tZSBxdWljayB0ZXN0aW5nLCBpdAo+PiBkb2Vzbid0IHN1cHBvcnQg bWlncmF0aW9uLiBXZSBtdXN0IHRlc3QgYWxsIG5ldyBmZWF0dXJlcyB3aXRoIGEgbWlncmF0aW9u Cj4+IHN1cHBvcnRpbmcgVk1NLgo+Pgo+PiBJJ20gbm90IHN1cmUgYWJvdXQgKDEpLiBJIGRvbid0 IGZlZWwgbGlrZSBpdCBzaG91bGQgYmUgYSBtYWpvciBwcm9ibGVtLAo+PiBidXQgKDIpLgoKKDEp IHNlZW1zIHRvIGJlIGNvbnRlbnRpb3VzIHdoaWNoZXZlciB3YXkgd2UgZ28uIEVpdGhlciBQUk9U X01URSBpc24ndCAKcmVxdWlyZWQgaW4gd2hpY2ggY2FzZSBpdCdzIGVhc3kgdG8gYWNjaWRlbnRh bGx5IHNjcmV3IHVwIG1pZ3JhdGlvbiwgb3IgCml0IGlzIHJlcXVpcmVkIGluIHdoaWNoIGNhc2Ug aXQncyBkaWZmaWN1bHQgdG8gaGFuZGxlIG5vcm1hbCBndWVzdCAKbWVtb3J5IGZyb20gdGhlIFZN TS4gSSBnZXQgdGhlIGltcHJlc3Npb24gdGhhdCBwcm9iYWJseSBJIHNob3VsZCBnbyBiYWNrIAp0 byB0aGUgcHJldmlvdXMgYXBwcm9hY2ggLSBzb3JyeSBmb3IgdGhlIGRpc3RyYWN0aW9uIHdpdGgg dGhpcyBjaGFuZ2UuCgooMikgaXNuJ3Qgc29tZXRoaW5nIEknbSB0cnlpbmcgdG8gc2tpcCwgYnV0 IEknbSBsaW1pdGVkIGluIHdoYXQgSSBjYW4gZG8gCm15c2VsZiBzbyB3b3VsZCBhcHByZWNpYXRl IGhlbHAgaGVyZS4gSGFpYm8gaXMgbG9va2luZyBpbnRvIHRoaXMuCgo+Pgo+PiBJJ2QgYmUgaGFw cHkgdG8gaGVscCB3aXRoIHRoZSBRRU1VIHByb3RvdHlwZSwgYnV0IHByZWZlcmFibHkgd2hlbiB0 aGVyZSdzCj4+IGhhcmR3YXJlIGF2YWlsYWJsZS4gSGFzIGFsbCB0aGUgY3VycmVudCBNVEUgdGVz dGluZyBqdXN0IGJlZW4gZG9uZSBvbgo+PiBzaW11bGF0b3JzPyBBbmQsIGlmIHNvLCBhcmUgdGhl cmUgcmVncmVzc2lvbiB0ZXN0cyByZWd1bGFybHkgcnVubmluZyBvbgo+PiB0aGUgc2ltdWxhdG9y cyB0b28/IEFuZCBjYW4gdGhleSB0ZXN0IG1pZ3JhdGlvbj8gSWYgaGFyZHdhcmUgZG9lc24ndAo+ PiBzaG93IHVwIHF1aWNrbHkgYW5kIHNpbXVsYXRvcnMgYXJlbid0IHVzZWQgZm9yIHJlZ3Jlc3Np b24gdGVzdHMsIHRoZW4KPj4gYWxsIHRoaXMgY29kZSB3aWxsIHN0YXJ0IHJvdHRpbmcgZnJvbSBk YXkgb25lLgoKQXMgTWFyYyBzYXlzLCBoYXJkd2FyZSBpc24ndCBhdmFpbGFibGUuIFRlc3Rpbmcg aXMgZWl0aGVyIHZpYSB0aGUgQXJtIApGVlAgbW9kZWwgKHRoYXQgSSd2ZSBiZWVuIHVzaW5nIGZv ciBtb3N0IG9mIG15IHRlc3RpbmcpIG9yIFFFTVUgZnVsbCAKc3lzdGVtIGVtdWxhdGlvbi4KCj4g Cj4gV2hpbGUgSSBhZ3JlZSB3aXRoIHRoZSBzZW50aW1lbnQsIHRoZSByZWFsaXR5IGlzIHByZXR0 eSBibGVhay4KPiAKPiBJJ20gcHJldHR5IHN1cmUgbm9ib2R5IHdpbGwgZXZlciBydW4gYSBtaWdy YXRpb24gb24gZW11bGF0aW9uLiBJIGFsc28gZG91YnQKPiB0aGVyZSBpcyBtdWNoIG92ZXJsYXAg YmV0d2VlbiBNVEUgdXNlcnMgYW5kIG1pZ3JhdGlvbiB1c2VycywgdW5mb3J0dW5hdGVseS4KPiAK PiBObyBIVyBpcyBhdmFpbGFibGUgdG9kYXksIGFuZCB3aGVuIGl0IGJlY29tZXMgYXZhaWxhYmxl LCBpdCB3aWxsIGJlIGluCj4gdGhlIGZvcm0gb2YgYSBjbG9zZWQgc3lzdGVtIG9uIHdoaWNoIFFF TVUgZG9lc24ndCBydW4sIGVpdGhlciBiZWNhdXNlCj4gd2UgYXJlIGxvY2tlZCBvdXQgb2YgRUwy IChhcyB1c3VhbCksIG9yIGJlY2F1c2UgbWlncmF0aW9uIGlzIG5vdCBwYXJ0IG9mCj4gdGhlIHVz ZSBjYXNlIChsaWtlIEtWTSBvbiBBbmRyb2lkLCBmb3IgZXhhbXBsZSkuCj4gCj4gU28gd2UgY2Fu IHdhaXQgYW5vdGhlciB0d28gKGZpdmU/KSB5ZWFycyB1bnRpbCBnZW5lcmFsIHB1cnBvc2UgSFcg YmVjb21lcwo+IGF2YWlsYWJsZSwgb3Igd2Ugc3RhcnQgbWVyZ2luZyB3aGF0IHdlIGNhbiB0ZXN0 IHRvZGF5LiBJJ20gaW5jbGluZWQgdG8KPiBkbyB0aGUgbGF0dGVyLgo+IAo+IEFuZCBJIHRoaW5r IGl0IGlzIGFic29sdXRlbHkgZmluZSBmb3IgUUVNVSB0byBzYXkgIm5vIE1URSBzdXBwb3J0IHdp dGggS1ZNIgo+ICh3ZSBjYW4gcmVtb3ZlIGFsbCB1c2Vyc3BhY2UgdmlzaWJpbGl0eSwgZXhjZXB0 IGZvciB0aGUgY2FwYWJpbGl0eSkuCgpXaGF0IEknbSB0cnlpbmcgdG8gYWNoaWV2ZSBpcyBhIHNp dHVhdGlvbiB3aGVyZSBLVk0rTVRFIHdpdGhvdXQgCm1pZ3JhdGlvbiB3b3JrcyBhbmQgd2UgbGVh dmUgb3Vyc2VsdmVzIGEgY2xlYXIgcGF0aCB3aGVyZSBtaWdyYXRpb24gY2FuIApiZSBhZGRlZC4g V2l0aCBoaW5kc2lnaHQgSSB0aGluayB0aGlzIHZlcnNpb24gb2YgdGhlIHNlcmllcyB3YXMgYSB3 cm9uZyAKdHVybiAtIGlmIHdlIHJldHVybiB0byBub3QgcmVxdWlyaW5nIFBST1RfTVRFIHRoZW4g d2UgaGF2ZSB0aGUgZm9sbG93aW5nIAp0d28gcG90ZW50aWFsIG9wdGlvbnMgdG8gZXhwbG9yZSBm b3IgbWlncmF0aW9uIGluIHRoZSBmdXR1cmU6CgogICogVGhlIFZNTSBjYW4gY2hvb3NlIHRvIGVu YWJsZSBQUk9UX01URSBpZiBpdCBuZWVkcyB0bywgYW5kIGlmIGRlc2lyZWQgCndlIGNhbiBhZGQg YSBmbGFnIHRvIGVuZm9yY2UgdGhpcyBpbiB0aGUga2VybmVsLgoKICAqIElmIG5lZWRlZCBhIG5l dyBrZXJuZWwgaW50ZXJmYWNlIGNhbiBiZSBwcm92aWRlZCB0byBmZXRjaC9zZXQgdGFncyAKZnJv bSBndWVzdCBtZW1vcnkgd2hpY2ggaXNuJ3QgbWFwcGVkIFBST1RfTVRFLgoKRG9lcyB0aGlzIHNv dW5kIHJlYXNvbmFibGU/CgpJJ2xsIGNsZWFuIHVwIHRoZSBzZXRfcHRlX2F0KCkgY2hhbmdlIGFu ZCBwb3N0IGEgdjYgbGF0ZXIgdG9kYXkuCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwpsaW51eC1hcm0ta2VybmVsIG1haWxpbmcgbGlzdApsaW51eC1hcm0t a2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFp bG1hbi9saXN0aW5mby9saW51eC1hcm0ta2VybmVsCg== 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 D2B71C63777 for ; Fri, 20 Nov 2020 09:51:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 872B02222F for ; Fri, 20 Nov 2020 09:51:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727254AbgKTJu7 (ORCPT ); Fri, 20 Nov 2020 04:50:59 -0500 Received: from foss.arm.com ([217.140.110.172]:45952 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725809AbgKTJu6 (ORCPT ); Fri, 20 Nov 2020 04:50:58 -0500 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 7FF871042; Fri, 20 Nov 2020 01:50:57 -0800 (PST) Received: from [192.168.1.179] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1BD123F70D; Fri, 20 Nov 2020 01:50:54 -0800 (PST) Subject: Re: [PATCH v5 0/2] MTE support for KVM guest To: Marc Zyngier , Andrew Jones Cc: Peter Maydell , Mark Rutland , "Dr. David Alan Gilbert" , Haibo Xu , Suzuki K Poulose , QEMU Developers , Catalin Marinas , Juan Quintela , Richard Henderson , lkml - Kernel Mailing List , Dave Martin , James Morse , arm-mail-list , Thomas Gleixner , Will Deacon , kvmarm , Julien Thierry References: <20201119153901.53705-1-steven.price@arm.com> <20201119184248.4bycy6ouvaxqdiiy@kamzik.brq.redhat.com> From: Steven Price Message-ID: Date: Fri, 20 Nov 2020 09:50:53 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: 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 19/11/2020 19:11, Marc Zyngier wrote: > On 2020-11-19 18:42, Andrew Jones wrote: >> On Thu, Nov 19, 2020 at 03:45:40PM +0000, Peter Maydell wrote: >>> On Thu, 19 Nov 2020 at 15:39, Steven Price wrote: >>> > This series adds support for Arm's Memory Tagging Extension (MTE) to >>> > KVM, allowing KVM guests to make use of it. This builds on the >>> existing >>> > user space support already in v5.10-rc1, see [1] for an overview. >>> >>> > The change to require the VMM to map all guest memory PROT_MTE is >>> > significant as it means that the VMM has to deal with the MTE tags >>> even >>> > if it doesn't care about them (e.g. for virtual devices or if the VMM >>> > doesn't support migration). Also unfortunately because the VMM can >>> > change the memory layout at any time the check for PROT_MTE/VM_MTE has >>> > to be done very late (at the point of faulting pages into stage 2). >>> >>> I'm a bit dubious about requring the VMM to map the guest memory >>> PROT_MTE unless somebody's done at least a sketch of the design >>> for how this would work on the QEMU side. Currently QEMU just >>> assumes the guest memory is guest memory and it can access it >>> without special precautions... >>> >> >> There are two statements being made here: >> >> 1) Requiring the use of PROT_MTE when mapping guest memory may not fit >>    QEMU well. >> >> 2) New KVM features should be accompanied with supporting QEMU code in >>    order to prove that the APIs make sense. >> >> I strongly agree with (2). While kvmtool supports some quick testing, it >> doesn't support migration. We must test all new features with a migration >> supporting VMM. >> >> I'm not sure about (1). I don't feel like it should be a major problem, >> but (2). (1) seems to be contentious whichever way we go. Either PROT_MTE isn't required in which case it's easy to accidentally screw up migration, or it is required in which case it's difficult to handle normal guest memory from the VMM. I get the impression that probably I should go back to the previous approach - sorry for the distraction with this change. (2) isn't something I'm trying to skip, but I'm limited in what I can do myself so would appreciate help here. Haibo is looking into this. >> >> I'd be happy to help with the QEMU prototype, but preferably when there's >> hardware available. Has all the current MTE testing just been done on >> simulators? And, if so, are there regression tests regularly running on >> the simulators too? And can they test migration? If hardware doesn't >> show up quickly and simulators aren't used for regression tests, then >> all this code will start rotting from day one. As Marc says, hardware isn't available. Testing is either via the Arm FVP model (that I've been using for most of my testing) or QEMU full system emulation. > > While I agree with the sentiment, the reality is pretty bleak. > > I'm pretty sure nobody will ever run a migration on emulation. I also doubt > there is much overlap between MTE users and migration users, unfortunately. > > No HW is available today, and when it becomes available, it will be in > the form of a closed system on which QEMU doesn't run, either because > we are locked out of EL2 (as usual), or because migration is not part of > the use case (like KVM on Android, for example). > > So we can wait another two (five?) years until general purpose HW becomes > available, or we start merging what we can test today. I'm inclined to > do the latter. > > And I think it is absolutely fine for QEMU to say "no MTE support with KVM" > (we can remove all userspace visibility, except for the capability). What I'm trying to achieve is a situation where KVM+MTE without migration works and we leave ourselves a clear path where migration can be added. With hindsight I think this version of the series was a wrong turn - if we return to not requiring PROT_MTE then we have the following two potential options to explore for migration in the future: * The VMM can choose to enable PROT_MTE if it needs to, and if desired we can add a flag to enforce this in the kernel. * If needed a new kernel interface can be provided to fetch/set tags from guest memory which isn't mapped PROT_MTE. Does this sound reasonable? I'll clean up the set_pte_at() change and post a v6 later today. 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 BF959C5519F for ; Fri, 20 Nov 2020 09:51:53 +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 14B3C204EF for ; Fri, 20 Nov 2020 09:51:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 14B3C204EF 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]:52740 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kg355-0007Bt-P8 for qemu-devel@archiver.kernel.org; Fri, 20 Nov 2020 04:51:51 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:46370) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kg34I-0006d2-3E for qemu-devel@nongnu.org; Fri, 20 Nov 2020 04:51:02 -0500 Received: from foss.arm.com ([217.140.110.172]:38612) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kg34F-0006JO-2o for qemu-devel@nongnu.org; Fri, 20 Nov 2020 04:51:01 -0500 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 7FF871042; Fri, 20 Nov 2020 01:50:57 -0800 (PST) Received: from [192.168.1.179] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1BD123F70D; Fri, 20 Nov 2020 01:50:54 -0800 (PST) Subject: Re: [PATCH v5 0/2] MTE support for KVM guest To: Marc Zyngier , Andrew Jones References: <20201119153901.53705-1-steven.price@arm.com> <20201119184248.4bycy6ouvaxqdiiy@kamzik.brq.redhat.com> From: Steven Price Message-ID: Date: Fri, 20 Nov 2020 09:50:53 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: 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 , Haibo Xu , Suzuki K Poulose , Catalin Marinas , Juan Quintela , Richard Henderson , QEMU Developers , "Dr. David Alan Gilbert" , James Morse , arm-mail-list , kvmarm , Thomas Gleixner , Julien Thierry , Will Deacon , Dave Martin , lkml - Kernel Mailing List Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On 19/11/2020 19:11, Marc Zyngier wrote: > On 2020-11-19 18:42, Andrew Jones wrote: >> On Thu, Nov 19, 2020 at 03:45:40PM +0000, Peter Maydell wrote: >>> On Thu, 19 Nov 2020 at 15:39, Steven Price wrote: >>> > This series adds support for Arm's Memory Tagging Extension (MTE) to >>> > KVM, allowing KVM guests to make use of it. This builds on the >>> existing >>> > user space support already in v5.10-rc1, see [1] for an overview. >>> >>> > The change to require the VMM to map all guest memory PROT_MTE is >>> > significant as it means that the VMM has to deal with the MTE tags >>> even >>> > if it doesn't care about them (e.g. for virtual devices or if the VMM >>> > doesn't support migration). Also unfortunately because the VMM can >>> > change the memory layout at any time the check for PROT_MTE/VM_MTE has >>> > to be done very late (at the point of faulting pages into stage 2). >>> >>> I'm a bit dubious about requring the VMM to map the guest memory >>> PROT_MTE unless somebody's done at least a sketch of the design >>> for how this would work on the QEMU side. Currently QEMU just >>> assumes the guest memory is guest memory and it can access it >>> without special precautions... >>> >> >> There are two statements being made here: >> >> 1) Requiring the use of PROT_MTE when mapping guest memory may not fit >>    QEMU well. >> >> 2) New KVM features should be accompanied with supporting QEMU code in >>    order to prove that the APIs make sense. >> >> I strongly agree with (2). While kvmtool supports some quick testing, it >> doesn't support migration. We must test all new features with a migration >> supporting VMM. >> >> I'm not sure about (1). I don't feel like it should be a major problem, >> but (2). (1) seems to be contentious whichever way we go. Either PROT_MTE isn't required in which case it's easy to accidentally screw up migration, or it is required in which case it's difficult to handle normal guest memory from the VMM. I get the impression that probably I should go back to the previous approach - sorry for the distraction with this change. (2) isn't something I'm trying to skip, but I'm limited in what I can do myself so would appreciate help here. Haibo is looking into this. >> >> I'd be happy to help with the QEMU prototype, but preferably when there's >> hardware available. Has all the current MTE testing just been done on >> simulators? And, if so, are there regression tests regularly running on >> the simulators too? And can they test migration? If hardware doesn't >> show up quickly and simulators aren't used for regression tests, then >> all this code will start rotting from day one. As Marc says, hardware isn't available. Testing is either via the Arm FVP model (that I've been using for most of my testing) or QEMU full system emulation. > > While I agree with the sentiment, the reality is pretty bleak. > > I'm pretty sure nobody will ever run a migration on emulation. I also doubt > there is much overlap between MTE users and migration users, unfortunately. > > No HW is available today, and when it becomes available, it will be in > the form of a closed system on which QEMU doesn't run, either because > we are locked out of EL2 (as usual), or because migration is not part of > the use case (like KVM on Android, for example). > > So we can wait another two (five?) years until general purpose HW becomes > available, or we start merging what we can test today. I'm inclined to > do the latter. > > And I think it is absolutely fine for QEMU to say "no MTE support with KVM" > (we can remove all userspace visibility, except for the capability). What I'm trying to achieve is a situation where KVM+MTE without migration works and we leave ourselves a clear path where migration can be added. With hindsight I think this version of the series was a wrong turn - if we return to not requiring PROT_MTE then we have the following two potential options to explore for migration in the future: * The VMM can choose to enable PROT_MTE if it needs to, and if desired we can add a flag to enforce this in the kernel. * If needed a new kernel interface can be provided to fetch/set tags from guest memory which isn't mapped PROT_MTE. Does this sound reasonable? I'll clean up the set_pte_at() change and post a v6 later today.