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.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 5D503C56201 for ; Thu, 19 Nov 2020 16:39:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EC8562220B for ; Thu, 19 Nov 2020 16:39:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="K7bWQ0Zc" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729111AbgKSQj4 (ORCPT ); Thu, 19 Nov 2020 11:39:56 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55934 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727849AbgKSQjz (ORCPT ); Thu, 19 Nov 2020 11:39:55 -0500 Received: from mail-ej1-x643.google.com (mail-ej1-x643.google.com [IPv6:2a00:1450:4864:20::643]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 29365C0613CF for ; Thu, 19 Nov 2020 08:39:54 -0800 (PST) Received: by mail-ej1-x643.google.com with SMTP id f23so8845862ejk.2 for ; Thu, 19 Nov 2020 08:39:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wHCeV+0wASxa7xKuZTzPc3uHjiByPnCWQmQdnty1SfE=; b=K7bWQ0Zc34TB663V4lX0Qpf54I3JpW4/Qv0E3aCd2FzmNzPEhOljrgVnmphkmOB1dc a6SoyQVZUAEKpTTkmOmFxaWEbyIHfNU1t5s4H+FGnQfBh3yN4A0dv3Jjpn7D4gdQJdwO Ju3cHL9f6IDj08kfEWIO22b2kY0KCvZqLgRoc06QwAaZrdQx8LsgIRI/fXWLbGC17jXb HMMexFgaVR1tx6U/qzRdJJFqAt6ocD2O2c/l/aEEZF7tOOrDJWmaySSX9sKRw4Ov4wXs joWmgV0j3pVCynbuzQOj93EchianKE39W9JT+KbSmq6jMP9MZyZAwS+f/yKTtTxNhQj6 GEZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wHCeV+0wASxa7xKuZTzPc3uHjiByPnCWQmQdnty1SfE=; b=ofM3MZjH5ufkWz3UJjgTxo77jmKK3rGJhSOODBXmNZYw23eY4e/h5Qklzlnucy5mkY g9sJQv0zdqe4NQRBOJTYyERssDgo6MfKy6NmEZCeX+wfeE7kbkrfjCQ5QineNJx08tLT 7nJF81xAnCKS7PEqiSaEDEtPurz87A03xx6rBFk+FIKTclOELHMEG0evf5lAXCUZsNCM pQBOMUA5Oo5tk+WvMppOKjmtD1+l/XBZWOkMXje7OgD5DEv4U+U8OL1kMxIjfn4NcwH/ v7AgrqloenNE/EZFmkJP3qwVMQqsSTrMM+VVBpqe75p1334E3df+1BCsN511ea+dEsKh I/Wg== X-Gm-Message-State: AOAM532jN7AEMxBRntN4EkR4Ooqiu2v/YXx7z5+Hv/VvVjJN5wyYGqVy 4aHgNdDtF5Sn4I2Pxodq9wZnS1riR+xLKoHStx4bHg== X-Google-Smtp-Source: ABdhPJxohkqohF8Rold75mHYphEqgvgYH008wPvAAASt8psj0r6y3aoUKE/wT9nNKiSdXCRUmbbTz2P3mxtXYvrp7Oo= X-Received: by 2002:a17:906:af8c:: with SMTP id mj12mr28777718ejb.85.1605803992789; Thu, 19 Nov 2020 08:39:52 -0800 (PST) MIME-Version: 1.0 References: <20201119153901.53705-1-steven.price@arm.com> In-Reply-To: From: Peter Maydell Date: Thu, 19 Nov 2020 16:39:41 +0000 Message-ID: Subject: Re: [PATCH v5 0/2] MTE support for KVM guest To: Steven Price Cc: Catalin Marinas , Marc Zyngier , Will Deacon , James Morse , Julien Thierry , Suzuki K Poulose , kvmarm , arm-mail-list , lkml - Kernel Mailing List , Dave Martin , Mark Rutland , Thomas Gleixner , QEMU Developers , Juan Quintela , "Dr. David Alan Gilbert" , Richard Henderson , Haibo Xu , Andrew Jones Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 19 Nov 2020 at 15:57, Steven Price wrote: > On 19/11/2020 15:45, Peter Maydell wrote: > > 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... > > I agree this needs some investigation - I'm hoping Haibo will be able to > provide some feedback here as he has been looking at the QEMU support. > However the VMM is likely going to require some significant changes to > ensure that migration doesn't break, so either way there's work to be done. > > Fundamentally most memory will need a mapping with PROT_MTE just so the > VMM can get at the tags for migration purposes, so QEMU is going to have > to learn how to treat guest memory specially if it wants to be able to > enable MTE for both itself and the guest. If the only reason the VMM needs tag access is for migration it feels like there must be a nicer way to do it than by requiring it to map the whole of the guest address space twice (once for normal use and once to get the tags)... Anyway, maybe "must map PROT_MTE" is workable, but it seems a bit premature to fix the kernel ABI as working that way until we are at least reasonably sure that it is the right design. thanks -- PMM 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=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 78134C63697 for ; Thu, 19 Nov 2020 16:45:07 +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 D61252222A for ; Thu, 19 Nov 2020 16:45:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="K7bWQ0Zc" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D61252222A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:43948 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kfn3R-0007l2-QC for qemu-devel@archiver.kernel.org; Thu, 19 Nov 2020 11:45:05 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:57798) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kfmyU-0000Rz-Kk for qemu-devel@nongnu.org; Thu, 19 Nov 2020 11:39:58 -0500 Received: from mail-ej1-x642.google.com ([2a00:1450:4864:20::642]:36790) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kfmyS-0006MG-IX for qemu-devel@nongnu.org; Thu, 19 Nov 2020 11:39:58 -0500 Received: by mail-ej1-x642.google.com with SMTP id o21so8824185ejb.3 for ; Thu, 19 Nov 2020 08:39:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wHCeV+0wASxa7xKuZTzPc3uHjiByPnCWQmQdnty1SfE=; b=K7bWQ0Zc34TB663V4lX0Qpf54I3JpW4/Qv0E3aCd2FzmNzPEhOljrgVnmphkmOB1dc a6SoyQVZUAEKpTTkmOmFxaWEbyIHfNU1t5s4H+FGnQfBh3yN4A0dv3Jjpn7D4gdQJdwO Ju3cHL9f6IDj08kfEWIO22b2kY0KCvZqLgRoc06QwAaZrdQx8LsgIRI/fXWLbGC17jXb HMMexFgaVR1tx6U/qzRdJJFqAt6ocD2O2c/l/aEEZF7tOOrDJWmaySSX9sKRw4Ov4wXs joWmgV0j3pVCynbuzQOj93EchianKE39W9JT+KbSmq6jMP9MZyZAwS+f/yKTtTxNhQj6 GEZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wHCeV+0wASxa7xKuZTzPc3uHjiByPnCWQmQdnty1SfE=; b=SWgjRJLNTwZm7pcJ7YRyuA0YBzeU2aWsf0baQ4YIEsHq8ojdB5CDmXTvY49UrxVXNv +ap2hoQA0CbG3OVbSWGNQSgqsC8PgkSRVXT45OtkLPvvFnqOK0H0rbnxvWUWXJ0hf0KG fuSJity1ASWiAYWS5QbD0CL/X4t86VZN1vznPMKM0myXC8wKjNdp6OJHyuE0jIB2XbuI 85OeXN4fb2k7lxeW87dvXs/jfJWsUCynlszcmXEumE5v1wTpkminkF5kF5pWtghL4Sw/ 0ogHhrXAL2znwDLiVoDA9eBzKo+7AWSTiw1LMi6R8taO+Q+vorQf4lrLRtJQmY2Fz7Zb 9WAA== X-Gm-Message-State: AOAM531U7BWp5DrzctUOS4JfIZ2A+jyEVQNHm8NOYV2Ws6/YA0Uy1E30 PqSm7+MPmr4HE+99YO+j/fUbVI+OeLKzllv2O1KBRw== X-Google-Smtp-Source: ABdhPJxohkqohF8Rold75mHYphEqgvgYH008wPvAAASt8psj0r6y3aoUKE/wT9nNKiSdXCRUmbbTz2P3mxtXYvrp7Oo= X-Received: by 2002:a17:906:af8c:: with SMTP id mj12mr28777718ejb.85.1605803992789; Thu, 19 Nov 2020 08:39:52 -0800 (PST) MIME-Version: 1.0 References: <20201119153901.53705-1-steven.price@arm.com> In-Reply-To: From: Peter Maydell Date: Thu, 19 Nov 2020 16:39:41 +0000 Message-ID: Subject: Re: [PATCH v5 0/2] MTE support for KVM guest To: Steven Price Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2a00:1450:4864:20::642; envelope-from=peter.maydell@linaro.org; helo=mail-ej1-x642.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 , "Dr. David Alan Gilbert" , Andrew Jones , Haibo Xu , Suzuki K Poulose , QEMU Developers , Catalin Marinas , Juan Quintela , Richard Henderson , lkml - Kernel Mailing List , Dave Martin , James Morse , arm-mail-list , Marc Zyngier , Thomas Gleixner , Will Deacon , kvmarm , Julien Thierry Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Thu, 19 Nov 2020 at 15:57, Steven Price wrote: > On 19/11/2020 15:45, Peter Maydell wrote: > > 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... > > I agree this needs some investigation - I'm hoping Haibo will be able to > provide some feedback here as he has been looking at the QEMU support. > However the VMM is likely going to require some significant changes to > ensure that migration doesn't break, so either way there's work to be done. > > Fundamentally most memory will need a mapping with PROT_MTE just so the > VMM can get at the tags for migration purposes, so QEMU is going to have > to learn how to treat guest memory specially if it wants to be able to > enable MTE for both itself and the guest. If the only reason the VMM needs tag access is for migration it feels like there must be a nicer way to do it than by requiring it to map the whole of the guest address space twice (once for normal use and once to get the tags)... Anyway, maybe "must map PROT_MTE" is workable, but it seems a bit premature to fix the kernel ABI as working that way until we are at least reasonably sure that it is the right design. thanks -- PMM 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=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 D52C8C6369E for ; Thu, 19 Nov 2020 16:39:57 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 0F8262220B for ; Thu, 19 Nov 2020 16:39:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="K7bWQ0Zc" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0F8262220B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org 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 70F294B4BE; Thu, 19 Nov 2020 11:39:56 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@linaro.org 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 k8wGb6W4OSF5; Thu, 19 Nov 2020 11:39:55 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 739DF4B538; Thu, 19 Nov 2020 11:39:55 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id EAB054B53B for ; Thu, 19 Nov 2020 11:39:54 -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 1U-gQAALWRgQ for ; Thu, 19 Nov 2020 11:39:54 -0500 (EST) Received: from mail-ej1-f67.google.com (mail-ej1-f67.google.com [209.85.218.67]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id D97464B4BE for ; Thu, 19 Nov 2020 11:39:53 -0500 (EST) Received: by mail-ej1-f67.google.com with SMTP id 7so8848661ejm.0 for ; Thu, 19 Nov 2020 08:39:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wHCeV+0wASxa7xKuZTzPc3uHjiByPnCWQmQdnty1SfE=; b=K7bWQ0Zc34TB663V4lX0Qpf54I3JpW4/Qv0E3aCd2FzmNzPEhOljrgVnmphkmOB1dc a6SoyQVZUAEKpTTkmOmFxaWEbyIHfNU1t5s4H+FGnQfBh3yN4A0dv3Jjpn7D4gdQJdwO Ju3cHL9f6IDj08kfEWIO22b2kY0KCvZqLgRoc06QwAaZrdQx8LsgIRI/fXWLbGC17jXb HMMexFgaVR1tx6U/qzRdJJFqAt6ocD2O2c/l/aEEZF7tOOrDJWmaySSX9sKRw4Ov4wXs joWmgV0j3pVCynbuzQOj93EchianKE39W9JT+KbSmq6jMP9MZyZAwS+f/yKTtTxNhQj6 GEZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wHCeV+0wASxa7xKuZTzPc3uHjiByPnCWQmQdnty1SfE=; b=MYZ+CNoK7n2hgnANJ0qj2nQ6DL92lraCTC50IeYNkWQ11tcnpXeceoHOWqus/Iqlkz IQ/L5XCn0xnCH/AvzaaM5DRtfxCreyTcp+davM7F2sZe58HSSUO1iFWTojw/tGIvp0th CeXbyFMwxnxSqWyS3kJ7tTA5V+wo5F/rAyWKS+AInLJyKIgma2TA5GwHzGONFD/RCyVC o/hb0Q3nDNwTZXYGSSE4fs7X+AzLgM8epbgUB/wJvZNbbE8uo2t0T1gm1GVs5+hU3WSq DgLLgeXcM0SFREUiChK9Ta77RwxxCYJ4aVRgrvjlS2mZUVjojR75hUSlgllRFe1JQNG2 KclQ== X-Gm-Message-State: AOAM533H6eroAh03jS+UTTnNpFZV70eMSQiZ9bb7MQPKRh0DzmhLeXzx v1riWWX+3oBwC80edCi36ltnkhUQxUpVe55uxgoKYA== X-Google-Smtp-Source: ABdhPJxohkqohF8Rold75mHYphEqgvgYH008wPvAAASt8psj0r6y3aoUKE/wT9nNKiSdXCRUmbbTz2P3mxtXYvrp7Oo= X-Received: by 2002:a17:906:af8c:: with SMTP id mj12mr28777718ejb.85.1605803992789; Thu, 19 Nov 2020 08:39:52 -0800 (PST) MIME-Version: 1.0 References: <20201119153901.53705-1-steven.price@arm.com> In-Reply-To: From: Peter Maydell Date: Thu, 19 Nov 2020 16:39:41 +0000 Message-ID: Subject: Re: [PATCH v5 0/2] MTE support for KVM guest To: Steven Price Cc: "Dr. David Alan Gilbert" , QEMU Developers , Catalin Marinas , Juan Quintela , Richard Henderson , lkml - Kernel Mailing List , Dave Martin , arm-mail-list , Marc Zyngier , Thomas Gleixner , Will Deacon , kvmarm 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 Thu, 19 Nov 2020 at 15:57, Steven Price wrote: > On 19/11/2020 15:45, Peter Maydell wrote: > > 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... > > I agree this needs some investigation - I'm hoping Haibo will be able to > provide some feedback here as he has been looking at the QEMU support. > However the VMM is likely going to require some significant changes to > ensure that migration doesn't break, so either way there's work to be done. > > Fundamentally most memory will need a mapping with PROT_MTE just so the > VMM can get at the tags for migration purposes, so QEMU is going to have > to learn how to treat guest memory specially if it wants to be able to > enable MTE for both itself and the guest. If the only reason the VMM needs tag access is for migration it feels like there must be a nicer way to do it than by requiring it to map the whole of the guest address space twice (once for normal use and once to get the tags)... Anyway, maybe "must map PROT_MTE" is workable, but it seems a bit premature to fix the kernel ABI as working that way until we are at least reasonably sure that it is the right design. thanks -- PMM _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm 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=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 0591FC56201 for ; Thu, 19 Nov 2020 16:41:07 +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 6DF732220B for ; Thu, 19 Nov 2020 16:41:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="oDUrfkld"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="K7bWQ0Zc" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6DF732220B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org 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-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=pL9oEyJj8nkkUA2vzHqkwm/wmDVnM+sGD8Pry1jl79o=; b=oDUrfkldVsNMGlBdCpk1kE187 t6u5qh5Qwd8NeSj1dF9K+t6kLB2WWavYWS76hFy4Yx6go9nRYgS23cn6tZIpy7sAFA+AfAdl3pDRS FbUgnybsHoNTOeCynV7s2Yw2W3K80VLwItKrb0RvyNeUgJWvW9uWV8uPSrMIQKJ1wB4eVeASY8RMq aoWCMch5SmrmO0S3hjal5l/1BCmhS6AIRef39fQRbbFyBHtqqKBA+sZsEFuGYdfS+BHm0nyZcDldU k9src7qSfoQjpcZKFGRaZ6Gy2M2woaw0ih5uSN46yC6fWgQ+5A/bLkFvmry/jAJnWRG9nBHUSAE+v 71e/zem5Q==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kfmyR-0007k8-RZ; Thu, 19 Nov 2020 16:39:55 +0000 Received: from mail-ej1-x643.google.com ([2a00:1450:4864:20::643]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kfmyP-0007jU-OT for linux-arm-kernel@lists.infradead.org; Thu, 19 Nov 2020 16:39:55 +0000 Received: by mail-ej1-x643.google.com with SMTP id y17so8779072ejh.11 for ; Thu, 19 Nov 2020 08:39:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wHCeV+0wASxa7xKuZTzPc3uHjiByPnCWQmQdnty1SfE=; b=K7bWQ0Zc34TB663V4lX0Qpf54I3JpW4/Qv0E3aCd2FzmNzPEhOljrgVnmphkmOB1dc a6SoyQVZUAEKpTTkmOmFxaWEbyIHfNU1t5s4H+FGnQfBh3yN4A0dv3Jjpn7D4gdQJdwO Ju3cHL9f6IDj08kfEWIO22b2kY0KCvZqLgRoc06QwAaZrdQx8LsgIRI/fXWLbGC17jXb HMMexFgaVR1tx6U/qzRdJJFqAt6ocD2O2c/l/aEEZF7tOOrDJWmaySSX9sKRw4Ov4wXs joWmgV0j3pVCynbuzQOj93EchianKE39W9JT+KbSmq6jMP9MZyZAwS+f/yKTtTxNhQj6 GEZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wHCeV+0wASxa7xKuZTzPc3uHjiByPnCWQmQdnty1SfE=; b=pUGCEcUp3wT961tXld67Mh5eSvKF9/YgrDcY4iigB7V+8O/iGK/RNUQoLr1ohiz2JT wuM1S8xHYL0JXN4Ct//kh9vdOseXy0jK7FdO5NE0+IrMU29YWXSZxjdVonhEI+7QYmHV x7lGMlB9GVzCQWH6fI8cSKiiV0ePhi9EBegjpEEZrXtd9HUpM9Zk5Vqb7iRdrJRE/GXE tUZ4HWxl4YTwuXBaHovJW3v4MLjrHR2h/ICvhEiGIyLv2ME0bXUdCb6bNuRPtpt38S4f Ub9ZtSMvnp4wiSzh0oEPpiuUEkp9h9LtolsqAFMDBki7vwwaZn8/1ScZ+cz55BUknPDT LVtQ== X-Gm-Message-State: AOAM531JpybRBrloCIwsmbumw2N1Y+hBjooglUlnY44Q2OmbYgoJ3hIe sxYAlaMTj8n+2vr+Q/oZRQtlET8vcqhkoTPamBVJyg== X-Google-Smtp-Source: ABdhPJxohkqohF8Rold75mHYphEqgvgYH008wPvAAASt8psj0r6y3aoUKE/wT9nNKiSdXCRUmbbTz2P3mxtXYvrp7Oo= X-Received: by 2002:a17:906:af8c:: with SMTP id mj12mr28777718ejb.85.1605803992789; Thu, 19 Nov 2020 08:39:52 -0800 (PST) MIME-Version: 1.0 References: <20201119153901.53705-1-steven.price@arm.com> In-Reply-To: From: Peter Maydell Date: Thu, 19 Nov 2020 16:39:41 +0000 Message-ID: Subject: Re: [PATCH v5 0/2] MTE support for KVM guest To: Steven Price X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201119_113954_101545_23AA01A2 X-CRM114-Status: GOOD ( 21.18 ) 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 , "Dr. David Alan Gilbert" , Andrew Jones , Haibo Xu , Suzuki K Poulose , QEMU Developers , Catalin Marinas , Juan Quintela , Richard Henderson , lkml - Kernel Mailing List , Dave Martin , James Morse , arm-mail-list , Marc Zyngier , Thomas Gleixner , Will Deacon , kvmarm , Julien Thierry 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 Thu, 19 Nov 2020 at 15:57, Steven Price wrote: > On 19/11/2020 15:45, Peter Maydell wrote: > > 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... > > I agree this needs some investigation - I'm hoping Haibo will be able to > provide some feedback here as he has been looking at the QEMU support. > However the VMM is likely going to require some significant changes to > ensure that migration doesn't break, so either way there's work to be done. > > Fundamentally most memory will need a mapping with PROT_MTE just so the > VMM can get at the tags for migration purposes, so QEMU is going to have > to learn how to treat guest memory specially if it wants to be able to > enable MTE for both itself and the guest. If the only reason the VMM needs tag access is for migration it feels like there must be a nicer way to do it than by requiring it to map the whole of the guest address space twice (once for normal use and once to get the tags)... Anyway, maybe "must map PROT_MTE" is workable, but it seems a bit premature to fix the kernel ABI as working that way until we are at least reasonably sure that it is the right design. thanks -- PMM _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel