Linux KVM/arm64 development list
 help / color / mirror / Atom feed
From: Oliver Upton <oliver.upton@linux.dev>
To: Itaru Kitayama <itaru.kitayama@linux.dev>
Cc: kvmarm@lists.linux.dev
Subject: Re: RFC KVM: arm64: selftest: stage 2 mapping helpers
Date: Wed, 22 Oct 2025 02:05:21 -0700	[thread overview]
Message-ID: <aPieUS7BTQB_dUFs@linux.dev> (raw)
In-Reply-To: <aPhq1tKKQCxhae43@vm4>

On Wed, Oct 22, 2025 at 02:25:42PM +0900, Itaru Kitayama wrote:
> Hi Oliver,
> Thanks for your review. Below is the updated helper patch and a test program
> which does ERET in L1 guest (in guest_code). However, upon execution I keep 
> getting IABTs from lower EL.

I don't have the time to help debugging this, you'll need to spend some
time on this if you can.

> int main(void)
> {
> 	struct kvm_vm *vm;
> 	struct kvm_vcpu *vcpu;
> 	struct kvm_vcpu_init init = {};
> 
> 	/* Check we're on a NV2 hardware */
> 	if (!kvm_check_cap(KVM_CAP_ARM_EL2))
> 		exit(KSFT_SKIP);
> 
> 	vm = vm_create(1);
> 
> 	kvm_get_default_vcpu_target(vm, &init);
>         init.features[0] |= BIT(KVM_ARM_VCPU_HAS_EL2);
>         vcpu = aarch64_vcpu_add(vm, 0, &init, guest_code);

Keep in mind that aarch64_vcpu_add() will wind up initializing the EL2
CPU context when HAS_EL2 is set. To get a functional EL1 you'll need to
initialize the EL1 CPU context, including the MMU and allocating a
separate stack.

You can probably get away with reusing the EL2&0 page tables at EL1 so
long as the stage-2 translation is an identity mapping.

Thanks,
Oliver

  reply	other threads:[~2025-10-22  9:05 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 [this message]
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

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=aPieUS7BTQB_dUFs@linux.dev \
    --to=oliver.upton@linux.dev \
    --cc=itaru.kitayama@linux.dev \
    --cc=kvmarm@lists.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox