All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Fuad Tabba <tabba@google.com>
Cc: Steven Price <steven.price@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	qemu-devel@nongnu.org, Dave Martin <Dave.Martin@arm.com>,
	Juan Quintela <quintela@redhat.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v17 4/6] KVM: arm64: Expose KVM_ARM_CAP_MTE
Date: Tue, 22 Jun 2021 09:48:33 +0100	[thread overview]
Message-ID: <877dimcmji.wl-maz@kernel.org> (raw)
In-Reply-To: <CA+EHjTzuduzTcJo+jjVzVAVUB4i3Nr3mki4jyiNW9K=pr-HPYA@mail.gmail.com>

On Tue, 22 Jun 2021 09:07:51 +0100,
Fuad Tabba <tabba@google.com> wrote:
> 
> Hi,
> 
> On Mon, Jun 21, 2021 at 12:18 PM Steven Price <steven.price@arm.com> 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 <catalin.marinas@arm.com>
> > Signed-off-by: Steven Price <steven.price@arm.com>
> > ---
> >  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).

We already group the 32bit related compatibility checks in
vcpu_allowed_register_width(), and this is where I think this should
move to. I've provisionally added the change below.

	M.

diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index 9e6922b9503a..cba7872d69a8 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -176,6 +176,10 @@ static bool vcpu_allowed_register_width(struct kvm_vcpu *vcpu)
 	if (!cpus_have_const_cap(ARM64_HAS_32BIT_EL1) && is32bit)
 		return false;
 
+	/* MTE is incompatible with AArch32 */
+	if (kvm_has_mte(vcpu->kvm) && is32bit)
+		return false;
+
 	/* Check that the vcpus are either all 32bit or all 64bit */
 	kvm_for_each_vcpu(i, tmp, vcpu->kvm) {
 		if (vcpu_has_feature(tmp, KVM_ARM_VCPU_EL1_32BIT) != is32bit)
@@ -244,10 +248,6 @@ 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;


-- 
Without deviation from the norm, progress is not possible.

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Fuad Tabba <tabba@google.com>
Cc: Juan Quintela <quintela@redhat.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	qemu-devel@nongnu.org,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Steven Price <steven.price@arm.com>,
	Will Deacon <will@kernel.org>, Dave Martin <Dave.Martin@arm.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v17 4/6] KVM: arm64: Expose KVM_ARM_CAP_MTE
Date: Tue, 22 Jun 2021 09:48:33 +0100	[thread overview]
Message-ID: <877dimcmji.wl-maz@kernel.org> (raw)
In-Reply-To: <CA+EHjTzuduzTcJo+jjVzVAVUB4i3Nr3mki4jyiNW9K=pr-HPYA@mail.gmail.com>

On Tue, 22 Jun 2021 09:07:51 +0100,
Fuad Tabba <tabba@google.com> wrote:
> 
> Hi,
> 
> On Mon, Jun 21, 2021 at 12:18 PM Steven Price <steven.price@arm.com> 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 <catalin.marinas@arm.com>
> > Signed-off-by: Steven Price <steven.price@arm.com>
> > ---
> >  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).

We already group the 32bit related compatibility checks in
vcpu_allowed_register_width(), and this is where I think this should
move to. I've provisionally added the change below.

	M.

diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index 9e6922b9503a..cba7872d69a8 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -176,6 +176,10 @@ static bool vcpu_allowed_register_width(struct kvm_vcpu *vcpu)
 	if (!cpus_have_const_cap(ARM64_HAS_32BIT_EL1) && is32bit)
 		return false;
 
+	/* MTE is incompatible with AArch32 */
+	if (kvm_has_mte(vcpu->kvm) && is32bit)
+		return false;
+
 	/* Check that the vcpus are either all 32bit or all 64bit */
 	kvm_for_each_vcpu(i, tmp, vcpu->kvm) {
 		if (vcpu_has_feature(tmp, KVM_ARM_VCPU_EL1_32BIT) != is32bit)
@@ -244,10 +248,6 @@ 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;


-- 
Without deviation from the norm, progress is not possible.


WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Fuad Tabba <tabba@google.com>
Cc: Juan Quintela <quintela@redhat.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	qemu-devel@nongnu.org,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Steven Price <steven.price@arm.com>,
	Will Deacon <will@kernel.org>, Dave Martin <Dave.Martin@arm.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v17 4/6] KVM: arm64: Expose KVM_ARM_CAP_MTE
