[PATCH 0/3] Fixes for movable pages

[PATCH 0/3] 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.

Fix an improper cleanup issue in the region invalidation failure path.

Anirudh Rayabharam (Microsoft) (3):
  hyperv: add definitions for arm64 gpa intercepts
  mshv: handle gpa intercepts for arm64
  mshv: release mutex on region invalidation failure

 drivers/hv/mshv_regions.c   |  4 +++-
 drivers/hv/mshv_root_main.c | 38 +++++++++++++++++++++++-------
 include/hyperv/hvhdk.h      | 47 +++++++++++++++++++++++++++++++++++++
 3 files changed, 79 insertions(+), 10 deletions(-)

-- 
2.34.1

[PATCH 1/3] 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..a286f75f0afa 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;
+		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 1/3] hyperv: add definitions for arm64 gpa intercepts

[vdso]

> On 12/16/2025 6:20 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;

That looks oddly x86(-64)-specific (Current Priviledge Level).

Unless I'm mistaken, CPL doesn't belong here, and the bitfield isn't
used on ARM64. Provided the layout of the struct is correct, the
bitfield can have a better name of `reserved0` or something like that.

> +		u16 debug_active:1;
> +		u16 interruption_pending:1;
> +		u16 vtl:4;
> +		u16 virtualization_fault_active:1;
> +		u16 reserved:7;
> +	} __packed;

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

[Anirudh Rayabharam]

On Tue, Dec 16, 2025 at 07:07:45AM -0800, vdso@mailbox.org wrote:
> 
> > On 12/16/2025 6:20 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;
> 
> That looks oddly x86(-64)-specific (Current Priviledge Level).
> 
> Unless I'm mistaken, CPL doesn't belong here, and the bitfield isn't
> used on ARM64. Provided the layout of the struct is correct, the
> bitfield can have a better name of `reserved0` or something like that.

Hmmm... this is how it is defined in the hypervisor headers though.

Anirudh.

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

[vdso]

> On 12/16/2025 9:08 PM  Anirudh Rayabharam <anirudh@anirudhrb.com> wrote:
> 
>  
> On Tue, Dec 16, 2025 at 07:07:45AM -0800, vdso@mailbox.org wrote:
> > 
> > > On 12/16/2025 6:20 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;
> > 
> > That looks oddly x86(-64)-specific (Current Priviledge Level).
> > 
> > Unless I'm mistaken, CPL doesn't belong here, and the bitfield isn't
> > used on ARM64. Provided the layout of the struct is correct, the
> > bitfield can have a better name of `reserved0` or something like that.
> 
> Hmmm... this is how it is defined in the hypervisor headers though.

The questions would be why the hypervisor has got that there (e.g., the
definitions of that struct for x86 and ARM64 are merged), and if Linux needs
to care about the reason valid in the hv's codebase. Perhaps the definitions
are merged there to write less arch-specific code, similar to what Stas suggested
for the patch 2.

I haven't been able to find anything called CPL in the ARM64 arch docs, and
that field really sticks out as the x86-64's CPL. Naming it like that in an
ARM64-specific structure doesn't look justified.

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

[Wei Liu]

On Wed, Dec 17, 2025 at 10:38:47AM +0530, Anirudh Rayabharam wrote:
> On Tue, Dec 16, 2025 at 07:07:45AM -0800, vdso@mailbox.org wrote:
> > 
> > > On 12/16/2025 6:20 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;
> > 
> > That looks oddly x86(-64)-specific (Current Priviledge Level).
> > 
> > Unless I'm mistaken, CPL doesn't belong here, and the bitfield isn't
> > used on ARM64. Provided the layout of the struct is correct, the
> > bitfield can have a better name of `reserved0` or something like that.
> 
> Hmmm... this is how it is defined in the hypervisor headers though.

We should ask the hypervisor folks then. Once this gets out in the wild
it will be difficult to change.

Wei

> 
> Anirudh.

[PATCH 2/3] 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). Without this, arm64 guests are
broken.

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

Signed-off-by: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>
---
 drivers/hv/mshv_root_main.c | 38 ++++++++++++++++++++++++++++---------
 1 file changed, 29 insertions(+), 9 deletions(-)

