All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Oliver Upton <oliver.upton@linux.dev>
Cc: kvm@vger.kernel.org, Will Deacon <will@kernel.org>,
	stable@vger.kernel.org, kvmarm@lists.linux.dev,
	kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/3] KVM: arm64: Fix S1PTW handling on RO memslots
Date: Wed, 21 Dec 2022 17:53:58 +0000	[thread overview]
Message-ID: <86k02kbq2x.wl-maz@kernel.org> (raw)
In-Reply-To: <Y6M5Vh+EGOhkR5hd@google.com>

On Wed, 21 Dec 2022 16:50:30 +0000,
Oliver Upton <oliver.upton@linux.dev> wrote:
> 
> On Wed, Dec 21, 2022 at 09:35:06AM +0000, Marc Zyngier wrote:
> 
> [...]
> 
> > > > +	if (kvm_vcpu_abt_iss1tw(vcpu)) {
> > > > +		/*
> > > > +		 * Only a permission fault on a S1PTW should be
> > > > +		 * considered as a write. Otherwise, page tables baked
> > > > +		 * in a read-only memslot will result in an exception
> > > > +		 * being delivered in the guest.
> > > 
> > > Somewhat of a tangent, but:
> > > 
> > > Aren't we somewhat unaligned with the KVM UAPI by injecting an
> > > exception in this case? I know we've been doing it for a while, but it
> > > flies in the face of the rules outlined in the
> > > KVM_SET_USER_MEMORY_REGION documentation.
> > 
> > That's an interesting point, and I certainly haven't considered that
> > for faults introduced by page table walks.
> > 
> > I'm not sure what userspace can do with that though. The problem is
> > that this is a write for which we don't have useful data: although we
> > know it is a page-table walker access, we don't know what it was about
> > to write. The instruction that caused the write is meaningless (it
> > could either be a load, a store, or an instruction fetch). How do you
> > populate the data[] field then?
> > 
> > If anything, this is closer to KVM_EXIT_ARM_NISV, for which we give
> > userspace the full ESR and ask it to sort it out. I doubt it will be
> > able to, but hey, maybe it is worth a shot. This would need to be a
> > different exit reason though, as NISV is explicitly for non-memslot
> > stuff.
> > 
> > In any case, the documentation for KVM_SET_USER_MEMORY_REGION needs to
> > reflect the fact that KVM_EXIT_MMIO cannot represent a fault due to a
> > S1 PTW.
> 
> Oh I completely agree with you here. I probably should have said before,
> I think the exit would be useless anyway. Getting the documentation in
> line with the intended behavior seems to be the best fix.

Right. How about something like this?

diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index 226b40baffb8..72abd018a618 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -1381,6 +1381,14 @@ It is recommended to use this API instead of the KVM_SET_MEMORY_REGION ioctl.
 The KVM_SET_MEMORY_REGION does not allow fine grained control over memory
 allocation and is deprecated.
 
+Note: On arm64, a write generated by the page-table walker (to update
+the Access and Dirty flags, for example) never results in a
+KVM_EXIT_MMIO exit when the slot has the KVM_MEM_READONLY flag. This
+is because KVM cannot provide the data that would be written by the
+page-table walker, making it impossible to emulate the access.
+Instead, an abort (data abort if the cause of the page-table update
+was a load or a store, instruction abort if it was an instruction
+fetch) is injected in the guest.
 
 4.36 KVM_SET_TSS_ADDR
 ---------------------

Thanks,

	M.

-- 
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: Oliver Upton <oliver.upton@linux.dev>
Cc: kvmarm@lists.cs.columbia.edu, kvmarm@lists.linux.dev,
	kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	James Morse <james.morse@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	Ard Biesheuvel <ardb@kernel.org>, Will Deacon <will@kernel.org>,
	Quentin Perret <qperret@google.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH 1/3] KVM: arm64: Fix S1PTW handling on RO memslots
Date: Wed, 21 Dec 2022 17:53:58 +0000	[thread overview]
Message-ID: <86k02kbq2x.wl-maz@kernel.org> (raw)
Message-ID: <20221221175358.2rZaAItOGWgcsJ_ihBoUxGN89dM8jHglY8Q-xtpbLfw@z> (raw)
In-Reply-To: <Y6M5Vh+EGOhkR5hd@google.com>

On Wed, 21 Dec 2022 16:50:30 +0000,
Oliver Upton <oliver.upton@linux.dev> wrote:
> 
> On Wed, Dec 21, 2022 at 09:35:06AM +0000, Marc Zyngier wrote:
> 
> [...]
> 
> > > > +	if (kvm_vcpu_abt_iss1tw(vcpu)) {
> > > > +		/*
> > > > +		 * Only a permission fault on a S1PTW should be
> > > > +		 * considered as a write. Otherwise, page tables baked
> > > > +		 * in a read-only memslot will result in an exception
> > > > +		 * being delivered in the guest.
> > > 
> > > Somewhat of a tangent, but:
> > > 
> > > Aren't we somewhat unaligned with the KVM UAPI by injecting an
> > > exception in this case? I know we've been doing it for a while, but it
> > > flies in the face of the rules outlined in the
> > > KVM_SET_USER_MEMORY_REGION documentation.
> > 
> > That's an interesting point, and I certainly haven't considered that
> > for faults introduced by page table walks.
> > 
> > I'm not sure what userspace can do with that though. The problem is
> > that this is a write for which we don't have useful data: although we
> > know it is a page-table walker access, we don't know what it was about
> > to write. The instruction that caused the write is meaningless (it
> > could either be a load, a store, or an instruction fetch). How do you
> > populate the data[] field then?
> > 
> > If anything, this is closer to KVM_EXIT_ARM_NISV, for which we give
> > userspace the full ESR and ask it to sort it out. I doubt it will be
> > able to, but hey, maybe it is worth a shot. This would need to be a
> > different exit reason though, as NISV is explicitly for non-memslot
> > stuff.
> > 
> > In any case, the documentation for KVM_SET_USER_MEMORY_REGION needs to
> > reflect the fact that KVM_EXIT_MMIO cannot represent a fault due to a
> > S1 PTW.
> 
> Oh I completely agree with you here. I probably should have said before,
> I think the exit would be useless anyway. Getting the documentation in
> line with the intended behavior seems to be the best fix.

Right. How about something like this?

diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index 226b40baffb8..72abd018a618 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -1381,6 +1381,14 @@ It is recommended to use this API instead of the KVM_SET_MEMORY_REGION ioctl.
 The KVM_SET_MEMORY_REGION does not allow fine grained control over memory
 allocation and is deprecated.
 
+Note: On arm64, a write generated by the page-table walker (to update
+the Access and Dirty flags, for example) never results in a
+KVM_EXIT_MMIO exit when the slot has the KVM_MEM_READONLY flag. This
+is because KVM cannot provide the data that would be written by the
+page-table walker, making it impossible to emulate the access.
+Instead, an abort (data abort if the cause of the page-table update
+was a load or a store, instruction abort if it was an instruction
+fetch) is injected in the guest.
 
 4.36 KVM_SET_TSS_ADDR
 ---------------------

Thanks,

	M.

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

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Oliver Upton <oliver.upton@linux.dev>
Cc: kvmarm@lists.cs.columbia.edu, kvmarm@lists.linux.dev,
	kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	James Morse <james.morse@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	Ard Biesheuvel <ardb@kernel.org>, Will Deacon <will@kernel.org>,
	Quentin Perret <qperret@google.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH 1/3] KVM: arm64: Fix S1PTW handling on RO memslots
Date: Wed, 21 Dec 2022 17:53:58 +0000	[thread overview]
Message-ID: <86k02kbq2x.wl-maz@kernel.org> (raw)
In-Reply-To: <Y6M5Vh+EGOhkR5hd@google.com>

On Wed, 21 Dec 2022 16:50:30 +0000,
Oliver Upton <oliver.upton@linux.dev> wrote:
> 
> On Wed, Dec 21, 2022 at 09:35:06AM +0000, Marc Zyngier wrote:
> 
> [...]
> 
> > > > +	if (kvm_vcpu_abt_iss1tw(vcpu)) {
> > > > +		/*
> > > > +		 * Only a permission fault on a S1PTW should be
> > > > +		 * considered as a write. Otherwise, page tables baked
> > > > +		 * in a read-only memslot will result in an exception
> > > > +		 * being delivered in the guest.
> > > 
> > > Somewhat of a tangent, but:
> > > 
> > > Aren't we somewhat unaligned with the KVM UAPI by injecting an
> > > exception in this case? I know we've been doing it for a while, but it
> > > flies in the face of the rules outlined in the
> > > KVM_SET_USER_MEMORY_REGION documentation.
> > 
> > That's an interesting point, and I certainly haven't considered that
> > for faults introduced by page table walks.
> > 
> > I'm not sure what userspace can do with that though. The problem is
> > that this is a write for which we don't have useful data: although we
> > know it is a page-table walker access, we don't know what it was about
> > to write. The instruction that caused the write is meaningless (it
> > could either be a load, a store, or an instruction fetch). How do you
> > populate the data[] field then?
> > 
> > If anything, this is closer to KVM_EXIT_ARM_NISV, for which we give
> > userspace the full ESR and ask it to sort it out. I doubt it will be
> > able to, but hey, maybe it is worth a shot. This would need to be a
> > different exit reason though, as NISV is explicitly for non-memslot
> > stuff.
> > 
> > In any case, the documentation for KVM_SET_USER_MEMORY_REGION needs to
> > reflect the fact that KVM_EXIT_MMIO cannot represent a fault due to a
> > S1 PTW.
> 
> Oh I completely agree with you here. I probably should have said before,
> I think the exit would be useless anyway. Getting the documentation in
> line with the intended behavior seems to be the best fix.

Right. How about something like this?

diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index 226b40baffb8..72abd018a618 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -1381,6 +1381,14 @@ It is recommended to use this API instead of the KVM_SET_MEMORY_REGION ioctl.
 The KVM_SET_MEMORY_REGION does not allow fine grained control over memory
 allocation and is deprecated.
 
+Note: On arm64, a write generated by the page-table walker (to update
+the Access and Dirty flags, for example) never results in a
+KVM_EXIT_MMIO exit when the slot has the KVM_MEM_READONLY flag. This
+is because KVM cannot provide the data that would be written by the
+page-table walker, making it impossible to emulate the access.
+Instead, an abort (data abort if the cause of the page-table update
+was a load or a store, instruction abort if it was an instruction
+fetch) is injected in the guest.
 
 4.36 KVM_SET_TSS_ADDR
 ---------------------

Thanks,

	M.

-- 
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:[~2022-12-21 17:54 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-20 20:09 [PATCH 0/3] KVM: arm64: Fix handling of S1PTW S2 fault on RO memslots Marc Zyngier
2022-12-20 20:09 ` Marc Zyngier
2022-12-20 20:09 ` Marc Zyngier
2022-12-20 20:09 ` [PATCH 1/3] KVM: arm64: Fix S1PTW handling " Marc Zyngier
2022-12-20 20:09   ` Marc Zyngier
2022-12-20 20:09   ` Marc Zyngier
2022-12-20 21:47   ` Oliver Upton
2022-12-20 21:47     ` Oliver Upton
2022-12-20 21:47     ` Oliver Upton
2022-12-21  9:35     ` Marc Zyngier
2022-12-21  9:35       ` Marc Zyngier
2022-12-21  9:35       ` Marc Zyngier
2022-12-21 16:50       ` Oliver Upton
2022-12-21 16:50         ` Oliver Upton
2022-12-21 16:50         ` Oliver Upton
2022-12-21 17:53         ` Marc Zyngier [this message]
2022-12-21 17:53           ` Marc Zyngier
2022-12-21 17:53           ` Marc Zyngier
2022-12-21 18:26           ` Oliver Upton
2022-12-21 18:26             ` Oliver Upton
2022-12-21 18:26             ` Oliver Upton
2022-12-22 13:01   ` Ard Biesheuvel
2022-12-22 13:01     ` Ard Biesheuvel
2022-12-22 13:01     ` Ard Biesheuvel
2022-12-24 12:18     ` Marc Zyngier
2022-12-24 12:18       ` Marc Zyngier
2022-12-24 12:18       ` Marc Zyngier
2022-12-24 13:09       ` Ard Biesheuvel
2022-12-24 13:09         ` Ard Biesheuvel
2022-12-24 13:09         ` Ard Biesheuvel
2022-12-20 20:09 ` [PATCH 2/3] KVM: arm64: Handle S1PTW translation with TCR_HA set as a write Marc Zyngier
2022-12-20 20:09   ` Marc Zyngier
2022-12-20 20:09   ` Marc Zyngier
2022-12-21 16:46   ` Ricardo Koller
2022-12-21 16:46     ` Ricardo Koller
2022-12-21 16:46     ` Ricardo Koller
2022-12-21 17:43     ` Marc Zyngier
2022-12-21 17:43       ` Marc Zyngier
2022-12-21 17:43       ` Marc Zyngier
2022-12-23  0:33       ` Ricardo Koller
2022-12-23  0:33         ` Ricardo Koller
2022-12-23  0:33         ` Ricardo Koller
2022-12-21 17:46     ` Oliver Upton
2022-12-21 17:46       ` Oliver Upton
2022-12-21 17:46       ` Oliver Upton
2022-12-22  9:01       ` Marc Zyngier
2022-12-22  9:01         ` Marc Zyngier
2022-12-22  9:01         ` Marc Zyngier
2022-12-22 20:58         ` Oliver Upton
2022-12-22 20:58           ` Oliver Upton
2022-12-22 20:58           ` Oliver Upton
2022-12-23  1:00           ` Ricardo Koller
2022-12-23  1:00             ` Ricardo Koller
2022-12-23  1:00             ` Ricardo Koller
2022-12-24 11:59           ` Marc Zyngier
2022-12-24 11:59             ` Marc Zyngier
2022-12-24 11:59             ` Marc Zyngier
2022-12-20 20:09 ` [PATCH 3/3] KVM: arm64: Convert FSC_* over to ESR_ELx_FSC_* Marc Zyngier
2022-12-20 20:09   ` Marc Zyngier
2022-12-20 20:09   ` Marc Zyngier

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=86k02kbq2x.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=oliver.upton@linux.dev \
    --cc=stable@vger.kernel.org \
    --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.