Date: Tue, 22 Jun 2021 09:48:33 +0100	[thread overview]
Message-ID: <877dimcmji.wl-maz@kernel.org> (raw)
In-Reply-To: <CA+EHjTzuduzTcJo+jjVzVAVUB4i3Nr3mki4jyiNW9K=pr-HPYA@mail.gmail.com>

On Tue, 22 Jun 2021 09:07:51 +0100,
Fuad Tabba <tabba@google.com> wrote:
> 
> Hi,
> 
> On Mon, Jun 21, 2021 at 12:18 PM Steven Price <steven.price@arm.com> 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 <catalin.marinas@arm.com>
> > Signed-off-by: Steven Price <steven.price@arm.com>
> > ---
> >  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).

We already group the 32bit related compatibility checks in
vcpu_allowed_register_width(), and this is where I think this should
move to. I've provisionally added the change below.

	M.

diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index 9e6922b9503a..cba7872d69a8 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -176,6 +176,10 @@ static bool vcpu_allowed_register_width(struct kvm_vcpu *vcpu)
 	if (!cpus_have_const_cap(ARM64_HAS_32BIT_EL1) && is32bit)
 		return false;
 
+	/* MTE is incompatible with AArch32 */
+	if (kvm_has_mte(vcpu->kvm) && is32bit)
+		return false;
+
 	/* Check that the vcpus are either all 32bit or all 64bit */
 	kvm_for_each_vcpu(i, tmp, vcpu->kvm) {
 		if (vcpu_has_feature(tmp, KVM_ARM_VCPU_EL1_32BIT) != is32bit)
@@ -244,10 +248,6 @@ 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;


-- 
Without deviation from the norm, progress is not possible.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Fuad Tabba <tabba@google.com>
Cc: Steven Price <steven.price@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	qemu-devel@nongnu.org, Dave Martin <Dave.Martin@arm.com>,
	Juan Quintela <quintela@redhat.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v17 4/6] KVM: arm64: Expose KVM_ARM_CAP_MTE
Date: Tue, 22 Jun 2021 09:48:33 +0100	[thread overview]
Message-ID: <877dimcmji.wl-maz@kernel.org> (raw)
In-Reply-To: <CA+EHjTzuduzTcJo+jjVzVAVUB4i3Nr3mki4jyiNW9K=pr-HPYA@mail.gmail.com>

On Tue, 22 Jun 2021 09:07:51 +0100,
Fuad Tabba <tabba@google.com> wrote:
> 
> Hi,
> 
> On Mon, Jun 21, 2021 at 12:18 PM Steven Price <steven.price@arm.com> 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 <catalin.marinas@arm.com>
> > Signed-off-by: Steven Price <steven.price@arm.com>
> > ---
> >  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).

We already group the 32bit related compatibility checks in
vcpu_allowed_register_width(), and this is where I think this should
move to. I've provisionally added the change below.

	M.

diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index 9e6922b9503a..cba7872d69a8 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -176,6 +176,10 @@ static bool vcpu_allowed_register_width(struct kvm_vcpu *vcpu)
 	if (!cpus_have_const_cap(ARM64_HAS_32BIT_EL1) && is32bit)
 		return false;
 
+	/* MTE is incompatible with AArch32 */
+	if (kvm_has_mte(vcpu->kvm) && is32bit)
+		return false;
+
 	/* Check that the vcpus are either all 32bit or all 64bit */
 	kvm_for_each_vcpu(i, tmp, vcpu->kvm) {
 		if (vcpu_has_feature(tmp, KVM_ARM_VCPU_EL1_32BIT) != is32bit)
@@ -244,10 +248,6 @@ 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;


-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-06-22  8:48 UTC|newest]