diff --git a/drivers/hv/mshv_root_main.c b/drivers/hv/mshv_root_main.c
index 9cf28a3f12fe..882605349664 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)
 {
@@ -625,6 +624,34 @@ mshv_partition_region_by_gfn_get(struct mshv_partition *p, u64 gfn)
 	return region;
 }
 
+#ifdef CONFIG_X86_64
+static u64 mshv_get_gpa_intercept_gfn(struct mshv_vp *vp)
+{
+	struct hv_x64_memory_intercept_message *msg;
+	u64 gfn;
+
+	msg = (struct hv_x64_memory_intercept_message *)
+		vp->vp_intercept_msg_page->u.payload;
+
+	gfn = HVPFN_DOWN(msg->guest_physical_address);
+
+	return gfn;
+}
+#else  /* CONFIG_X86_64 */
+static u64 mshv_get_gpa_intercept_gfn(struct mshv_vp *vp)
+{
+	struct hv_arm64_memory_intercept_message *msg;
+	u64 gfn;
+
+	msg = (struct hv_arm64_memory_intercept_message *)
+		vp->vp_intercept_msg_page->u.payload;
+
+	gfn = HVPFN_DOWN(msg->guest_physical_address);
+
+	return gfn;
+}
+#endif /* CONFIG_X86_64 */
+
 /**
  * mshv_handle_gpa_intercept - Handle GPA (Guest Physical Address) intercepts.
  * @vp: Pointer to the virtual processor structure.
@@ -640,14 +667,10 @@ 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 *)
-		vp->vp_intercept_msg_page->u.payload;
-
-	gfn = HVPFN_DOWN(msg->guest_physical_address);
+	gfn = mshv_get_gpa_intercept_gfn(vp);
 
 	region = mshv_partition_region_by_gfn_get(p, gfn);
 	if (!region)
@@ -663,9 +686,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 2/3] mshv: handle gpa intercepts for arm64

[Stanislav Kinsburskii]

On Tue, Dec 16, 2025 at 02:20:29PM +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). Without this, arm64 guests are
> broken.
> 
> Move some arch-agnostic functions out of #ifdefs so that they can be
> re-used.
> 
> Signed-off-by: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>
> ---
>  drivers/hv/mshv_root_main.c | 38 ++++++++++++++++++++++++++++---------
>  1 file changed, 29 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/hv/mshv_root_main.c b/drivers/hv/mshv_root_main.c
> index 9cf28a3f12fe..882605349664 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)
>  {
> @@ -625,6 +624,34 @@ mshv_partition_region_by_gfn_get(struct mshv_partition *p, u64 gfn)
>  	return region;
>  }
>  
> +#ifdef CONFIG_X86_64
> +static u64 mshv_get_gpa_intercept_gfn(struct mshv_vp *vp)
> +{
> +	struct hv_x64_memory_intercept_message *msg;
> +	u64 gfn;
> +
> +	msg = (struct hv_x64_memory_intercept_message *)
> +		vp->vp_intercept_msg_page->u.payload;
> +
> +	gfn = HVPFN_DOWN(msg->guest_physical_address);
> +
> +	return gfn;
> +}
> +#else  /* CONFIG_X86_64 */

It's better to explicitly branch for ARM64 here for clarity as
hv_arm64_memory_intercept_message is defined only for ARM64.

> +static u64 mshv_get_gpa_intercept_gfn(struct mshv_vp *vp)
> +{
> +	struct hv_arm64_memory_intercept_message *msg;
> +	u64 gfn;
> +
> +	msg = (struct hv_arm64_memory_intercept_message *)
> +		vp->vp_intercept_msg_page->u.payload;
> +
> +	gfn = HVPFN_DOWN(msg->guest_physical_address);
> +
> +	return gfn;
> +}
> +#endif /* CONFIG_X86_64 */
> +

Are these functions really needed?
It would be clearer (and shorter) to branch directly in
mshv_handle_gpa_intercept.

Thanks,
Stanislav

