From: Sebastian Ott <sebott@redhat.com>
To: linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
linux-kernel@vger.kernel.org
Cc: Marc Zyngier <maz@kernel.org>,
Oliver Upton <oliver.upton@linux.dev>,
James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>
Subject: [PATCH v3 0/6] KVM: arm64: emulation for CTR_EL0
Date: Tue, 14 May 2024 09:22:46 +0200 [thread overview]
Message-ID: <20240514072252.5657-1-sebott@redhat.com> (raw)
Hej folks,
I'm looking into supporting migration between 2 Ampere Altra (Max)
machines (using Neoverse-N1). They are almost identical regarding
their feature id register state except for CTR_EL0.DIC which is set
on one machine but not the other.
CTR_EL0 is currently marked as invariant and migrating a VM between
those 2 machines using qemu fails.
Changes RFC [0] -> V1 [1]:
* store the emulated value per VM and not per VCPU
* allow to change more values than just the DIC bit
* only trap guest access to that reg when needed
* make sure to not present the guest with an inconsistent register set
Changes V1 -> V2 [2]:
* implemented Marc's suggestion for keeping registers consistent while
not breaking userspace ABI / expectations (I hope correctly this time)
* keep the shadowed value valid at all time
* unify the code to setup traps
Changes V2 -> V3:
* rebased to kvm-arm-next (to include Olivers idreg fixes)
* fixed VM ops trapping for non-FWB CPUs
* fixed writable mask for CLIDR_EL1
* re-added manual ctr validation (using arm64_check_features() had a
side effect with the way .reset is working for these registers)
* added a testcase
Thanks,
Sebastian
[0]: https://lore.kernel.org/all/20240318111636.10613-1-sebott@redhat.com/T/
[1]: https://lore.kernel.org/lkml/20240405120108.11844-1-sebott@redhat.com/T/
[2]: https://lore.kernel.org/lkml/20240426104950.7382-1-sebott@redhat.com/T/
Sebastian Ott (6):
KVM: arm64: unify code to prepare traps
KVM: arm64: maintain per VM value for CTR_EL0
KVM: arm64: add emulation for CTR_EL0 register
KVM: arm64: show writable masks for feature registers
KVM: arm64: rename functions for invariant sys regs
KVM: selftests: arm64: Test writes to CTR_EL0
arch/arm64/include/asm/kvm_emulate.h | 40 +---
arch/arm64/include/asm/kvm_host.h | 4 +-
arch/arm64/kvm/arm.c | 2 +-
arch/arm64/kvm/sys_regs.c | 210 ++++++++++++++----
.../selftests/kvm/aarch64/set_id_regs.c | 16 ++
5 files changed, 197 insertions(+), 75 deletions(-)
--
2.42.0
WARNING: multiple messages have this Message-ID (diff)
From: Sebastian Ott <sebott@redhat.com>
To: linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
linux-kernel@vger.kernel.org
Cc: Marc Zyngier <maz@kernel.org>,
Oliver Upton <oliver.upton@linux.dev>,
James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>
Subject: [PATCH v3 0/6] KVM: arm64: emulation for CTR_EL0
Date: Tue, 14 May 2024 09:22:46 +0200 [thread overview]
Message-ID: <20240514072252.5657-1-sebott@redhat.com> (raw)
Hej folks,
I'm looking into supporting migration between 2 Ampere Altra (Max)
machines (using Neoverse-N1). They are almost identical regarding
their feature id register state except for CTR_EL0.DIC which is set
on one machine but not the other.
CTR_EL0 is currently marked as invariant and migrating a VM between
those 2 machines using qemu fails.
Changes RFC [0] -> V1 [1]:
* store the emulated value per VM and not per VCPU
* allow to change more values than just the DIC bit
* only trap guest access to that reg when needed
* make sure to not present the guest with an inconsistent register set
Changes V1 -> V2 [2]:
* implemented Marc's suggestion for keeping registers consistent while
not breaking userspace ABI / expectations (I hope correctly this time)
* keep the shadowed value valid at all time
* unify the code to setup traps
Changes V2 -> V3:
* rebased to kvm-arm-next (to include Olivers idreg fixes)
* fixed VM ops trapping for non-FWB CPUs
* fixed writable mask for CLIDR_EL1
* re-added manual ctr validation (using arm64_check_features() had a
side effect with the way .reset is working for these registers)
* added a testcase
Thanks,
Sebastian
[0]: https://lore.kernel.org/all/20240318111636.10613-1-sebott@redhat.com/T/
[1]: https://lore.kernel.org/lkml/20240405120108.11844-1-sebott@redhat.com/T/
[2]: https://lore.kernel.org/lkml/20240426104950.7382-1-sebott@redhat.com/T/
Sebastian Ott (6):
KVM: arm64: unify code to prepare traps
KVM: arm64: maintain per VM value for CTR_EL0
KVM: arm64: add emulation for CTR_EL0 register
KVM: arm64: show writable masks for feature registers
KVM: arm64: rename functions for invariant sys regs
KVM: selftests: arm64: Test writes to CTR_EL0
arch/arm64/include/asm/kvm_emulate.h | 40 +---
arch/arm64/include/asm/kvm_host.h | 4 +-
arch/arm64/kvm/arm.c | 2 +-
arch/arm64/kvm/sys_regs.c | 210 ++++++++++++++----
.../selftests/kvm/aarch64/set_id_regs.c | 16 ++
5 files changed, 197 insertions(+), 75 deletions(-)
--
2.42.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next reply other threads:[~2024-05-14 7:23 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-14 7:22 Sebastian Ott [this message]
2024-05-14 7:22 ` [PATCH v3 0/6] KVM: arm64: emulation for CTR_EL0 Sebastian Ott
2024-05-14 7:22 ` [PATCH v3 1/6] KVM: arm64: unify code to prepare traps Sebastian Ott
2024-05-14 7:22 ` Sebastian Ott
2024-05-27 8:01 ` Shaoqin Huang
2024-05-27 8:01 ` Shaoqin Huang
2024-05-27 14:23 ` Sebastian Ott
2024-05-27 14:23 ` Sebastian Ott
2024-05-30 16:54 ` Eric Auger
2024-05-30 16:54 ` Eric Auger
2024-05-14 7:22 ` [PATCH v3 2/6] KVM: arm64: maintain per VM value for CTR_EL0 Sebastian Ott
2024-05-14 7:22 ` Sebastian Ott
2024-05-27 8:37 ` Shaoqin Huang
2024-05-27 8:37 ` Shaoqin Huang
2024-05-29 10:37 ` Eric Auger
2024-05-29 10:37 ` Eric Auger
2024-05-29 15:51 ` Sebastian Ott
2024-05-29 15:51 ` Sebastian Ott
2024-05-29 17:35 ` Eric Auger
2024-05-29 17:35 ` Eric Auger
2024-05-30 11:24 ` Sebastian Ott
2024-05-30 11:24 ` Sebastian Ott
2024-05-30 12:17 ` Eric Auger
2024-05-30 12:17 ` Eric Auger
2024-05-14 7:22 ` [PATCH v3 3/6] KVM: arm64: add emulation for CTR_EL0 register Sebastian Ott
2024-05-14 7:22 ` Sebastian Ott
2024-05-29 10:37 ` Eric Auger
2024-05-29 10:37 ` Eric Auger
2024-05-30 12:56 ` Sebastian Ott
2024-05-30 12:56 ` Sebastian Ott
2024-05-30 17:20 ` Eric Auger
2024-05-30 17:20 ` Eric Auger
2024-05-14 7:22 ` [PATCH v3 4/6] KVM: arm64: show writable masks for feature registers Sebastian Ott
2024-05-14 7:22 ` Sebastian Ott
2024-05-29 13:49 ` Eric Auger
2024-05-29 13:49 ` Eric Auger
2024-05-14 7:22 ` [PATCH v3 5/6] KVM: arm64: rename functions for invariant sys regs Sebastian Ott
2024-05-14 7:22 ` Sebastian Ott
2024-05-29 13:58 ` Eric Auger
2024-05-29 13:58 ` Eric Auger
2024-05-29 15:29 ` Sebastian Ott
2024-05-29 15:29 ` Sebastian Ott
2024-05-29 17:17 ` Eric Auger
2024-05-29 17:17 ` Eric Auger
2024-05-14 7:22 ` [PATCH v3 6/6] KVM: selftests: arm64: Test writes to CTR_EL0 Sebastian Ott
2024-05-14 7:22 ` Sebastian Ott
2024-05-29 17:07 ` Eric Auger
2024-05-29 17:07 ` Eric Auger
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=20240514072252.5657-1-sebott@redhat.com \
--to=sebott@redhat.com \
--cc=catalin.marinas@arm.com \
--cc=james.morse@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=suzuki.poulose@arm.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.