[PATCH v2 0/2] Fixes for movable pages

[PATCH v2 0/2] Fixes for movable pages

[Anirudh Rayabharam]

From: "Anirudh Rayabharam (Microsoft)" <anirudh@anirudhrb.com>

Fix movable pages for arm64 guests by implementing a GPA intercept
handler.

v2:
  - Added "Fixes:" tag
  - Got rid of the utility function to get intercept GPA and instead
    integrated the rather small logic into the GPA intercept handling
    function.
  - Dropped patch 3 since it was applied to the fixes tree.

Anirudh Rayabharam (Microsoft) (2):
  hyperv: add definitions for arm64 gpa intercepts
  mshv: handle gpa intercepts for arm64

 drivers/hv/mshv_root_main.c | 15 ++++++------
 include/hyperv/hvhdk.h      | 47 +++++++++++++++++++++++++++++++++++++
 2 files changed, 55 insertions(+), 7 deletions(-)

-- 
2.34.1

[PATCH v2 1/2] hyperv: add definitions for arm64 gpa intercepts

[Anirudh Rayabharam]

From: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>

Add definitions required for handling GPA intercepts on arm64.

Signed-off-by: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>
---
 include/hyperv/hvhdk.h | 47 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 47 insertions(+)

diff --git a/include/hyperv/hvhdk.h b/include/hyperv/hvhdk.h
index 469186df7826..08965970c17d 100644
--- a/include/hyperv/hvhdk.h
+++ b/include/hyperv/hvhdk.h
@@ -800,6 +800,53 @@ struct hv_x64_memory_intercept_message {
 	u8 instruction_bytes[16];
 } __packed;
 
+#if IS_ENABLED(CONFIG_ARM64)
+union hv_arm64_vp_execution_state {
+	u16 as_uint16;
+	struct {
+		u16 cpl:2; /* Exception Level (EL) */
+		u16 debug_active:1;
+		u16 interruption_pending:1;
+		u16 vtl:4;
+		u16 virtualization_fault_active:1;
+		u16 reserved:7;
+	} __packed;
+};
+
+struct hv_arm64_intercept_message_header {
+	u32 vp_index;
+	u8 instruction_length;
+	u8 intercept_access_type;
+	union hv_arm64_vp_execution_state execution_state;
+	u64 pc;
+	u64 cpsr;
+} __packed;
+
+union hv_arm64_memory_access_info {
+	u8 as_uint8;
+	struct {
+		u8 gva_valid:1;
+		u8 gva_gpa_valid:1;
+		u8 hypercall_output_pending:1;
+		u8 reserved:5;
+	} __packed;
+};
+
+struct hv_arm64_memory_intercept_message {
+	struct hv_arm64_intercept_message_header header;
+	u32 cache_type; /* enum hv_cache_type */
+	u8 instruction_byte_count;
+	union hv_arm64_memory_access_info memory_access_info;
+	u16 reserved1;
+	u8 instruction_bytes[4];
+	u32 reserved2;
+	u64 guest_virtual_address;
+	u64 guest_physical_address;
+	u64 syndrome;
+} __packed;
+
+#endif /* CONFIG_ARM64 */
+
 /*
  * Dispatch state for the VP communicated by the hypervisor to the
  * VP-dispatching thread in the root on return from HVCALL_DISPATCH_VP.
-- 
2.34.1

Re: [PATCH v2 1/2] hyperv: add definitions for arm64 gpa intercepts

[vdso]

> On 01/05/2026 4:28 AM  Anirudh Rayabharam <anirudh@anirudhrb.com> wrote:
> 

[...]

>  
> +#if IS_ENABLED(CONFIG_ARM64)
> +union hv_arm64_vp_execution_state {
> +	u16 as_uint16;
> +	struct {
> +		u16 cpl:2; /* Exception Level (EL) */

Anirudh,

Appreciate following up on the CPL field in that ARM64 structure
and adding the comment!

Still, using something from the x86 parlance (CPL) and adding a comment
stating that this is actually ARM64 EL certainly needs an explanation
as to _why_ using an x86 term here is beneficial, why not just call
the field "el"? As an analogy, here is a thought experiment of writing

#ffdef CONFIG_ARM64
u64 rax; /* This is X0 */
#endif

where an x86 register name would be used to refer to X0 on ARM64, and
that doen't look natural.

So far, I can't seem to find drawbacks in naming this field "el", only
benefits:
* ARM64 folks will immediately know what this field is, and
* the comment isn't required to explain the situation to the reader.

Do you foresee any drawbacks of calling the field "el" and dropping
the comment? If you do, would these drawbacks outweigh the benefits?

[...]

--
Cheers,
Roman

Re: [PATCH v2 1/2] hyperv: add definitions for arm64 gpa intercepts

[Anirudh Rayabharam]

On Mon, Jan 05, 2026 at 08:06:02AM -0800, vdso@mailbox.org wrote:
> 
> > On 01/05/2026 4:28 AM  Anirudh Rayabharam <anirudh@anirudhrb.com> wrote:
> > 
> 
> [...]
> 
> >  
> > +#if IS_ENABLED(CONFIG_ARM64)
> > +union hv_arm64_vp_execution_state {
> > +	u16 as_uint16;
> > +	struct {
> > +		u16 cpl:2; /* Exception Level (EL) */
> 
> Anirudh,
> 
> Appreciate following up on the CPL field in that ARM64 structure
> and adding the comment!

My bad, actually I was gonna explain this in a reply to the previous
thread but it slipped my mind.

> 
> Still, using something from the x86 parlance (CPL) and adding a comment
> stating that this is actually ARM64 EL certainly needs an explanation
> as to _why_ using an x86 term here is beneficial, why not just call
> the field "el"? As an analogy, here is a thought experiment of writing
> 
> #ffdef CONFIG_ARM64
> u64 rax; /* This is X0 */
> #endif
> 
> where an x86 register name would be used to refer to X0 on ARM64, and
> that doen't look natural.

Well, in this case neither CPL nor EL is an architecturally defined
register name. These are just architectural concepts.

> 
> So far, I can't seem to find drawbacks in naming this field "el", only
> benefits:
> * ARM64 folks will immediately know what this field is, and
> * the comment isn't required to explain the situation to the reader.
> 
> Do you foresee any drawbacks of calling the field "el" and dropping
> the comment? If you do, would these drawbacks outweigh the benefits?

As a general rule we want to keep these headers exactly same as the
hypervisor headers so that we can directly ingest them at some point in
the future.

I am not seeing a substantial benefit in breaking that rule. The CPL ->
EL analogy is not a huge leap to make IMO and the comment helps. One
could think of "current privilege level" as a generic term here.

Thanks,
Anirudh.

> 
> [...]
> 
> --
> Cheers,
> Roman

Re: [PATCH v2 1/2] hyperv: add definitions for arm64 gpa intercepts

[mrathor]

On 1/5/26 11:27, Anirudh Rayabharam wrote:
> On Mon, Jan 05, 2026 at 08:06:02AM -0800, vdso@mailbox.org wrote:
>>
>>> On 01/05/2026 4:28 AM  Anirudh Rayabharam <anirudh@anirudhrb.com> wrote:
>>>
>>
>> [...]
>>
>>>   
>>> +#if IS_ENABLED(CONFIG_ARM64)
>>> +union hv_arm64_vp_execution_state {
>>> +	u16 as_uint16;
>>> +	struct {
>>> +		u16 cpl:2; /* Exception Level (EL) */
>>
>> Anirudh,
>>
>> Appreciate following up on the CPL field in that ARM64 structure
>> and adding the comment!
> 
> My bad, actually I was gonna explain this in a reply to the previous
> thread but it slipped my mind.
> 
>>
>> Still, using something from the x86 parlance (CPL) and adding a comment
>> stating that this is actually ARM64 EL certainly needs an explanation
>> as to _why_ using an x86 term here is beneficial, why not just call
>> the field "el"? As an analogy, here is a thought experiment of writing
>>
>> #ffdef CONFIG_ARM64
>> u64 rax; /* This is X0 */
>> #endif
>>
>> where an x86 register name would be used to refer to X0 on ARM64, and
>> that doen't look natural.
> 
> Well, in this case neither CPL nor EL is an architecturally defined
> register name. These are just architectural concepts.
> 
>>
>> So far, I can't seem to find drawbacks in naming this field "el", only
>> benefits:
>> * ARM64 folks will immediately know what this field is, and
>> * the comment isn't required to explain the situation to the reader.
>>
>> Do you foresee any drawbacks of calling the field "el" and dropping
>> the comment? If you do, would these drawbacks outweigh the benefits?
> 
> As a general rule we want to keep these headers exactly same as the
> hypervisor headers so that we can directly ingest them at some point in
> the future.

Having said that, we've communicated the concern to the hyp team, and
there is no opposition to changing it. After the change is made on
that side, it will propagate to this side in future.

Thanks for your diligence.

-Mukesh



> I am not seeing a substantial benefit in breaking that rule. The CPL ->
> EL analogy is not a huge leap to make IMO and the comment helps. One
> could think of "current privilege level" as a generic term here.
> 
> Thanks,
> Anirudh.
> 
>>
>> [...]
>>
>> --
>> Cheers,
>> Roman

Re: [PATCH v2 1/2] hyperv: add definitions for arm64 gpa intercepts

[Stanislav Kinsburskii]

On Mon, Jan 05, 2026 at 12:28:36PM +0000, Anirudh Rayabharam wrote:
> From: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>
> 
> Add definitions required for handling GPA intercepts on arm64.
> 
> Signed-off-by: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>

Reviewed-by: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>

> ---
>  include/hyperv/hvhdk.h | 47 ++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 47 insertions(+)
> 
> diff --git a/include/hyperv/hvhdk.h b/include/hyperv/hvhdk.h
> index 469186df7826..08965970c17d 100644
> --- a/include/hyperv/hvhdk.h
> +++ b/include/hyperv/hvhdk.h
> @@ -800,6 +800,53 @@ struct hv_x64_memory_intercept_message {
>  	u8 instruction_bytes[16];
>  } __packed;
>  
> +#if IS_ENABLED(CONFIG_ARM64)
> +union hv_arm64_vp_execution_state {
> +	u16 as_uint16;
> +	struct {
> +		u16 cpl:2; /* Exception Level (EL) */
> +		u16 debug_active:1;
> +		u16 interruption_pending:1;
> +		u16 vtl:4;
> +		u16 virtualization_fault_active:1;
> +		u16 reserved:7;
> +	} __packed;
> +};
> +
> +struct hv_arm64_intercept_message_header {
> +	u32 vp_index;
> +	u8 instruction_length;
> +	u8 intercept_access_type;
> +	union hv_arm64_vp_execution_state execution_state;
> +	u64 pc;
> +	u64 cpsr;
> +} __packed;
> +
> +union hv_arm64_memory_access_info {
> +	u8 as_uint8;
> +	struct {
> +		u8 gva_valid:1;
> +		u8 gva_gpa_valid:1;
> +		u8 hypercall_output_pending:1;
> +		u8 reserved:5;
> +	} __packed;
> +};
> +
> +struct hv_arm64_memory_intercept_message {
> +	struct hv_arm64_intercept_message_header header;
> +	u32 cache_type; /* enum hv_cache_type */
> +	u8 instruction_byte_count;
> +	union hv_arm64_memory_access_info memory_access_info;
> +	u16 reserved1;
> +	u8 instruction_bytes[4];
> +	u32 reserved2;
> +	u64 guest_virtual_address;
> +	u64 guest_physical_address;
> +	u64 syndrome;
> +} __packed;
> +
> +#endif /* CONFIG_ARM64 */
> +
>  /*
>   * Dispatch state for the VP communicated by the hypervisor to the
>   * VP-dispatching thread in the root on return from HVCALL_DISPATCH_VP.
> -- 
> 2.34.1
> 

[PATCH v2 2/2] mshv: handle gpa intercepts for arm64

[Anirudh Rayabharam]

From: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>

The mshv driver now uses movable pages for guests. For arm64 guests
to be functional, handle gpa intercepts for arm64 too (the current
code implements handling only for x86).

Move some arch-agnostic functions out of #ifdefs so that they can be
re-used.

Fixes: b9a66cd5ccbb ("mshv: Add support for movable memory regions")
Signed-off-by: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>
---
 drivers/hv/mshv_root_main.c | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/hv/mshv_root_main.c b/drivers/hv/mshv_root_main.c
index 9cf28a3f12fe..f8c4c2ae2cc9 100644
--- a/drivers/hv/mshv_root_main.c
+++ b/drivers/hv/mshv_root_main.c
@@ -608,7 +608,6 @@ mshv_partition_region_by_gfn(struct mshv_partition *partition, u64 gfn)
 	return NULL;
 }
 
-#ifdef CONFIG_X86_64
 static struct mshv_mem_region *
 mshv_partition_region_by_gfn_get(struct mshv_partition *p, u64 gfn)
 {
@@ -640,12 +639,17 @@ static bool mshv_handle_gpa_intercept(struct mshv_vp *vp)
 {
 	struct mshv_partition *p = vp->vp_partition;
 	struct mshv_mem_region *region;
-	struct hv_x64_memory_intercept_message *msg;
 	bool ret;
 	u64 gfn;
-
-	msg = (struct hv_x64_memory_intercept_message *)
+#if defined(CONFIG_X86_64)
+	struct hv_x64_memory_intercept_message *msg =
+		(struct hv_x64_memory_intercept_message *)
+		vp->vp_intercept_msg_page->u.payload;
+#elif defined(CONFIG_ARM64)
+	struct hv_arm64_memory_intercept_message *msg =
+		(struct hv_arm64_memory_intercept_message *)
 		vp->vp_intercept_msg_page->u.payload;
+#endif
 
 	gfn = HVPFN_DOWN(msg->guest_physical_address);
 
@@ -663,9 +667,6 @@ static bool mshv_handle_gpa_intercept(struct mshv_vp *vp)
 
 	return ret;
 }
-#else  /* CONFIG_X86_64 */
-static bool mshv_handle_gpa_intercept(struct mshv_vp *vp) { return false; }
-#endif /* CONFIG_X86_64 */
 
 static bool mshv_vp_handle_intercept(struct mshv_vp *vp)
 {
-- 
2.34.1

Re: [PATCH v2 2/2] mshv: handle gpa intercepts for arm64

[Stanislav Kinsburskii]

On Mon, Jan 05, 2026 at 12:28:37PM +0000, Anirudh Rayabharam wrote:
> From: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>
> 
> The mshv driver now uses movable pages for guests. For arm64 guests
> to be functional, handle gpa intercepts for arm64 too (the current
> code implements handling only for x86).
> 
> Move some arch-agnostic functions out of #ifdefs so that they can be
> re-used.
> 
> Fixes: b9a66cd5ccbb ("mshv: Add support for movable memory regions")

I'm not sure that this patch needs "Fixes" tag as it introduced new
functionality rather than fixing a bug.

Thanks,
Stanislav

> Signed-off-by: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>
> ---
>  drivers/hv/mshv_root_main.c | 15 ++++++++-------
>  1 file changed, 8 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/hv/mshv_root_main.c b/drivers/hv/mshv_root_main.c
> index 9cf28a3f12fe..f8c4c2ae2cc9 100644
> --- a/drivers/hv/mshv_root_main.c
> +++ b/drivers/hv/mshv_root_main.c
> @@ -608,7 +608,6 @@ mshv_partition_region_by_gfn(struct mshv_partition *partition, u64 gfn)
>  	return NULL;
>  }
>  
> -#ifdef CONFIG_X86_64
>  static struct mshv_mem_region *
>  mshv_partition_region_by_gfn_get(struct mshv_partition *p, u64 gfn)
>  {
> @@ -640,12 +639,17 @@ static bool mshv_handle_gpa_intercept(struct mshv_vp *vp)
>  {
>  	struct mshv_partition *p = vp->vp_partition;
>  	struct mshv_mem_region *region;
> -	struct hv_x64_memory_intercept_message *msg;
>  	bool ret;
>  	u64 gfn;
> -
> -	msg = (struct hv_x64_memory_intercept_message *)
> +#if defined(CONFIG_X86_64)
> +	struct hv_x64_memory_intercept_message *msg =
> +		(struct hv_x64_memory_intercept_message *)
> +		vp->vp_intercept_msg_page->u.payload;
> +#elif defined(CONFIG_ARM64)
> +	struct hv_arm64_memory_intercept_message *msg =
> +		(struct hv_arm64_memory_intercept_message *)
>  		vp->vp_intercept_msg_page->u.payload;
> +#endif
>  
>  	gfn = HVPFN_DOWN(msg->guest_physical_address);
>  
> @@ -663,9 +667,6 @@ static bool mshv_handle_gpa_intercept(struct mshv_vp *vp)
>  
>  	return ret;
>  }
> -#else  /* CONFIG_X86_64 */
> -static bool mshv_handle_gpa_intercept(struct mshv_vp *vp) { return false; }
> -#endif /* CONFIG_X86_64 */
>  
>  static bool mshv_vp_handle_intercept(struct mshv_vp *vp)
>  {
> -- 
> 2.34.1
> 

Re: [PATCH v2 2/2] mshv: handle gpa intercepts for arm64

[Anirudh Rayabharam]

On Mon, Jan 05, 2026 at 09:04:02AM -0800, Stanislav Kinsburskii wrote:
> On Mon, Jan 05, 2026 at 12:28:37PM +0000, Anirudh Rayabharam wrote:
> > From: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>
> > 
> > The mshv driver now uses movable pages for guests. For arm64 guests
> > to be functional, handle gpa intercepts for arm64 too (the current
> > code implements handling only for x86).
> > 
> > Move some arch-agnostic functions out of #ifdefs so that they can be
> > re-used.
> > 
> > Fixes: b9a66cd5ccbb ("mshv: Add support for movable memory regions")
> 
> I'm not sure that this patch needs "Fixes" tag as it introduced new
> functionality rather than fixing a bug.

This does fix a bug. The commit mentioned here regressed arm64 guests because
it didn't have GPA intercept handling for arm64.

Thanks,
Anirudh.

> 
> Thanks,
> Stanislav
> 
> > Signed-off-by: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>
> > ---
> >  drivers/hv/mshv_root_main.c | 15 ++++++++-------
> >  1 file changed, 8 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/hv/mshv_root_main.c b/drivers/hv/mshv_root_main.c
> > index 9cf28a3f12fe..f8c4c2ae2cc9 100644
> > --- a/drivers/hv/mshv_root_main.c
> > +++ b/drivers/hv/mshv_root_main.c
> > @@ -608,7 +608,6 @@ mshv_partition_region_by_gfn(struct mshv_partition *partition, u64 gfn)
> >  	return NULL;
> >  }
> >  
> > -#ifdef CONFIG_X86_64
> >  static struct mshv_mem_region *
> >  mshv_partition_region_by_gfn_get(struct mshv_partition *p, u64 gfn)
> >  {
> > @@ -640,12 +639,17 @@ static bool mshv_handle_gpa_intercept(struct mshv_vp *vp)
> >  {
> >  	struct mshv_partition *p = vp->vp_partition;
> >  	struct mshv_mem_region *region;
> > -	struct hv_x64_memory_intercept_message *msg;
> >  	bool ret;
> >  	u64 gfn;
> > -
> > -	msg = (struct hv_x64_memory_intercept_message *)
> > +#if defined(CONFIG_X86_64)
> > +	struct hv_x64_memory_intercept_message *msg =
> > +		(struct hv_x64_memory_intercept_message *)
> > +		vp->vp_intercept_msg_page->u.payload;
> > +#elif defined(CONFIG_ARM64)
> > +	struct hv_arm64_memory_intercept_message *msg =
> > +		(struct hv_arm64_memory_intercept_message *)
> >  		vp->vp_intercept_msg_page->u.payload;
> > +#endif
> >  
> >  	gfn = HVPFN_DOWN(msg->guest_physical_address);
> >  
> > @@ -663,9 +667,6 @@ static bool mshv_handle_gpa_intercept(struct mshv_vp *vp)
> >  
> >  	return ret;
> >  }
> > -#else  /* CONFIG_X86_64 */
> > -static bool mshv_handle_gpa_intercept(struct mshv_vp *vp) { return false; }
> > -#endif /* CONFIG_X86_64 */
> >  
> >  static bool mshv_vp_handle_intercept(struct mshv_vp *vp)
> >  {
> > -- 
> > 2.34.1
> > 

Re: [PATCH v2 2/2] mshv: handle gpa intercepts for arm64

[Stanislav Kinsburskii]

On Tue, Jan 06, 2026 at 07:21:41AM +0000, Anirudh Rayabharam wrote:
> On Mon, Jan 05, 2026 at 09:04:02AM -0800, Stanislav Kinsburskii wrote:
> > On Mon, Jan 05, 2026 at 12:28:37PM +0000, Anirudh Rayabharam wrote:
> > > From: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>
> > > 
> > > The mshv driver now uses movable pages for guests. For arm64 guests
> > > to be functional, handle gpa intercepts for arm64 too (the current
> > > code implements handling only for x86).
> > > 
> > > Move some arch-agnostic functions out of #ifdefs so that they can be
> > > re-used.
> > > 
> > > Fixes: b9a66cd5ccbb ("mshv: Add support for movable memory regions")
> > 
> > I'm not sure that this patch needs "Fixes" tag as it introduced new
> > functionality rather than fixing a bug.
> 
> This does fix a bug. The commit mentioned here regressed arm64 guests because
> it didn't have GPA intercept handling for arm64.
> 

Were ARM guests functional before this commit? If yes, then I agree that
this patch fixes a bug. If no, then this is just adding new
functionality.
I had an impression ARM is not yet supported in MSHV, so please clarify.

Thanks,
Stanislav

> Thanks,
> Anirudh.
> 
> > 
> > Thanks,
> > Stanislav
> > 
> > > Signed-off-by: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>
> > > ---
> > >  drivers/hv/mshv_root_main.c | 15 ++++++++-------
> > >  1 file changed, 8 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/drivers/hv/mshv_root_main.c b/drivers/hv/mshv_root_main.c
> > > index 9cf28a3f12fe..f8c4c2ae2cc9 100644
> > > --- a/drivers/hv/mshv_root_main.c
> > > +++ b/drivers/hv/mshv_root_main.c
> > > @@ -608,7 +608,6 @@ mshv_partition_region_by_gfn(struct mshv_partition *partition, u64 gfn)
> > >  	return NULL;
> > >  }
> > >  
> > > -#ifdef CONFIG_X86_64
> > >  static struct mshv_mem_region *
> > >  mshv_partition_region_by_gfn_get(struct mshv_partition *p, u64 gfn)
> > >  {
> > > @@ -640,12 +639,17 @@ static bool mshv_handle_gpa_intercept(struct mshv_vp *vp)
> > >  {
> > >  	struct mshv_partition *p = vp->vp_partition;
> > >  	struct mshv_mem_region *region;
> > > -	struct hv_x64_memory_intercept_message *msg;
> > >  	bool ret;
> > >  	u64 gfn;
> > > -
> > > -	msg = (struct hv_x64_memory_intercept_message *)
> > > +#if defined(CONFIG_X86_64)
> > > +	struct hv_x64_memory_intercept_message *msg =
> > > +		(struct hv_x64_memory_intercept_message *)
> > > +		vp->vp_intercept_msg_page->u.payload;
> > > +#elif defined(CONFIG_ARM64)
> > > +	struct hv_arm64_memory_intercept_message *msg =
> > > +		(struct hv_arm64_memory_intercept_message *)
> > >  		vp->vp_intercept_msg_page->u.payload;
> > > +#endif
> > >  
> > >  	gfn = HVPFN_DOWN(msg->guest_physical_address);
> > >  
> > > @@ -663,9 +667,6 @@ static bool mshv_handle_gpa_intercept(struct mshv_vp *vp)
> > >  
> > >  	return ret;
> > >  }
> > > -#else  /* CONFIG_X86_64 */
> > > -static bool mshv_handle_gpa_intercept(struct mshv_vp *vp) { return false; }
> > > -#endif /* CONFIG_X86_64 */
> > >  
> > >  static bool mshv_vp_handle_intercept(struct mshv_vp *vp)
> > >  {
> > > -- 
> > > 2.34.1
> > > 

Re: [PATCH v2 2/2] mshv: handle gpa intercepts for arm64

[Nuno Das Neves]

On 1/6/2026 8:36 AM, Stanislav Kinsburskii wrote:
> On Tue, Jan 06, 2026 at 07:21:41AM +0000, Anirudh Rayabharam wrote:
>> On Mon, Jan 05, 2026 at 09:04:02AM -0800, Stanislav Kinsburskii wrote:
>>> On Mon, Jan 05, 2026 at 12:28:37PM +0000, Anirudh Rayabharam wrote:
>>>> From: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>
>>>>
>>>> The mshv driver now uses movable pages for guests. For arm64 guests
>>>> to be functional, handle gpa intercepts for arm64 too (the current
>>>> code implements handling only for x86).
>>>>
>>>> Move some arch-agnostic functions out of #ifdefs so that they can be
>>>> re-used.
>>>>
>>>> Fixes: b9a66cd5ccbb ("mshv: Add support for movable memory regions")
>>>
>>> I'm not sure that this patch needs "Fixes" tag as it introduced new
>>> functionality rather than fixing a bug.
>>
>> This does fix a bug. The commit mentioned here regressed arm64 guests because
>> it didn't have GPA intercept handling for arm64.
>>
> 
> Were ARM guests functional before this commit? If yes, then I agree that
> this patch fixes a bug. If no, then this is just adding new
> functionality.
> I had an impression ARM is not yet supported in MSHV, so please clarify.
> 

Chiming in, I had a similar discussion with Michael regarding correcting
the value of VpRootDispatchThreadBlocked for ARM64:
https://lore.kernel.org/linux-hyperv/SN6PR02MB41574240F18B87346C659DBFD4BBA@SN6PR02MB4157.namprd02.prod.outlook.com/T/#u

Michael didn't see need for a separate patch for that fix (with "Fixes"
tag, I assumed, though we didn't discuss it). This is because the code
is currently not doing anything due to ARM64 not yet being supported.

Keep in mind adding a "Fixes" tag marks the patch for backporting to LTS
kernels (if the original patch is in one of those, of course). There is
no need for such backporting as it has no impact for features that do not
yet exist. This 'fix' is really a precursor for ARM64 support, and we don't
have a special way of tagging those.

I can see that "Fixes" may help someone who is backporting entire features
to help them identify dependencies (e.g. backporting ARM64 support), but
the benefit of that is conjectural so I don't see it as a strong enough
reason given the above.

Nuno

> Thanks,
> Stanislav
> 
>> Thanks,
>> Anirudh.
>>
>>>
>>> Thanks,
>>> Stanislav
>>>
>>>> Signed-off-by: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>
>>>> ---
>>>>  drivers/hv/mshv_root_main.c | 15 ++++++++-------
>>>>  1 file changed, 8 insertions(+), 7 deletions(-)
>>>>
>>>> diff --git a/drivers/hv/mshv_root_main.c b/drivers/hv/mshv_root_main.c
>>>> index 9cf28a3f12fe..f8c4c2ae2cc9 100644
>>>> --- a/drivers/hv/mshv_root_main.c
>>>> +++ b/drivers/hv/mshv_root_main.c
>>>> @@ -608,7 +608,6 @@ mshv_partition_region_by_gfn(struct mshv_partition *partition, u64 gfn)
>>>>  	return NULL;
>>>>  }
>>>>  
>>>> -#ifdef CONFIG_X86_64
>>>>  static struct mshv_mem_region *
>>>>  mshv_partition_region_by_gfn_get(struct mshv_partition *p, u64 gfn)
>>>>  {
>>>> @@ -640,12 +639,17 @@ static bool mshv_handle_gpa_intercept(struct mshv_vp *vp)
>>>>  {
>>>>  	struct mshv_partition *p = vp->vp_partition;
>>>>  	struct mshv_mem_region *region;
>>>> -	struct hv_x64_memory_intercept_message *msg;
>>>>  	bool ret;
>>>>  	u64 gfn;
>>>> -
>>>> -	msg = (struct hv_x64_memory_intercept_message *)
>>>> +#if defined(CONFIG_X86_64)
>>>> +	struct hv_x64_memory_intercept_message *msg =
>>>> +		(struct hv_x64_memory_intercept_message *)
>>>> +		vp->vp_intercept_msg_page->u.payload;
>>>> +#elif defined(CONFIG_ARM64)
>>>> +	struct hv_arm64_memory_intercept_message *msg =
>>>> +		(struct hv_arm64_memory_intercept_message *)
>>>>  		vp->vp_intercept_msg_page->u.payload;
>>>> +#endif
>>>>  
>>>>  	gfn = HVPFN_DOWN(msg->guest_physical_address);
>>>>  
>>>> @@ -663,9 +667,6 @@ static bool mshv_handle_gpa_intercept(struct mshv_vp *vp)
>>>>  
>>>>  	return ret;
>>>>  }
>>>> -#else  /* CONFIG_X86_64 */
>>>> -static bool mshv_handle_gpa_intercept(struct mshv_vp *vp) { return false; }
>>>> -#endif /* CONFIG_X86_64 */
>>>>  
>>>>  static bool mshv_vp_handle_intercept(struct mshv_vp *vp)
>>>>  {
>>>> -- 
>>>> 2.34.1
>>>>

Re: [PATCH v2 2/2] mshv: handle gpa intercepts for arm64

[Anirudh Rayabharam]

On Tue, Jan 06, 2026 at 08:36:15AM -0800, Stanislav Kinsburskii wrote:
> On Tue, Jan 06, 2026 at 07:21:41AM +0000, Anirudh Rayabharam wrote:
> > On Mon, Jan 05, 2026 at 09:04:02AM -0800, Stanislav Kinsburskii wrote:
> > > On Mon, Jan 05, 2026 at 12:28:37PM +0000, Anirudh Rayabharam wrote:
> > > > From: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>
> > > > 
> > > > The mshv driver now uses movable pages for guests. For arm64 guests
> > > > to be functional, handle gpa intercepts for arm64 too (the current
> > > > code implements handling only for x86).
> > > > 
> > > > Move some arch-agnostic functions out of #ifdefs so that they can be
> > > > re-used.
> > > > 
> > > > Fixes: b9a66cd5ccbb ("mshv: Add support for movable memory regions")
> > > 
> > > I'm not sure that this patch needs "Fixes" tag as it introduced new
> > > functionality rather than fixing a bug.
> > 
> > This does fix a bug. The commit mentioned here regressed arm64 guests because
> > it didn't have GPA intercept handling for arm64.
> > 
> 
> Were ARM guests functional before this commit? If yes, then I agree that

Yes.

> this patch fixes a bug. If no, then this is just adding new
> functionality.
> I had an impression ARM is not yet supported in MSHV, so please clarify.

No, ARM is very much supported in MSHV. Going forward all new
code/features should be written for arm64 too. Missing arm64
implementation in way that leaves guests broken is a bug.

Thanks,
Anirudh.

> 
> Thanks,
> Stanislav
> 
> > Thanks,
> > Anirudh.
> > 
> > > 
> > > Thanks,
> > > Stanislav
> > > 
> > > > Signed-off-by: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>
> > > > ---
> > > >  drivers/hv/mshv_root_main.c | 15 ++++++++-------
> > > >  1 file changed, 8 insertions(+), 7 deletions(-)
> > > > 
> > > > diff --git a/drivers/hv/mshv_root_main.c b/drivers/hv/mshv_root_main.c
> > > > index 9cf28a3f12fe..f8c4c2ae2cc9 100644
> > > > --- a/drivers/hv/mshv_root_main.c
> > > > +++ b/drivers/hv/mshv_root_main.c
> > > > @@ -608,7 +608,6 @@ mshv_partition_region_by_gfn(struct mshv_partition *partition, u64 gfn)
> > > >  	return NULL;
> > > >  }
> > > >  
> > > > -#ifdef CONFIG_X86_64
> > > >  static struct mshv_mem_region *
> > > >  mshv_partition_region_by_gfn_get(struct mshv_partition *p, u64 gfn)
> > > >  {
> > > > @@ -640,12 +639,17 @@ static bool mshv_handle_gpa_intercept(struct mshv_vp *vp)
> > > >  {
> > > >  	struct mshv_partition *p = vp->vp_partition;
> > > >  	struct mshv_mem_region *region;
> > > > -	struct hv_x64_memory_intercept_message *msg;
> > > >  	bool ret;
> > > >  	u64 gfn;
> > > > -
> > > > -	msg = (struct hv_x64_memory_intercept_message *)
> > > > +#if defined(CONFIG_X86_64)
> > > > +	struct hv_x64_memory_intercept_message *msg =
> > > > +		(struct hv_x64_memory_intercept_message *)
> > > > +		vp->vp_intercept_msg_page->u.payload;
> > > > +#elif defined(CONFIG_ARM64)
> > > > +	struct hv_arm64_memory_intercept_message *msg =
> > > > +		(struct hv_arm64_memory_intercept_message *)
> > > >  		vp->vp_intercept_msg_page->u.payload;
> > > > +#endif
> > > >  
> > > >  	gfn = HVPFN_DOWN(msg->guest_physical_address);
> > > >  
> > > > @@ -663,9 +667,6 @@ static bool mshv_handle_gpa_intercept(struct mshv_vp *vp)
> > > >  
> > > >  	return ret;
> > > >  }
> > > > -#else  /* CONFIG_X86_64 */
> > > > -static bool mshv_handle_gpa_intercept(struct mshv_vp *vp) { return false; }
> > > > -#endif /* CONFIG_X86_64 */
> > > >  
> > > >  static bool mshv_vp_handle_intercept(struct mshv_vp *vp)
> > > >  {
> > > > -- 
> > > > 2.34.1
> > > > 

Re: [PATCH v2 0/2] Fixes for movable pages

[Wei Liu]

On Mon, Jan 05, 2026 at 12:28:35PM +0000, Anirudh Rayabharam wrote:
> From: "Anirudh Rayabharam (Microsoft)" <anirudh@anirudhrb.com>
> 
> Fix movable pages for arm64 guests by implementing a GPA intercept
> handler.
> 
> v2:
>   - Added "Fixes:" tag
>   - Got rid of the utility function to get intercept GPA and instead
>     integrated the rather small logic into the GPA intercept handling
>     function.
>   - Dropped patch 3 since it was applied to the fixes tree.
> 
> Anirudh Rayabharam (Microsoft) (2):
>   hyperv: add definitions for arm64 gpa intercepts
>   mshv: handle gpa intercepts for arm64
> 

The code looks fine. I have queued both patches.

I massaged the first subject line a bit.

Wei

>  drivers/hv/mshv_root_main.c | 15 ++++++------
>  include/hyperv/hvhdk.h      | 47 +++++++++++++++++++++++++++++++++++++
>  2 files changed, 55 insertions(+), 7 deletions(-)
> 
> -- 
> 2.34.1
>