>  /**
>   * mshv_handle_gpa_intercept - Handle GPA (Guest Physical Address) intercepts.
>   * @vp: Pointer to the virtual processor structure.
> @@ -640,14 +667,10 @@ 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 *)
> -		vp->vp_intercept_msg_page->u.payload;
> -
> -	gfn = HVPFN_DOWN(msg->guest_physical_address);
> +	gfn = mshv_get_gpa_intercept_gfn(vp);
>  
>  	region = mshv_partition_region_by_gfn_get(p, gfn);
>  	if (!region)
> @@ -663,9 +686,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 2/3] mshv: handle gpa intercepts for arm64

[Anirudh Rayabharam]

On Tue, Dec 16, 2025 at 08:11:01AM -0800, Stanislav Kinsburskii wrote:
> On Tue, Dec 16, 2025 at 02:20:29PM +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). Without this, arm64 guests are
> > broken.
> > 
> > Move some arch-agnostic functions out of #ifdefs so that they can be
> > re-used.
> > 
> > Signed-off-by: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>
> > ---
> >  drivers/hv/mshv_root_main.c | 38 ++++++++++++++++++++++++++++---------
> >  1 file changed, 29 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/hv/mshv_root_main.c b/drivers/hv/mshv_root_main.c
> > index 9cf28a3f12fe..882605349664 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)
> >  {
> > @@ -625,6 +624,34 @@ mshv_partition_region_by_gfn_get(struct mshv_partition *p, u64 gfn)
> >  	return region;
> >  }
> >  
> > +#ifdef CONFIG_X86_64
> > +static u64 mshv_get_gpa_intercept_gfn(struct mshv_vp *vp)
> > +{
> > +	struct hv_x64_memory_intercept_message *msg;
> > +	u64 gfn;
> > +
> > +	msg = (struct hv_x64_memory_intercept_message *)
> > +		vp->vp_intercept_msg_page->u.payload;
> > +
> > +	gfn = HVPFN_DOWN(msg->guest_physical_address);
> > +
> > +	return gfn;
> > +}
> > +#else  /* CONFIG_X86_64 */
> 
> It's better to explicitly branch for ARM64 here for clarity as
> hv_arm64_memory_intercept_message is defined only for ARM64.

Ack.

> 
> > +static u64 mshv_get_gpa_intercept_gfn(struct mshv_vp *vp)
> > +{
> > +	struct hv_arm64_memory_intercept_message *msg;
> > +	u64 gfn;
> > +
> > +	msg = (struct hv_arm64_memory_intercept_message *)
> > +		vp->vp_intercept_msg_page->u.payload;
> > +
> > +	gfn = HVPFN_DOWN(msg->guest_physical_address);
> > +
> > +	return gfn;
> > +}
> > +#endif /* CONFIG_X86_64 */
> > +
> 
> Are these functions really needed?
> It would be clearer (and shorter) to branch directly in
> mshv_handle_gpa_intercept.

True, that might be simpler. I'll send a v2.

Thanks,
Anirudh

[PATCH 3/3] mshv: release mutex on region invalidation failure

[Anirudh Rayabharam]

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

In the region invalidation failure path in
mshv_region_interval_invalidate(), the region mutex is not released. Fix
it by releasing the mutex in the failure path.

Signed-off-by: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>
---
 drivers/hv/mshv_regions.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/hv/mshv_regions.c b/drivers/hv/mshv_regions.c