Thread overview: 92+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-21 11:17 [PATCH v17 0/6] MTE support for KVM guest Steven Price
2021-06-21 11:17 ` Steven Price
2021-06-21 11:17 ` Steven Price
2021-06-21 11:17 ` Steven Price
2021-06-21 11:17 ` [PATCH v17 1/6] arm64: mte: Sync tags for pages where PTE is untagged Steven Price
2021-06-21 11:17   ` Steven Price
2021-06-21 11:17   ` Steven Price
2021-06-21 11:17   ` Steven Price
2021-06-21 11:17 ` [PATCH v17 2/6] KVM: arm64: Introduce MTE VM feature Steven Price
2021-06-21 11:17   ` Steven Price
2021-06-21 11:17   ` Steven Price
2021-06-21 11:17   ` Steven Price
2021-06-21 17:00   ` Fuad Tabba
2021-06-21 17:00     ` Fuad Tabba
2021-06-21 17:00     ` Fuad Tabba
2021-06-21 17:00     ` Fuad Tabba
2021-06-22 11:29     ` Marc Zyngier
2021-06-22 11:29       ` Marc Zyngier
2021-06-22 11:29       ` Marc Zyngier
2021-06-22 11:29       ` Marc Zyngier
2021-06-21 11:17 ` [PATCH v17 3/6] KVM: arm64: Save/restore MTE registers Steven Price
2021-06-21 11:17   ` Steven Price
2021-06-21 11:17   ` Steven Price
2021-06-21 11:17   ` Steven Price
2021-06-22  9:46   ` Fuad Tabba
2021-06-22  9:46     ` Fuad Tabba
2021-06-22  9:46     ` Fuad Tabba
2021-06-22  9:46     ` Fuad Tabba
2021-06-21 11:17 ` [PATCH v17 4/6] KVM: arm64: Expose KVM_ARM_CAP_MTE Steven Price
2021-06-21 11:17   ` Steven Price
2021-06-21 11:17   ` Steven Price
2021-06-21 11:17   ` Steven Price
2021-06-22  8:07   ` Fuad Tabba
2021-06-22  8:07     ` Fuad Tabba
2021-06-22  8:07     ` Fuad Tabba
2021-06-22  8:07     ` Fuad Tabba
2021-06-22  8:48     ` Marc Zyngier [this message]
2021-06-22  8:48       ` Marc Zyngier
2021-06-22  8:48       ` Marc Zyngier
2021-06-22  8:48       ` Marc Zyngier
2021-06-21 11:17 ` [PATCH v17 5/6] KVM: arm64: ioctl to fetch/store tags in a guest Steven Price
2021-06-21 11:17   ` Steven Price
2021-06-21 11:17   ` Steven Price
2021-06-21 11:17   ` Steven Price
2021-06-22  8:56   ` Fuad Tabba
2021-06-22  8:56     ` Fuad Tabba
2021-06-22  8:56     ` Fuad Tabba
2021-06-22  8:56     ` Fuad Tabba
2021-06-22 10:25     ` Marc Zyngier
2021-06-22 10:25       ` Marc Zyngier
2021-06-22 10:25       ` Marc Zyngier
2021-06-22 10:25       ` Marc Zyngier
2021-06-22 10:56       ` Fuad Tabba
2021-06-22 10:56         ` Fuad Tabba
2021-06-22 10:56         ` Fuad Tabba
2021-06-22 10:56         ` Fuad Tabba
2021-06-23 14:07         ` Steven Price
2021-06-23 14:07           ` Steven Price
2021-06-23 14:07           ` Steven Price
2021-06-23 14:07           ` Steven Price
2021-06-24 13:35   ` Marc Zyngier
2021-06-24 13:35     ` Marc Zyngier
2021-06-24 13:35     ` Marc Zyngier
2021-06-24 13:35     ` Marc Zyngier
2021-06-24 13:42     ` Steven Price
2021-06-24 13:42       ` Steven Price
2021-06-24 13:42       ` Steven Price
2021-06-24 13:42       ` Steven Price
2021-06-21 11:17 ` [PATCH v17 6/6] KVM: arm64: Document MTE capability and ioctl Steven Price
2021-06-21 11:17   ` Steven Price
2021-06-21 11:17   ` Steven Price
2021-06-21 11:17   ` Steven Price
2021-06-22  9:42   ` Fuad Tabba
2021-06-22  9:42     ` Fuad Tabba
2021-06-22  9:42     ` Fuad Tabba
2021-06-22  9:42     ` Fuad Tabba
2021-06-22 10:35     ` Marc Zyngier
2021-06-22 10:35       ` Marc Zyngier
2021-06-22 10:35       ` Marc Zyngier
2021-06-22 10:35       ` Marc Zyngier
2021-06-22 10:41       ` Fuad Tabba
2021-06-22 10:41         ` Fuad Tabba
2021-06-22 10:41         ` Fuad Tabba
2021-06-22 10:41         ` Fuad Tabba
2021-06-22 14:21 ` [PATCH v17 0/6] MTE support for KVM guest Marc Zyngier
2021-06-22 14:21   ` Marc Zyngier
2021-06-22 14:21   ` Marc Zyngier
2021-06-22 14:21   ` Marc Zyngier
2021-06-23 14:09   ` Steven Price
2021-06-23 14:09     ` Steven Price
2021-06-23 14:09     ` Steven Price
2021-06-23 14:09     ` Steven Price

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877dimcmji.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=Dave.Martin@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=dgilbert@redhat.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=richard.henderson@linaro.org \
    --cc=steven.price@arm.com \
    --cc=tabba@google.com \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.