All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Oliver Upton <oliver.upton@linux.dev>
Cc: James Morse <james.morse@arm.com>,
	linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
	Quentin Perret <qperret@google.com>,
	Will Deacon <will@kernel.org>, Reiji Watanabe <reijiw@google.com>
Subject: Re: [PATCH 4/5] KVM: arm64: Correctly handle page aging notifiers for unaligned memlsot
Date: Thu, 12 Jan 2023 15:44:50 +0000	[thread overview]
Message-ID: <86bkn3oiz1.wl-maz@kernel.org> (raw)
In-Reply-To: <20230111000300.2034799-5-oliver.upton@linux.dev>

On Wed, 11 Jan 2023 00:02:59 +0000,
Oliver Upton <oliver.upton@linux.dev> wrote:
> 
> Userspace is allowed to select any PAGE_SIZE aligned hva to back guest
> memory. This is even the case with hugepages, although it is a rather
> suboptimal configuration as PTE level mappings are used at stage-2.
> 
> The page aging notifiers have an assumption that the spefified range
> is exactly one page/block of memory, which in the aforementioned case is
> not necessarily true. All together this leads to a rather obvious kernel
> WARN when using an unaligned memslot:
> 
> However, the WARN is only part of the issue as the table walkers visit
> at most a single leaf PTE. For hugepage-backed memory that is at a
> suboptimal alignment in the memslot, page aging entirely misses accesses
> to the hugepage at an offset greater than PAGE_SIZE.
> 
> Pass through the size of the notifier range to the table walkers and
> traverse the full range of memory requested. While at it, drop the WARN
> from before as it is clearly a valid condition.

Rather than changing the low-level walker, with the oddity that it
generates (patch #3), couldn't we instead just iterate over the range
and only process one entry at a time? All we need to know is the level
of the last processed entry to progress to the following block...

Thoughts?

	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: James Morse <james.morse@arm.com>,
	linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
	Quentin Perret <qperret@google.com>,
	Will Deacon <will@kernel.org>, Reiji Watanabe <reijiw@google.com>
Subject: Re: [PATCH 4/5] KVM: arm64: Correctly handle page aging notifiers for unaligned memlsot
Date: Thu, 12 Jan 2023 15:44:50 +0000	[thread overview]
Message-ID: <86bkn3oiz1.wl-maz@kernel.org> (raw)
In-Reply-To: <20230111000300.2034799-5-oliver.upton@linux.dev>

On Wed, 11 Jan 2023 00:02:59 +0000,
Oliver Upton <oliver.upton@linux.dev> wrote:
> 
> Userspace is allowed to select any PAGE_SIZE aligned hva to back guest
> memory. This is even the case with hugepages, although it is a rather
> suboptimal configuration as PTE level mappings are used at stage-2.
> 
> The page aging notifiers have an assumption that the spefified range
> is exactly one page/block of memory, which in the aforementioned case is
> not necessarily true. All together this leads to a rather obvious kernel
> WARN when using an unaligned memslot:
> 
> However, the WARN is only part of the issue as the table walkers visit
> at most a single leaf PTE. For hugepage-backed memory that is at a
> suboptimal alignment in the memslot, page aging entirely misses accesses
> to the hugepage at an offset greater than PAGE_SIZE.
> 
> Pass through the size of the notifier range to the table walkers and
> traverse the full range of memory requested. While at it, drop the WARN
> from before as it is clearly a valid condition.

Rather than changing the low-level walker, with the oddity that it
generates (patch #3), couldn't we instead just iterate over the range
and only process one entry at a time? All we need to know is the level
of the last processed entry to progress to the following block...

Thoughts?

	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:[~2023-01-12 15:44 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-11  0:02 [PATCH 0/5] KVM: arm64: Handle unaligned memslots in kvm_(test_)_age_gfn() Oliver Upton
2023-01-11  0:02 ` Oliver Upton
2023-01-11  0:02 ` [PATCH 1/5] KVM: arm64: Hoist S2 PTE definitions into kvm_pgtable.h Oliver Upton
2023-01-11  0:02   ` Oliver Upton
2023-01-11  0:02 ` [PATCH 2/5] KVM: arm64: Add a mask for all leaf PTE attributes Oliver Upton
2023-01-11  0:02   ` Oliver Upton
2023-01-11  0:02 ` [PATCH 3/5] KVM: arm64: Only return attributes from stage2_update_leaf_attrs() Oliver Upton
2023-01-11  0:02   ` Oliver Upton
2023-01-11  8:52   ` Marc Zyngier
2023-01-11  8:52     ` Marc Zyngier
2023-01-11 17:21     ` Oliver Upton
2023-01-11 17:21       ` Oliver Upton
2023-02-02 22:08       ` Oliver Upton
2023-02-02 22:08         ` Oliver Upton
2023-02-07 14:56         ` Marc Zyngier
2023-02-07 14:56           ` Marc Zyngier
2023-01-11  0:02 ` [PATCH 4/5] KVM: arm64: Correctly handle page aging notifiers for unaligned memlsot Oliver Upton
2023-01-11  0:02   ` Oliver Upton
2023-01-12 15:44   ` Marc Zyngier [this message]
2023-01-12 15:44     ` Marc Zyngier
2023-01-11  0:03 ` [PATCH 5/5] KVM: arm64: Consistently use KVM's types/helpers in kvm_age_gfn() Oliver Upton
2023-01-11  0:03   ` Oliver Upton

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=86bkn3oiz1.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=james.morse@arm.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=oliver.upton@linux.dev \
    --cc=qperret@google.com \
    --cc=reijiw@google.com \
    --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.