index 8abf80129f9b..30bacba6aec3 100644
--- a/drivers/hv/mshv_regions.c
+++ b/drivers/hv/mshv_regions.c
@@ -511,7 +511,7 @@ static bool mshv_region_interval_invalidate(struct mmu_interval_notifier *mni,
 	ret = mshv_region_remap_pages(region, HV_MAP_GPA_NO_ACCESS,
 				      page_offset, page_count);
 	if (ret)
-		goto out_fail;
+		goto out_unlock;
 
 	mshv_region_invalidate_pages(region, page_offset, page_count);
 
@@ -519,6 +519,8 @@ static bool mshv_region_interval_invalidate(struct mmu_interval_notifier *mni,
 
 	return true;
 
+out_unlock:
+	mutex_unlock(&region->mutex);
 out_fail:
 	WARN_ONCE(ret,
 		  "Failed to invalidate region %#llx-%#llx (range %#lx-%#lx, event: %u, pages %#llx-%#llx, mm: %#llx): %d\n",
-- 
2.34.1

Re: [PATCH 3/3] mshv: release mutex on region invalidation failure

[vdso]

> On 12/16/2025 6:20 AM  Anirudh Rayabharam <anirudh@anirudhrb.com> wrote:
> 
>  
> From: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>
> 
> In the region invalidation failure path in
> mshv_region_interval_invalidate(), the region mutex is not released. Fix
> it by releasing the mutex in the failure path.
> 
> Signed-off-by: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>

Reviewed-by: Roman Kisel <vdso@mailbox.org>

> ---
>  drivers/hv/mshv_regions.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/hv/mshv_regions.c b/drivers/hv/mshv_regions.c
> index 8abf80129f9b..30bacba6aec3 100644
> --- a/drivers/hv/mshv_regions.c
> +++ b/drivers/hv/mshv_regions.c
> @@ -511,7 +511,7 @@ static bool mshv_region_interval_invalidate(struct mmu_interval_notifier *mni,
>  	ret = mshv_region_remap_pages(region, HV_MAP_GPA_NO_ACCESS,
>  				      page_offset, page_count);
>  	if (ret)
> -		goto out_fail;
> +		goto out_unlock;
>  
>  	mshv_region_invalidate_pages(region, page_offset, page_count);
>  
> @@ -519,6 +519,8 @@ static bool mshv_region_interval_invalidate(struct mmu_interval_notifier *mni,
>  
>  	return true;
>  
> +out_unlock:
> +	mutex_unlock(&region->mutex);
>  out_fail:
>  	WARN_ONCE(ret,
>  		  "Failed to invalidate region %#llx-%#llx (range %#lx-%#lx, event: %u, pages %#llx-%#llx, mm: %#llx): %d\n",
> -- 
> 2.34.1

Re: [PATCH 3/3] mshv: release mutex on region invalidation failure

[Stanislav Kinsburskii]

On Tue, Dec 16, 2025 at 02:20:30PM +0000, Anirudh Rayabharam wrote:
> From: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>
> 
> In the region invalidation failure path in
> mshv_region_interval_invalidate(), the region mutex is not released. Fix
> it by releasing the mutex in the failure path.
> 

Please, add the corresponding "Fixes" tag.

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

> Signed-off-by: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>
> ---
>  drivers/hv/mshv_regions.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/hv/mshv_regions.c b/drivers/hv/mshv_regions.c
> index 8abf80129f9b..30bacba6aec3 100644
> --- a/drivers/hv/mshv_regions.c
> +++ b/drivers/hv/mshv_regions.c
> @@ -511,7 +511,7 @@ static bool mshv_region_interval_invalidate(struct mmu_interval_notifier *mni,
>  	ret = mshv_region_remap_pages(region, HV_MAP_GPA_NO_ACCESS,
>  				      page_offset, page_count);
>  	if (ret)
> -		goto out_fail;
> +		goto out_unlock;
>  
>  	mshv_region_invalidate_pages(region, page_offset, page_count);
>  
> @@ -519,6 +519,8 @@ static bool mshv_region_interval_invalidate(struct mmu_interval_notifier *mni,
>  
>  	return true;
>  
> +out_unlock:
> +	mutex_unlock(&region->mutex);
>  out_fail:
>  	WARN_ONCE(ret,
>  		  "Failed to invalidate region %#llx-%#llx (range %#lx-%#lx, event: %u, pages %#llx-%#llx, mm: %#llx): %d\n",
> -- 
> 2.34.1
> 

Re: [PATCH 3/3] mshv: release mutex on region invalidation failure

[Wei Liu]

On Tue, Dec 16, 2025 at 02:20:30PM +0000, Anirudh Rayabharam wrote:
> From: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>
> 
> In the region invalidation failure path in
> mshv_region_interval_invalidate(), the region mutex is not released. Fix
> it by releasing the mutex in the failure path.
> 
> Signed-off-by: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>

I applied this patch to hyperv-fixes.

Wei