From: Oliver Upton <oliver.upton@linux.dev>
To: Ricardo Koller <ricarkol@google.com>
Cc: kvm@vger.kernel.org, kvmarm@lists.linux.dev,
andrew.jones@linux.dev, pbonzini@redhat.com, maz@kernel.org,
alexandru.elisei@arm.com, eric.auger@redhat.com,
yuzenghui@huawei.com
Subject: Re: [PATCH 1/4] KVM: selftests: aarch64: Relax userfaultfd read vs. write checks
Date: Mon, 23 Jan 2023 23:07:25 +0000 [thread overview]
Message-ID: <Y88TLcuetXMSYyfD@google.com> (raw)
In-Reply-To: <20230110022432.330151-2-ricarkol@google.com>
On Tue, Jan 10, 2023 at 02:24:29AM +0000, Ricardo Koller wrote:
> Only Stage1 Page table walks (S1PTW) writing a PTE on an unmapped page
> should result in a userfaultfd write. However, the userfaultfd tests in
> page_fault_test wrongly assert that any S1PTW is a PTE write.
>
> Fix this by relaxing the read vs. write checks in all userfaultfd handlers.
> Note that this is also an attempt to focus less on KVM (and userfaultfd)
> behavior, and more on architectural behavior. Also note that after commit
> "KVM: arm64: Fix S1PTW handling on RO memslots" the userfaultfd fault
> (S1PTW with AF on an unmaped PTE page) is actually a read: the translation
> fault that comes before the permission fault.
I certainly agree that we cannot make assertions about read v. write
when registering uffd in 'missing' mode. We probably need another test
to assert that we get write faults for hardware AF updates when using
uffd in write protect mode.
--
Thanks,
Oliver
next prev parent reply other threads:[~2023-01-23 23:07 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-10 2:24 [PATCH 0/4] KVM: selftests: aarch64: page_fault_test S1PTW related fixes Ricardo Koller
2023-01-10 2:24 ` [PATCH 1/4] KVM: selftests: aarch64: Relax userfaultfd read vs. write checks Ricardo Koller
2023-01-23 23:07 ` Oliver Upton [this message]
2023-01-24 16:17 ` Ricardo Koller
2023-01-24 18:40 ` Oliver Upton
2023-01-10 2:24 ` [PATCH 2/4] KVM: selftests: aarch64: Do not default to dirty PTE pages on all S1PTWs Ricardo Koller
2023-01-10 2:24 ` [PATCH 3/4] KVM: selftests: aarch64: Fix check of dirty log PT write Ricardo Koller
2023-01-10 2:24 ` [PATCH 4/4] KVM: selftests: aarch64: Test read-only PT memory regions Ricardo Koller
2023-01-23 23:36 ` Oliver Upton
2023-01-24 16:26 ` Ricardo Koller
2023-01-24 19:54 ` Oliver Upton
2023-01-25 12:26 ` Marc Zyngier
2023-01-25 14:02 ` Ricardo Koller
2023-01-25 14:14 ` Marc Zyngier
2023-01-23 23:41 ` [PATCH 0/4] KVM: selftests: aarch64: page_fault_test S1PTW related fixes Oliver Upton
2023-01-23 23:43 ` Oliver Upton
2023-01-24 16:16 ` Ricardo Koller
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=Y88TLcuetXMSYyfD@google.com \
--to=oliver.upton@linux.dev \
--cc=alexandru.elisei@arm.com \
--cc=andrew.jones@linux.dev \
--cc=eric.auger@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=maz@kernel.org \
--cc=pbonzini@redhat.com \
--cc=ricarkol@google.com \
--cc=yuzenghui@huawei.com \
/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.