Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp4489932pxj; Tue, 22 Jun 2021 01:09:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx7VX3H14z2Vxe+9ei9SAUqa36M2lV/Ih3BvtRM+sDai33UEZVGmJUszTHSjw1AYjda7iGK X-Received: by 2002:a5e:9306:: with SMTP id k6mr1920271iom.157.1624349359104; Tue, 22 Jun 2021 01:09:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624349359; cv=none; d=google.com; s=arc-20160816; b=P3SMipRP/OYXadukMFiQB2mSJGc9kL2g/r84lTfvhsjfKBBIlf53r5LsFh67LvidEz Gwbh4RLZPTVcWrZcsaDw0eueYg3ZgcsKyWcKkeoiU9enbmn1hUBIvW3biaRQAziDLaZq tpB9qyxhXp8aLuGOqvu5kZhYF68PlvcRiHiFi6D1o7v5EwiMJkIwjRKYlyhE7lSaF9fN n0PuNMJ2crLOzxLQBxBnq/wL46ucfBYStRAhwZHeJM2DQnpMEJGpB6O8x/ozMVqzABBT wzflYo9C/IA7aN6X6R/ze+LOW42m53AvWo47VaJyu2NKKuXLdHPd7N/LgUfJ9sibR70f 19hQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=Beo38iuohodlyRGHyjXttlsvIYg9mKSm+zuOAhH7bbI=; b=c/6ZfmYS+anhvchhnmj3bFrgNk68s0JGlwgaRj+N/rDIeh3CDGXsb4kd1Nn8syvT/n DvSQ28tXkfGqeSpLh+2Ca4YQLCg+DyrXjI/SdJAs8AuxKAkKZlDGFKB9H//RflzlRnbN 5q5j1VU3OsLm/JlhQnfstsaTVcGaBbYll+Cpqjnid6ipnhWhBAEXwkJUxauWTe53GFPD o4fRWJSziGU/5PPL9yjfV73sv4Cwh7BRBiDw5M8jdrL1R1odQS0u8xhGC80GpA+xtvfS IT1YEKK50uvAj8GOoUl3cYuGtZNRbxL6ZCKZSOV9t3HWJS+/drWUjlFrzT+pXDagk+vZ arnw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=eXFdd6Vx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c4si9791961ilk.14.2021.06.22.01.09.06; Tue, 22 Jun 2021 01:09:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=eXFdd6Vx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229970AbhFVIKr (ORCPT + 99 others); Tue, 22 Jun 2021 04:10:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42318 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229853AbhFVIKo (ORCPT ); Tue, 22 Jun 2021 04:10:44 -0400 Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6490FC061574 for ; Tue, 22 Jun 2021 01:08:28 -0700 (PDT) Received: by mail-ot1-x32d.google.com with SMTP id o17-20020a9d76510000b02903eabfc221a9so20480359otl.0 for ; Tue, 22 Jun 2021 01:08:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Beo38iuohodlyRGHyjXttlsvIYg9mKSm+zuOAhH7bbI=; b=eXFdd6VxuZa/DYPOmOXnXEky4VQsJMT/UQpduHu02BEU1YhAn1pFfY4FaYLDYL+ikC uAHK2J/vbGb40UKTAEfT/yo1IYWvbxUDVqFGzgBAydAhPlRO4zmhMwZL5+u7HGavYZKH H12WEshODfMx+D7fAubGmbmY9lBoPGpqkW3J/X+5gcKxM/i2xzfNbVMqDiYsTU1158qs gg9IWNeR2Yza7A5Ic/pwJaQ449BMitgtZvwr4VOY6PjYgZeq5ar+lh1ej3pCQJ9MnJwZ JvE5EgYzJz7WiQzsrYxSPY3I6n1l+xuGf8aj3ziygHc6+Z2EAocVErEEFRefl+xrNi8E nKHw== 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=Beo38iuohodlyRGHyjXttlsvIYg9mKSm+zuOAhH7bbI=; b=V4I5xPjRGD79gAb/iJ1iS0SmskqW/Swd6MI0mD0mw07KkJTdfQLqgt4O6U2v0smJiy PDqpY9AtZqq0bid0BtR6Ngz0Jk0/ElXBngg7oifQe6nuK2TpE2i7xKu7UX9BFFzj1OmK Unry5XsiSJbJAdJZOmKTtQ6VcT7hlAVXoul4FbDoq72LjWTKsKgvmCvq7p/jhCKtV/WC C2gfmihxx+pX1fE8gFYBBIkm8rruH3DcQmrrDYVr/OrWKqhx/eq9SsynQM5+egMdE1Ev 87bpif2740Ji90IdDhixBt48V7ukubiCDo0wMkJTbWjeY3ZU/QNbeO2r7CcEEYPHbnN6 a/jA== X-Gm-Message-State: AOAM5326Z8QBdBU77PuBj64qGthA5r4ynAHgMHWcZIRKtS3rCPFyb9fz KIMG7SbzacGtVIIxFbxRb71IGZXZdWFnTJEHYY6GvQ== X-Received: by 2002:a05:6830:1598:: with SMTP id i24mr2089639otr.52.1624349307481; Tue, 22 Jun 2021 01:08:27 -0700 (PDT) MIME-Version: 1.0 References: <20210621111716.37157-1-steven.price@arm.com> <20210621111716.37157-5-steven.price@arm.com> In-Reply-To: <20210621111716.37157-5-steven.price@arm.com> From: Fuad Tabba Date: Tue, 22 Jun 2021 09:07:51 +0100 Message-ID: Subject: Re: [PATCH v17 4/6] KVM: arm64: Expose KVM_ARM_CAP_MTE To: Steven Price Cc: Catalin Marinas , Marc Zyngier , Will Deacon , "Dr. David Alan Gilbert" , qemu-devel@nongnu.org, Dave Martin , Juan Quintela , Richard Henderson , linux-kernel@vger.kernel.org, Thomas Gleixner , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Mon, Jun 21, 2021 at 12:18 PM Steven Price wrote: > > It's now safe for the VMM to enable MTE in a guest, so expose the > capability to user space. > > Reviewed-by: Catalin Marinas > Signed-off-by: Steven Price > --- > arch/arm64/kvm/arm.c | 9 +++++++++ > arch/arm64/kvm/reset.c | 4 ++++ > arch/arm64/kvm/sys_regs.c | 3 +++ > 3 files changed, 16 insertions(+) > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c > index e720148232a0..28ce26a68f09 100644 > --- a/arch/arm64/kvm/arm.c > +++ b/arch/arm64/kvm/arm.c > @@ -93,6 +93,12 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm, > r = 0; > kvm->arch.return_nisv_io_abort_to_user = true; > break; > + case KVM_CAP_ARM_MTE: > + if (!system_supports_mte() || kvm->created_vcpus) > + return -EINVAL; > + r = 0; > + kvm->arch.mte_enabled = true; > + break; > default: > r = -EINVAL; > break; > @@ -237,6 +243,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) > */ > r = 1; > break; > + case KVM_CAP_ARM_MTE: > + r = system_supports_mte(); > + break; > case KVM_CAP_STEAL_TIME: > r = kvm_arm_pvtime_supported(); > break; > diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c > index d37ebee085cf..9e6922b9503a 100644 > --- a/arch/arm64/kvm/reset.c > +++ b/arch/arm64/kvm/reset.c > @@ -244,6 +244,10 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu) > switch (vcpu->arch.target) { > default: > if (test_bit(KVM_ARM_VCPU_EL1_32BIT, vcpu->arch.features)) { > + if (vcpu->kvm->arch.mte_enabled) { > + ret = -EINVAL; > + goto out; > + } > pstate = VCPU_RESET_PSTATE_SVC; > } else { > pstate = VCPU_RESET_PSTATE_EL1; nit: I was wondering whether this check would be better suited in kvm_vcpu_set_target, rather than here (kvm_reset_vcpu). kvm_reset_vcpu is called by kvm_vcpu_set_target, but kvm_vcpu_set_target is where checking for supported features happens. It might be better to group all such checks together. I don't think that there is any risk of this feature being toggled by the other call path to kvm_reset_vcpu (via check_vcpu_requests). Cheers, /fuad > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c > index 5c75b24eae21..f6f126eb6ac1 100644 > --- a/arch/arm64/kvm/sys_regs.c > +++ b/arch/arm64/kvm/sys_regs.c > @@ -1312,6 +1312,9 @@ static bool access_ccsidr(struct kvm_vcpu *vcpu, struct sys_reg_params *p, > static unsigned int mte_visibility(const struct kvm_vcpu *vcpu, > const struct sys_reg_desc *rd) > { > + if (kvm_has_mte(vcpu->kvm)) > + return 0; > + > return REG_HIDDEN; > } > > -- > 2.20.1 > > _______________________________________________ > kvmarm mailing list > kvmarm@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/kvmarm