All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Ganapatrao Kulkarni <gankulkarni@os.amperecomputing.com>
Cc: Eric Auger <eauger@redhat.com>,
	Oliver Upton <oliver.upton@linux.dev>,
	kvmarm <kvmarm@lists.linux.dev>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, christoffer.dall@arm.com,
	suzuki.poulose@arm.com, will@kernel.org, catalin.marinas@arm.com,
	coltonlewis@google.com, joey.gouly@arm.com, yuzenghui@huawei.com,
	darren@os.amperecomputing.com, vishnu@os.amperecomputing.com
Subject: Re: [PATCH] KVM: arm64: nv: Set ISTATUS for emulated timers, If timer expired
Date: Tue, 18 Feb 2025 21:24:16 +0000	[thread overview]
Message-ID: <86cyffrlof.wl-maz@kernel.org> (raw)
In-Reply-To: <1a19dacc-72ca-4631-bce8-7426b3de0b47@os.amperecomputing.com>

On Tue, 18 Feb 2025 07:33:11 +0000,
Ganapatrao Kulkarni <gankulkarni@os.amperecomputing.com> wrote:
> 
> 
> Hi Marc,
> 
> On 15-02-2025 11:20 pm, Marc Zyngier wrote:
> > On Mon, 10 Feb 2025 18:26:48 +0000,
> > Eric Auger <eauger@redhat.com> wrote:
> >> 
> >> Hi Marc,
> >> 
> >> On 2/7/25 7:38 PM, Marc Zyngier wrote:
> >>> On Fri, 07 Feb 2025 18:09:58 +0000,
> >>> Oliver Upton <oliver.upton@linux.dev> wrote:
> >>>> 
> >>>> Hey,
> >>>> 
> >>>> On Fri, Feb 07, 2025 at 05:45:33PM +0000, Marc Zyngier wrote:
> >>>>> I found at least one issue that could fail the migration. Before the
> >>>>> VM starts running, we limit the feature set to the subset we actually
> >>>>> support with NV.
> >>>>> 
> >>>>> By doing this, we also change the value of IDreg fields that are not
> >>>>> writable, because they describe features that we don't support.
> >>>>> Obviously, that fails on restore.
> >>>>> 
> >>>>> I need to have a think...
> >>>> 
> >>>> We spoke about this a while ago (and I forgot til now), but I was
> >>>> wondering if we could use vCPU feature flags to describe NV, including
> >>>> the selection between FEAT_E2H0 and FEAT_VHE.
> >>>> 
> >>>> I think this might match userspace expectations a bit more closely where
> >>>> the state of the ID registers after init gives the actual feature set
> >>>> supported by the VM.
> >>> 
> >>> I'm not sure that's enough. Let me give you an example:
> >>> 
> >>> My host has FEAT_XNX, described in ID_AA64MMFR1_EL1.XNX. For whatever
> >>> reason, we don't allow this field to be written to, even out of NV
> >>> context. This is odd, because for an EL1 VM, this field means nothing
> >>> at all.
> >> So the curprit fields for me look like
> >> 
> >> - ID_AA64MMFR1_EL1.XNX
> >> - ID_AA64DFR0_EL1.DoubleLock
> >> - ID_AA64PFR0_EL1.RAS
> >> 
> >> This is still based on your nv-next branch from Jan 9
> >> https://github.com/eauger/linux/tree/nv_next_jan9_2025
> > 
> > I have now pushed out a new nv-next branch with the new and improved
> > UAPI. I expect migration to work a bit better, or at least not to
> > explode on ID register restore. You will notice that things have
> > changed a bit (extra flag and cap for FEAT_E2H0), but nothing really
> > major.
> > 
> 
> Tried nv-next branch and it is breaking(kernel Oops) for normal VM
> boot itself with qemu. Looks like this is happening since qemu is
> trying to write to ID_UNALLOCATED mapped registers as part of
> save-restore of registers.

My take on this problem ends up being more consolidation, and make
sure that the individual macros only override the default callbacks
for idregs.

Additionally, ID_UNALLOCATED gets a name matching the architectural
encoding.

	M.

diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index e6f4599dca48e..2e14562b5841f 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -2261,24 +2261,26 @@ static bool bad_redir_trap(struct kvm_vcpu *vcpu,
  * from userspace.
  */
 
-#define ID_DESC(name)				\
-	SYS_DESC(SYS_##name),			\
+#define ID_DESC_DEFAULT_CALLBACKS		\
 	.access	= access_id_reg,		\
 	.get_user = get_id_reg,			\
+	.set_user = set_id_reg,			\
+	.visibility = id_visibility,		\
 	.reset = kvm_read_sanitised_id_reg
 
+#define ID_DESC(name)				\
+	SYS_DESC(SYS_##name),			\
+	ID_DESC_DEFAULT_CALLBACKS
+
 /* sys_reg_desc initialiser for known cpufeature ID registers */
 #define ID_SANITISED(name) {			\
 	ID_DESC(name),				\
-	.set_user = set_id_reg,			\
-	.visibility = id_visibility,		\
 	.val = 0,				\
 }
 
 /* sys_reg_desc initialiser for known cpufeature ID registers */
 #define AA32_ID_SANITISED(name) {		\
 	ID_DESC(name),				\
-	.set_user = set_id_reg,			\
 	.visibility = aa32_id_visibility,	\
 	.val = 0,				\
 }
@@ -2286,8 +2288,6 @@ static bool bad_redir_trap(struct kvm_vcpu *vcpu,
 /* sys_reg_desc initialiser for writable ID registers */
 #define ID_WRITABLE(name, mask) {		\
 	ID_DESC(name),				\
-	.set_user = set_id_reg,			\
-	.visibility = id_visibility,		\
 	.val = mask,				\
 }
 
@@ -2295,7 +2295,6 @@ static bool bad_redir_trap(struct kvm_vcpu *vcpu,
 #define ID_FILTERED(sysreg, name, mask) {	\
 	ID_DESC(sysreg),				\
 	.set_user = set_##name,				\
-	.visibility = id_visibility,			\
 	.val = (mask),					\
 }
 
@@ -2305,10 +2304,9 @@ static bool bad_redir_trap(struct kvm_vcpu *vcpu,
  * (1 <= crm < 8, 0 <= Op2 < 8).
  */
 #define ID_UNALLOCATED(crm, op2) {			\
+	.name = "S3_0_0_" #crm "_" #op2,		\
 	Op0(3), Op1(0), CRn(0), CRm(crm), Op2(op2),	\
-	.access = access_id_reg,			\
-	.get_user = get_id_reg,				\
-	.set_user = set_id_reg,				\
+	ID_DESC_DEFAULT_CALLBACKS,			\
 	.visibility = raz_visibility,			\
 	.val = 0,					\
 }
@@ -2320,7 +2318,6 @@ static bool bad_redir_trap(struct kvm_vcpu *vcpu,
  */
 #define ID_HIDDEN(name) {			\
 	ID_DESC(name),				\
-	.set_user = set_id_reg,			\
 	.visibility = raz_visibility,		\
 	.val = 0,				\
 }

-- 
Without deviation from the norm, progress is not possible.

  parent reply	other threads:[~2025-02-18 21:24 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-09  5:32 [PATCH] KVM: arm64: nv: Set ISTATUS for emulated timers, If timer expired Ganapatrao Kulkarni
2024-12-09  9:54 ` Marc Zyngier
2024-12-09 12:25   ` Ganapatrao Kulkarni
2024-12-09 13:20     ` Marc Zyngier
2024-12-09 15:23       ` Marc Zyngier
2024-12-09 15:39       ` Ganapatrao Kulkarni
2024-12-09 15:52         ` Marc Zyngier
2024-12-09 16:46         ` Eric Auger
2024-12-09 17:30           ` Marc Zyngier
2024-12-09 17:34             ` Eric Auger
2024-12-19  9:30               ` Ganapatrao Kulkarni
2024-12-19 12:23                 ` Marc Zyngier
2025-01-14 13:12                 ` Eric Auger
2025-01-14 14:38                   ` Marc Zyngier
2025-01-14 14:57                     ` Eric Auger
2025-01-14 15:52                       ` Marc Zyngier
2025-01-16 17:52                         ` Eric Auger
2025-01-16 18:25                           ` Marc Zyngier
2025-02-07 17:45                           ` Marc Zyngier
2025-02-07 18:09                             ` Oliver Upton
2025-02-07 18:38                               ` Marc Zyngier
2025-02-07 19:08                                 ` Oliver Upton
2025-02-10 18:26                                 ` Eric Auger
2025-02-11 19:20                                   ` Marc Zyngier
2025-02-15 17:50                                   ` Marc Zyngier
2025-02-18  7:33                                     ` Ganapatrao Kulkarni
2025-02-18 16:33                                       ` Marc Zyngier
2025-02-18 21:24                                       ` Marc Zyngier [this message]
2025-02-20  6:10                                         ` Ganapatrao Kulkarni
2025-02-10 13:18                             ` Eric Auger
2024-12-10 12:48       ` Ganapatrao Kulkarni
2024-12-09 19:36 ` kernel test robot

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=86cyffrlof.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=christoffer.dall@arm.com \
    --cc=coltonlewis@google.com \
    --cc=darren@os.amperecomputing.com \
    --cc=eauger@redhat.com \
    --cc=gankulkarni@os.amperecomputing.com \
    --cc=joey.gouly@arm.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oliver.upton@linux.dev \
    --cc=suzuki.poulose@arm.com \
    --cc=vishnu@os.amperecomputing.com \
    --cc=will@kernel.org \
    --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.