From: Sean Christopherson <seanjc@google.com>
To: Yosry Ahmed <yosry.ahmed@linux.dev>
Cc: Oliver Upton <oliver.upton@linux.dev>,
Itaru Kitayama <itaru.kitayama@linux.dev>,
kvmarm@lists.linux.dev, Jim Mattson <jmattson@google.com>
Subject: Re: RFC KVM: arm64: selftest: stage 2 mapping helpers
Date: Thu, 23 Oct 2025 08:46:33 -0700 [thread overview]
Message-ID: <aPpN2U7lq8ZDdHx9@google.com> (raw)
In-Reply-To: <zqtfz6k3mud5rjmnfy45pdvqhmf33mkqvmtsvayf7pjz2buoiw@m5z5rqqhiqh6>
On Wed, Oct 22, 2025, Yosry Ahmed wrote:
> On Wed, Oct 22, 2025 at 10:47:15AM -0700, Oliver Upton wrote:
> > On Wed, Oct 22, 2025 at 04:57:16PM +0000, Yosry Ahmed wrote:
> > > On Wed, Oct 22, 2025 at 06:34:58AM -0700, Sean Christopherson wrote:
> > IOW, the starting point for us is fine-grained control over potentially
> > multiple stage-2 MMUs with modal descriptor fields that change meaning
> > based on the current MMU context.
> >
> > > > I.e. if we envision any arch-agnositic tests that can do nested things,
> > > > now's the time. E.g. running dirty logging tests in L2 maybe?
> >
> > We can just as easily implement an agnostic wrapper after the fact;
> > enabling architectural validation of the arm64 nested implementation is
> > the highest priority at the moment for us.
>
> Oh 100%, I was not suggesting that we need to do this now, not sure if
> Sean was.
I was maybe 60% suggesting that? :-)
But it sounds like the underlying x86 and arm64 details are going to be much more
different than I was anticipating, so I'm a-ok punting for now. E.g. I was thinking
we'd want a common kvm_mmu_arch or kvm_stage2_arch, but trying to implement such
structures without a concrete use case would likely be painful/ugly.
prev parent reply other threads:[~2025-10-23 15:46 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-20 9:08 RFC KVM: arm64: selftest: stage 2 mapping helpers Itaru Kitayama
2025-10-20 23:55 ` Oliver Upton
2025-10-22 5:25 ` Itaru Kitayama
2025-10-22 9:05 ` Oliver Upton
2025-10-25 0:24 ` Itaru Kitayama
2025-10-22 13:34 ` Sean Christopherson
2025-10-22 16:57 ` Yosry Ahmed
2025-10-22 17:47 ` Oliver Upton
2025-10-22 17:50 ` Yosry Ahmed
2025-10-23 15:46 ` Sean Christopherson [this message]
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=aPpN2U7lq8ZDdHx9@google.com \
--to=seanjc@google.com \
--cc=itaru.kitayama@linux.dev \
--cc=jmattson@google.com \
--cc=kvmarm@lists.linux.dev \
--cc=oliver.upton@linux.dev \
--cc=yosry.ahmed@linux.dev \
/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.