* Re: [PATCH 4/6] mshv: Get the vmm capabilities offered by the hypervisor
From: Easwar Hariharan @ 2025-09-05 19:29 UTC (permalink / raw)
To: Nuno Das Neves
Cc: linux-hyperv, linux-kernel, easwar.hariharan, kys, haiyangz,
wei.liu, mhklinux, decui, paekkaladevi
In-Reply-To: <1756428230-3599-5-git-send-email-nunodasneves@linux.microsoft.com>
On 8/28/2025 5:43 PM, Nuno Das Neves wrote:
> From: Purna Pavan Chandra Aekkaladevi <paekkaladevi@linux.microsoft.com>
>
> Some newer hypervisor APIs are gated by feature bits in the so-called
> "vmm capabilities" partition property. Store the capabilities on
> mshv_root module init, using HVCALL_GET_PARTITION_PROPERTY_EX.
>
> Signed-off-by: Purna Pavan Chandra Aekkaladevi <paekkaladevi@linux.microsoft.com>
> Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
> ---
> drivers/hv/mshv_root.h | 1 +
> drivers/hv/mshv_root_main.c | 28 ++++++++++++++++++++++++++++
> 2 files changed, 29 insertions(+)
Looks good to me.
Reviewed-by: Easwar Hariharan <easwar.hariharan@linux.microsoft.com>
^ permalink raw reply
* Re: [PATCH 3/6] mshv: Add the HVCALL_GET_PARTITION_PROPERTY_EX hypercall
From: Easwar Hariharan @ 2025-09-05 19:28 UTC (permalink / raw)
To: Nuno Das Neves
Cc: linux-hyperv, linux-kernel, easwar.hariharan, kys, haiyangz,
wei.liu, mhklinux, decui, paekkaladevi
In-Reply-To: <1756428230-3599-4-git-send-email-nunodasneves@linux.microsoft.com>
On 8/28/2025 5:43 PM, Nuno Das Neves wrote:
> From: Purna Pavan Chandra Aekkaladevi <paekkaladevi@linux.microsoft.com>
>
> This hypercall can be used to fetch extended properties of a
> partition. Extended properties are properties with values larger than
> a u64. Some of these also need additional input arguments.
>
> Add helper function for using the hypercall in the mshv_root driver.
>
> Signed-off-by: Purna Pavan Chandra Aekkaladevi <paekkaladevi@linux.microsoft.com>
> Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
> ---
> drivers/hv/mshv_root.h | 2 ++
> drivers/hv/mshv_root_hv_call.c | 31 ++++++++++++++++++++++++++
> include/hyperv/hvgdk_mini.h | 1 +
> include/hyperv/hvhdk.h | 40 ++++++++++++++++++++++++++++++++++
> include/hyperv/hvhdk_mini.h | 26 ++++++++++++++++++++++
> 5 files changed, 100 insertions(+)
>
> diff --git a/drivers/hv/mshv_root.h b/drivers/hv/mshv_root.h
> index e3931b0f1269..4aeb03bea6b6 100644
> --- a/drivers/hv/mshv_root.h
> +++ b/drivers/hv/mshv_root.h
> @@ -303,6 +303,8 @@ int hv_call_unmap_stat_page(enum hv_stats_object_type type,
> int hv_call_modify_spa_host_access(u64 partition_id, struct page **pages,
> u64 page_struct_count, u32 host_access,
> u32 flags, u8 acquire);
> +int hv_call_get_partition_property_ex(u64 partition_id, u64 property_code, u64 arg,
> + void *property_value, size_t property_value_sz);
>
> extern struct mshv_root mshv_root;
> extern enum hv_scheduler_type hv_scheduler_type;
> diff --git a/drivers/hv/mshv_root_hv_call.c b/drivers/hv/mshv_root_hv_call.c
> index 1c38576a673c..7589b1ff3515 100644
> --- a/drivers/hv/mshv_root_hv_call.c
> +++ b/drivers/hv/mshv_root_hv_call.c
> @@ -590,6 +590,37 @@ int hv_call_unmap_vp_state_page(u64 partition_id, u32 vp_index, u32 type,
> return hv_result_to_errno(status);
> }
>
> +int
> +hv_call_get_partition_property_ex(u64 partition_id, u64 property_code, u64 arg,
One line like in patch 2..
<snip>
Thanks,
Easwar (he/him)
^ permalink raw reply
* Re: [PATCH 2/6] mshv: Ignore second stats page map result failure
From: Easwar Hariharan @ 2025-09-05 19:21 UTC (permalink / raw)
To: Nuno Das Neves
Cc: linux-hyperv, linux-kernel, easwar.hariharan, kys, haiyangz,
wei.liu, mhklinux, decui, paekkaladevi
In-Reply-To: <1756428230-3599-3-git-send-email-nunodasneves@linux.microsoft.com>
On 8/28/2025 5:43 PM, Nuno Das Neves wrote:
> From: Purna Pavan Chandra Aekkaladevi <paekkaladevi@linux.microsoft.com>
>
> Some versions of the hypervisor do not support HV_STATUS_AREA_PARENT and
> return HV_STATUS_INVALID_PARAMETER for the second stats page mapping
> request.
>
> This results a failure in module init. Instead of failing, gracefully
> fall back to populating stats_pages[HV_STATS_AREA_PARENT] with the
> already-mapped stats_pages[HV_STATS_AREA_SELF].
What's the impact of this graceful fallback? It occurs to me that if a stats
accumulator, in userspace perhaps, expected to get stats from the 2 pages,
it'd get incorrect values.
>
> Signed-off-by: Purna Pavan Chandra Aekkaladevi <paekkaladevi@linux.microsoft.com>
> Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
> ---
> drivers/hv/mshv_root_hv_call.c | 43 ++++++++++++++++++++++++++++++----
> drivers/hv/mshv_root_main.c | 3 +++
> 2 files changed, 42 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/hv/mshv_root_hv_call.c b/drivers/hv/mshv_root_hv_call.c
> index c9c274f29c3c..1c38576a673c 100644
> --- a/drivers/hv/mshv_root_hv_call.c
> +++ b/drivers/hv/mshv_root_hv_call.c
> @@ -724,6 +724,24 @@ hv_call_notify_port_ring_empty(u32 sint_index)
> return hv_result_to_errno(status);
> }
>
> +static int
> +hv_stats_get_area_type(enum hv_stats_object_type type,
One line please, i.e.
static int hv_stats_get_area_type(...)
<snip>
Thanks,
Easwar (he/him)
^ permalink raw reply
* Re: [PATCH 4/6] mshv: Get the vmm capabilities offered by the hypervisor
From: Anirudh Rayabharam @ 2025-09-05 19:03 UTC (permalink / raw)
To: Nuno Das Neves
Cc: linux-hyperv, linux-kernel, kys, haiyangz, wei.liu, mhklinux,
decui, paekkaladevi
In-Reply-To: <1756428230-3599-5-git-send-email-nunodasneves@linux.microsoft.com>
On Thu, Aug 28, 2025 at 05:43:48PM -0700, Nuno Das Neves wrote:
> From: Purna Pavan Chandra Aekkaladevi <paekkaladevi@linux.microsoft.com>
>
> Some newer hypervisor APIs are gated by feature bits in the so-called
> "vmm capabilities" partition property. Store the capabilities on
> mshv_root module init, using HVCALL_GET_PARTITION_PROPERTY_EX.
>
> Signed-off-by: Purna Pavan Chandra Aekkaladevi <paekkaladevi@linux.microsoft.com>
> Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
> ---
> drivers/hv/mshv_root.h | 1 +
> drivers/hv/mshv_root_main.c | 28 ++++++++++++++++++++++++++++
> 2 files changed, 29 insertions(+)
>
> diff --git a/drivers/hv/mshv_root.h b/drivers/hv/mshv_root.h
> index 4aeb03bea6b6..0cb1e2589fe1 100644
> --- a/drivers/hv/mshv_root.h
> +++ b/drivers/hv/mshv_root.h
> @@ -178,6 +178,7 @@ struct mshv_root {
> struct hv_synic_pages __percpu *synic_pages;
> spinlock_t pt_ht_lock;
> DECLARE_HASHTABLE(pt_htable, MSHV_PARTITIONS_HASH_BITS);
> + struct hv_partition_property_vmm_capabilities vmm_caps;
> };
>
> /*
> diff --git a/drivers/hv/mshv_root_main.c b/drivers/hv/mshv_root_main.c
> index 56ababab57ce..29f61ecc9771 100644
> --- a/drivers/hv/mshv_root_main.c
> +++ b/drivers/hv/mshv_root_main.c
> @@ -2327,6 +2327,28 @@ static int __init mshv_root_partition_init(struct device *dev)
> return err;
> }
>
> +static int mshv_init_vmm_caps(struct device *dev)
> +{
> + int ret;
> +
> + memset(&mshv_root.vmm_caps, 0, sizeof(mshv_root.vmm_caps));
> + ret = hv_call_get_partition_property_ex(HV_PARTITION_ID_SELF,
> + HV_PARTITION_PROPERTY_VMM_CAPABILITIES,
> + 0, &mshv_root.vmm_caps,
> + sizeof(mshv_root.vmm_caps));
> +
> + /*
> + * HV_PARTITION_PROPERTY_VMM_CAPABILITIES is not supported in
> + * older hyperv. Ignore the -EIO error code.
> + */
> + if (ret && ret != -EIO)
> + return ret;
> +
> + dev_dbg(dev, "vmm_caps=0x%llx\n", mshv_root.vmm_caps.as_uint64[0]);
> +
> + return 0;
> +}
> +
> static int __init mshv_parent_partition_init(void)
> {
> int ret;
> @@ -2377,6 +2399,12 @@ static int __init mshv_parent_partition_init(void)
> if (ret)
> goto remove_cpu_state;
>
> + ret = mshv_init_vmm_caps(dev);
> + if (ret) {
> + dev_err(dev, "Failed to get VMM capabilities\n");
> + goto exit_partition;
Should this really be treated as a failure here? We could still offer
/dev/mshv albeit with potentially limited capabilities.
Thanks,
Anirudh.
> + }
> +
> ret = mshv_irqfd_wq_init();
> if (ret)
> goto exit_partition;
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH 4/6] mshv: Get the vmm capabilities offered by the hypervisor
From: Nuno Das Neves @ 2025-09-05 18:49 UTC (permalink / raw)
To: Praveen K Paladugu, linux-hyperv, linux-kernel
Cc: kys, haiyangz, wei.liu, mhklinux, decui, paekkaladevi
In-Reply-To: <64adc508-d18b-4075-835d-97ce5b68c4eb@gmail.com>
On 9/5/2025 8:43 AM, Praveen K Paladugu wrote:
>
>
> On 8/28/2025 7:43 PM, Nuno Das Neves wrote:
>> From: Purna Pavan Chandra Aekkaladevi <paekkaladevi@linux.microsoft.com>
>>
>> Some newer hypervisor APIs are gated by feature bits in the so-called
>> "vmm capabilities" partition property. Store the capabilities on
> nit: s/xx/Some hypervisor APIs are gated by feature bits exposed in
> "vmm capabilities" partition property./g
Thanks, I'll update it for v2
Nuno
>> mshv_root module init, using HVCALL_GET_PARTITION_PROPERTY_EX.
>>>> Signed-off-by: Purna Pavan Chandra Aekkaladevi <paekkaladevi@linux.microsoft.com>
>> Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
>> ---
>> drivers/hv/mshv_root.h | 1 +
>> drivers/hv/mshv_root_main.c | 28 ++++++++++++++++++++++++++++
>> 2 files changed, 29 insertions(+)
>>
>> diff --git a/drivers/hv/mshv_root.h b/drivers/hv/mshv_root.h
>> index 4aeb03bea6b6..0cb1e2589fe1 100644
>> --- a/drivers/hv/mshv_root.h
>> +++ b/drivers/hv/mshv_root.h
>> @@ -178,6 +178,7 @@ struct mshv_root {
>> struct hv_synic_pages __percpu *synic_pages;
>> spinlock_t pt_ht_lock;
>> DECLARE_HASHTABLE(pt_htable, MSHV_PARTITIONS_HASH_BITS);
>> + struct hv_partition_property_vmm_capabilities vmm_caps;
>> };
>> /*
>> diff --git a/drivers/hv/mshv_root_main.c b/drivers/hv/mshv_root_main.c
>> index 56ababab57ce..29f61ecc9771 100644
>> --- a/drivers/hv/mshv_root_main.c
>> +++ b/drivers/hv/mshv_root_main.c
>> @@ -2327,6 +2327,28 @@ static int __init mshv_root_partition_init(struct device *dev)
>> return err;
>> }
>> +static int mshv_init_vmm_caps(struct device *dev)
>> +{
>> + int ret;
>> +
>> + memset(&mshv_root.vmm_caps, 0, sizeof(mshv_root.vmm_caps));
>> + ret = hv_call_get_partition_property_ex(HV_PARTITION_ID_SELF,
>> + HV_PARTITION_PROPERTY_VMM_CAPABILITIES,
>> + 0, &mshv_root.vmm_caps,
>> + sizeof(mshv_root.vmm_caps));
>> +
>> + /*
>> + * HV_PARTITION_PROPERTY_VMM_CAPABILITIES is not supported in
>> + * older hyperv. Ignore the -EIO error code.
>> + */
>> + if (ret && ret != -EIO)
>> + return ret;
>> +
>> + dev_dbg(dev, "vmm_caps=0x%llx\n", mshv_root.vmm_caps.as_uint64[0]);
>> +
>> + return 0;
>> +}
>> +
>> static int __init mshv_parent_partition_init(void)
>> {
>> int ret;
>> @@ -2377,6 +2399,12 @@ static int __init mshv_parent_partition_init(void)
>> if (ret)
>> goto remove_cpu_state;
>> + ret = mshv_init_vmm_caps(dev);
>> + if (ret) {
>> + dev_err(dev, "Failed to get VMM capabilities\n");
>> + goto exit_partition;
>> + }
>> +
>> ret = mshv_irqfd_wq_init();
>> if (ret)
>> goto exit_partition;
>
> Reviewed-by: Praveen K Paladugu <prapal@linux.microsoft.com>
^ permalink raw reply
* Re: [PATCH 2/6] mshv: Ignore second stats page map result failure
From: Nuno Das Neves @ 2025-09-05 18:48 UTC (permalink / raw)
To: Praveen K Paladugu, linux-hyperv, linux-kernel
Cc: kys, haiyangz, wei.liu, mhklinux, decui, paekkaladevi
In-Reply-To: <644647df-64d5-44eb-b7ac-13bd4b81d422@gmail.com>
On 9/5/2025 8:31 AM, Praveen K Paladugu wrote:
>
>
> On 8/28/2025 7:43 PM, Nuno Das Neves wrote:
>> From: Purna Pavan Chandra Aekkaladevi <paekkaladevi@linux.microsoft.com>
>>
>> Some versions of the hypervisor do not support HV_STATUS_AREA_PARENT and
>> return HV_STATUS_INVALID_PARAMETER for the second stats page mapping
>> request.
>>
> Is this behavior limited to VP stats? Or does it extend to other
> stats (hypervisor, partition, etc) as well?
>
In practice we will only need to worry about partition and VP.
In the current code in hyperv-next, it's only VP stats. Upcoming patches
to add debugfs code will also need it for partition stats.
>> This results a failure in module init. Instead of failing, gracefully
> nit: s/This results in a failure during module init/
Thanks, I'll change it for v2
Nuno
>> fall back to populating stats_pages[HV_STATS_AREA_PARENT] with the
>> already-mapped stats_pages[HV_STATS_AREA_SELF].
>>
>> Signed-off-by: Purna Pavan Chandra Aekkaladevi <paekkaladevi@linux.microsoft.com>
>> Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
>> ---
>> drivers/hv/mshv_root_hv_call.c | 43 ++++++++++++++++++++++++++++++----
>> drivers/hv/mshv_root_main.c | 3 +++
>> 2 files changed, 42 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/hv/mshv_root_hv_call.c b/drivers/hv/mshv_root_hv_call.c
>> index c9c274f29c3c..1c38576a673c 100644
>> --- a/drivers/hv/mshv_root_hv_call.c
>> +++ b/drivers/hv/mshv_root_hv_call.c
>> @@ -724,6 +724,24 @@ hv_call_notify_port_ring_empty(u32 sint_index)
>> return hv_result_to_errno(status);
>> }
>> +static int
>> +hv_stats_get_area_type(enum hv_stats_object_type type,
>> + const union hv_stats_object_identity *identity)
>> +{
>> + switch (type) {
>> + case HV_STATS_OBJECT_HYPERVISOR:
>> + return identity->hv.stats_area_type;
>> + case HV_STATS_OBJECT_LOGICAL_PROCESSOR:
>> + return identity->lp.stats_area_type;
>> + case HV_STATS_OBJECT_PARTITION:
>> + return identity->partition.stats_area_type;
>> + case HV_STATS_OBJECT_VP:
>> + return identity->vp.stats_area_type;
>> + }
>> +
>> + return -EINVAL;
>> +}
>> +
>> int hv_call_map_stat_page(enum hv_stats_object_type type,
>> const union hv_stats_object_identity *identity,
>> void **addr)
>> @@ -732,7 +750,7 @@ int hv_call_map_stat_page(enum hv_stats_object_type type,
>> struct hv_input_map_stats_page *input;
>> struct hv_output_map_stats_page *output;
>> u64 status, pfn;
>> - int ret = 0;
>> + int hv_status, ret = 0;
>> do {
>> local_irq_save(flags);
>> @@ -747,11 +765,28 @@ int hv_call_map_stat_page(enum hv_stats_object_type type,
>> pfn = output->map_location;
>> local_irq_restore(flags);
>> - if (hv_result(status) != HV_STATUS_INSUFFICIENT_MEMORY) {
>> - ret = hv_result_to_errno(status);
>> +
>> + hv_status = hv_result(status);
>> + if (hv_status != HV_STATUS_INSUFFICIENT_MEMORY) {
>> if (hv_result_success(status))
>> break;
>> - return ret;
>> +
>> + /*
>> + * Some versions of the hypervisor do not support the
>> + * PARENT stats area. In this case return "success" but
>> + * set the page to NULL. The caller checks for this
>> + * case instead just uses the SELF area.
>> + */
>> + if (hv_stats_get_area_type(type, identity) == HV_STATS_AREA_PARENT &&
>> + hv_status == HV_STATUS_INVALID_PARAMETER) {
>> + pr_debug_once("%s: PARENT area type is unsupported\n",
>> + __func__);
>> + *addr = NULL;
>> + return 0;
>> + }
>> +
>> + hv_status_debug(status, "\n");
>> + return hv_result_to_errno(status);
>> }
>> ret = hv_call_deposit_pages(NUMA_NO_NODE,
>> diff --git a/drivers/hv/mshv_root_main.c b/drivers/hv/mshv_root_main.c
>> index bbdefe8a2e9c..56ababab57ce 100644
>> --- a/drivers/hv/mshv_root_main.c
>> +++ b/drivers/hv/mshv_root_main.c
>> @@ -929,6 +929,9 @@ static int mshv_vp_stats_map(u64 partition_id, u32 vp_index,
>> if (err)
>> goto unmap_self;
>> + if (!stats_pages[HV_STATS_AREA_PARENT])
>> + stats_pages[HV_STATS_AREA_PARENT] = stats_pages[HV_STATS_AREA_SELF];
>> +
>> return 0;
>> unmap_self:
>
^ permalink raw reply
* Re: [PATCH 5/6] mshv: Allocate vp state page for HVCALL_MAP_VP_STATE_PAGE on L1VH
From: Praveen K Paladugu @ 2025-09-05 16:18 UTC (permalink / raw)
To: Nuno Das Neves, linux-hyperv, linux-kernel
Cc: kys, haiyangz, wei.liu, mhklinux, decui, paekkaladevi,
Jinank Jain
In-Reply-To: <1756428230-3599-6-git-send-email-nunodasneves@linux.microsoft.com>
On 8/28/2025 7:43 PM, Nuno Das Neves wrote:
> From: Jinank Jain <jinankjain@linux.microsoft.com>
>
> Introduce mshv_use_overlay_gpfn() to check if a page needs to be
> allocated and passed to the hypervisor to map VP state pages. This is
> only needed on L1VH, and only on some (newer) versions of the
> hypervisor, hence the need to check vmm_capabilities.
>
> Introduce functions hv_map/unmap_vp_state_page() to handle the
> allocation and freeing.
>
> Signed-off-by: Jinank Jain <jinankjain@linux.microsoft.com>
> Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
> ---
> drivers/hv/mshv_root.h | 11 +++---
> drivers/hv/mshv_root_hv_call.c | 61 +++++++++++++++++++++++++---
> drivers/hv/mshv_root_main.c | 72 +++++++++++++++++-----------------
> 3 files changed, 96 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/hv/mshv_root.h b/drivers/hv/mshv_root.h
> index 0cb1e2589fe1..d7c9520ef788 100644
> --- a/drivers/hv/mshv_root.h
> +++ b/drivers/hv/mshv_root.h
> @@ -279,11 +279,12 @@ int hv_call_set_vp_state(u32 vp_index, u64 partition_id,
> /* Choose between pages and bytes */
> struct hv_vp_state_data state_data, u64 page_count,
> struct page **pages, u32 num_bytes, u8 *bytes);
> -int hv_call_map_vp_state_page(u64 partition_id, u32 vp_index, u32 type,
> - union hv_input_vtl input_vtl,
> - struct page **state_page);
> -int hv_call_unmap_vp_state_page(u64 partition_id, u32 vp_index, u32 type,
> - union hv_input_vtl input_vtl);
> +int hv_map_vp_state_page(u64 partition_id, u32 vp_index, u32 type,
> + union hv_input_vtl input_vtl,
> + struct page **state_page);
> +int hv_unmap_vp_state_page(u64 partition_id, u32 vp_index, u32 type,
> + void *page_addr,
> + union hv_input_vtl input_vtl);
> int hv_call_create_port(u64 port_partition_id, union hv_port_id port_id,
> u64 connection_partition_id, struct hv_port_info *port_info,
> u8 port_vtl, u8 min_connection_vtl, int node);
> diff --git a/drivers/hv/mshv_root_hv_call.c b/drivers/hv/mshv_root_hv_call.c
> index 7589b1ff3515..1882cc90f2f5 100644
> --- a/drivers/hv/mshv_root_hv_call.c
> +++ b/drivers/hv/mshv_root_hv_call.c
> @@ -526,9 +526,9 @@ int hv_call_set_vp_state(u32 vp_index, u64 partition_id,
> return ret;
> }
>
> -int hv_call_map_vp_state_page(u64 partition_id, u32 vp_index, u32 type,
> - union hv_input_vtl input_vtl,
> - struct page **state_page)
> +static int hv_call_map_vp_state_page(u64 partition_id, u32 vp_index, u32 type,
> + union hv_input_vtl input_vtl,
> + struct page **state_page)
> {
> struct hv_input_map_vp_state_page *input;
> struct hv_output_map_vp_state_page *output;
> @@ -547,7 +547,14 @@ int hv_call_map_vp_state_page(u64 partition_id, u32 vp_index, u32 type,
> input->type = type;
> input->input_vtl = input_vtl;
>
> - status = hv_do_hypercall(HVCALL_MAP_VP_STATE_PAGE, input, output);
> + if (*state_page) {
> + input->flags.map_location_provided = 1;
> + input->requested_map_location =
> + page_to_pfn(*state_page);
> + }
> +
> + status = hv_do_hypercall(HVCALL_MAP_VP_STATE_PAGE, input,
> + output);
>
> if (hv_result(status) != HV_STATUS_INSUFFICIENT_MEMORY) {
> if (hv_result_success(status))
> @@ -565,8 +572,39 @@ int hv_call_map_vp_state_page(u64 partition_id, u32 vp_index, u32 type,
> return ret;
> }
>
> -int hv_call_unmap_vp_state_page(u64 partition_id, u32 vp_index, u32 type,
> - union hv_input_vtl input_vtl)
> +static bool mshv_use_overlay_gpfn(void)
> +{
> + return hv_l1vh_partition() &&
> + mshv_root.vmm_caps.vmm_can_provide_overlay_gpfn;
> +}
> +
> +int hv_map_vp_state_page(u64 partition_id, u32 vp_index, u32 type,
> + union hv_input_vtl input_vtl,
> + struct page **state_page)
> +{
> + int ret = 0;
> + struct page *allocated_page = NULL;
> +
> + if (mshv_use_overlay_gpfn()) {
> + allocated_page = alloc_page(GFP_KERNEL);
> + if (!allocated_page)
> + return -ENOMEM;
> + *state_page = allocated_page;
> + } else {
> + *state_page = NULL;
> + }
> +
> + ret = hv_call_map_vp_state_page(partition_id, vp_index, type, input_vtl,
> + state_page);
> +
> + if (ret && allocated_page)
> + __free_page(allocated_page);
> +
> + return ret;
> +}
> +
> +static int hv_call_unmap_vp_state_page(u64 partition_id, u32 vp_index, u32 type,
> + union hv_input_vtl input_vtl)
> {
> unsigned long flags;
> u64 status;
> @@ -590,6 +628,17 @@ int hv_call_unmap_vp_state_page(u64 partition_id, u32 vp_index, u32 type,
> return hv_result_to_errno(status);
> }
>
> +int hv_unmap_vp_state_page(u64 partition_id, u32 vp_index, u32 type,
> + void *page_addr, union hv_input_vtl input_vtl)
> +{
> + int ret = hv_call_unmap_vp_state_page(partition_id, vp_index, type, input_vtl);
> +
> + if (mshv_use_overlay_gpfn() && page_addr)
> + __free_page(virt_to_page(page_addr));
> +
> + return ret;
> +}
> +
> int
> hv_call_get_partition_property_ex(u64 partition_id, u64 property_code, u64 arg,
> void *property_value, size_t property_value_sz)
> diff --git a/drivers/hv/mshv_root_main.c b/drivers/hv/mshv_root_main.c
> index 29f61ecc9771..f91880cc9e29 100644
> --- a/drivers/hv/mshv_root_main.c
> +++ b/drivers/hv/mshv_root_main.c
> @@ -964,28 +964,25 @@ mshv_partition_ioctl_create_vp(struct mshv_partition *partition,
> if (ret)
> return ret;
>
> - ret = hv_call_map_vp_state_page(partition->pt_id, args.vp_index,
> - HV_VP_STATE_PAGE_INTERCEPT_MESSAGE,
> - input_vtl_zero,
> - &intercept_message_page);
> + ret = hv_map_vp_state_page(partition->pt_id, args.vp_index,
> + HV_VP_STATE_PAGE_INTERCEPT_MESSAGE,
> + input_vtl_zero, &intercept_message_page);
> if (ret)
> goto destroy_vp;
>
> if (!mshv_partition_encrypted(partition)) {
> - ret = hv_call_map_vp_state_page(partition->pt_id, args.vp_index,
> - HV_VP_STATE_PAGE_REGISTERS,
> - input_vtl_zero,
> - ®ister_page);
> + ret = hv_map_vp_state_page(partition->pt_id, args.vp_index,
> + HV_VP_STATE_PAGE_REGISTERS,
> + input_vtl_zero, ®ister_page);
> if (ret)
> goto unmap_intercept_message_page;
> }
>
> if (mshv_partition_encrypted(partition) &&
> is_ghcb_mapping_available()) {
> - ret = hv_call_map_vp_state_page(partition->pt_id, args.vp_index,
> - HV_VP_STATE_PAGE_GHCB,
> - input_vtl_normal,
> - &ghcb_page);
> + ret = hv_map_vp_state_page(partition->pt_id, args.vp_index,
> + HV_VP_STATE_PAGE_GHCB,
> + input_vtl_normal, &ghcb_page);
> if (ret)
> goto unmap_register_page;
> }
> @@ -1049,21 +1046,19 @@ mshv_partition_ioctl_create_vp(struct mshv_partition *partition,
> if (hv_scheduler_type == HV_SCHEDULER_TYPE_ROOT)
> mshv_vp_stats_unmap(partition->pt_id, args.vp_index);
> unmap_ghcb_page:
> - if (mshv_partition_encrypted(partition) && is_ghcb_mapping_available()) {
> - hv_call_unmap_vp_state_page(partition->pt_id, args.vp_index,
> - HV_VP_STATE_PAGE_GHCB,
> - input_vtl_normal);
> - }
> + if (mshv_partition_encrypted(partition) && is_ghcb_mapping_available())
> + hv_unmap_vp_state_page(partition->pt_id, args.vp_index,
> + HV_VP_STATE_PAGE_GHCB, vp->vp_ghcb_page,
> + input_vtl_normal);
> unmap_register_page:
> - if (!mshv_partition_encrypted(partition)) {
> - hv_call_unmap_vp_state_page(partition->pt_id, args.vp_index,
> - HV_VP_STATE_PAGE_REGISTERS,
> - input_vtl_zero);
> - }
> + if (!mshv_partition_encrypted(partition))
> + hv_unmap_vp_state_page(partition->pt_id, args.vp_index,
> + HV_VP_STATE_PAGE_REGISTERS,
> + vp->vp_register_page, input_vtl_zero);
> unmap_intercept_message_page:
> - hv_call_unmap_vp_state_page(partition->pt_id, args.vp_index,
> - HV_VP_STATE_PAGE_INTERCEPT_MESSAGE,
> - input_vtl_zero);
> + hv_unmap_vp_state_page(partition->pt_id, args.vp_index,
> + HV_VP_STATE_PAGE_INTERCEPT_MESSAGE,
> + vp->vp_intercept_msg_page, input_vtl_zero);
> destroy_vp:
> hv_call_delete_vp(partition->pt_id, args.vp_index);
> return ret;
> @@ -1804,24 +1799,27 @@ static void destroy_partition(struct mshv_partition *partition)
> mshv_vp_stats_unmap(partition->pt_id, vp->vp_index);
>
> if (vp->vp_register_page) {
> - (void)hv_call_unmap_vp_state_page(partition->pt_id,
> - vp->vp_index,
> - HV_VP_STATE_PAGE_REGISTERS,
> - input_vtl_zero);
> + (void)hv_unmap_vp_state_page(partition->pt_id,
> + vp->vp_index,
> + HV_VP_STATE_PAGE_REGISTERS,
> + vp->vp_register_page,
> + input_vtl_zero);
> vp->vp_register_page = NULL;
> }
>
> - (void)hv_call_unmap_vp_state_page(partition->pt_id,
> - vp->vp_index,
> - HV_VP_STATE_PAGE_INTERCEPT_MESSAGE,
> - input_vtl_zero);
> + (void)hv_unmap_vp_state_page(partition->pt_id,
> + vp->vp_index,
> + HV_VP_STATE_PAGE_INTERCEPT_MESSAGE,
> + vp->vp_intercept_msg_page,
> + input_vtl_zero);
> vp->vp_intercept_msg_page = NULL;
>
> if (vp->vp_ghcb_page) {
> - (void)hv_call_unmap_vp_state_page(partition->pt_id,
> - vp->vp_index,
> - HV_VP_STATE_PAGE_GHCB,
> - input_vtl_normal);
> + (void)hv_unmap_vp_state_page(partition->pt_id,
> + vp->vp_index,
> + HV_VP_STATE_PAGE_GHCB,
> + vp->vp_ghcb_page,
> + input_vtl_normal);
> vp->vp_ghcb_page = NULL;
> }
>
Reviewed-by: Praveen K Paladugu <prapal@linux.microsoft.com>
^ permalink raw reply
* RE: [PATCH v4] x86/hyperv: Fix kdump on Azure CVMs
From: Michael Kelley @ 2025-09-05 15:57 UTC (permalink / raw)
To: Vitaly Kuznetsov, Wei Liu
Cc: linux-hyperv@vger.kernel.org, K. Y. Srinivasan, Haiyang Zhang,
Wei Liu, Dexuan Cui, x86@kernel.org, linux-kernel@vger.kernel.org,
Nuno Das Neves, Tianyu Lan, Li Tian, Philipp Rudo
In-Reply-To: <87frd1figp.fsf@redhat.com>
From: Vitaly Kuznetsov <vkuznets@redhat.com> Sent: Friday, September 5, 2025 12:48 AM
>
> Wei Liu <wei.liu@kernel.org> writes:
>
> > On Thu, Aug 28, 2025 at 12:16:18PM +0300, Vitaly Kuznetsov wrote:
> >> Azure CVM instance types featuring a paravisor hang upon kdump. The
> >> investigation shows that makedumpfile causes a hang when it steps on a page
> >> which was previously share with the host
> >> (HVCALL_MODIFY_SPARSE_GPA_PAGE_HOST_VISIBILITY). The new kernel has no
> >> knowledge of these 'special' regions (which are Vmbus connection pages,
> >> GPADL buffers, ...). There are several ways to approach the issue:
> >> - Convey the knowledge about these regions to the new kernel somehow.
> >> - Unshare these regions before accessing in the new kernel (it is unclear
> >> if there's a way to query the status for a given GPA range).
> >> - Unshare these regions before jumping to the new kernel (which this patch
> >> implements).
> >>
> >> To make the procedure as robust as possible, store PFN ranges of shared
> >> regions in a linked list instead of storing GVAs and re-using
> >> hv_vtom_set_host_visibility(). This also allows to avoid memory allocation
> >> on the kdump/kexec path.
> >>
> >> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> >
> > No fixes tag for this one?
> >
>
> Personally, I don't see this as a 'bug', it's rather a missing
> feature. In theory, we can add something like
>
> Fixes: 810a52126502 ("x86/hyperv: Add new hvcall guest address host visibility
> support")
>
> but I'm on the fence whether this is accurate or not.
>
> > Should it be marked as a stable backport?
>
> I think it may make sense even without an explicit 'Fixes:': kdump is the
> user's last resort when it comes to kernel crashes and doubly so on
> CVMs. Pure kexec may also come handy.
>
I agree -- think of this as adding a feature instead of fixing a bug. Prior
to now, there hasn't been any attempt to make kexec/kdump work
for Azure CVMs.
Instead of using the word "Fix", maybe the patch "Subject:" should be
changed to "x86/hyperv: Add kexec/kdump support on Azure CVMs".
Michael
^ permalink raw reply
* Re: [PATCH 4/6] mshv: Get the vmm capabilities offered by the hypervisor
From: Praveen K Paladugu @ 2025-09-05 15:43 UTC (permalink / raw)
To: Nuno Das Neves, linux-hyperv, linux-kernel
Cc: kys, haiyangz, wei.liu, mhklinux, decui, paekkaladevi
In-Reply-To: <1756428230-3599-5-git-send-email-nunodasneves@linux.microsoft.com>
On 8/28/2025 7:43 PM, Nuno Das Neves wrote:
> From: Purna Pavan Chandra Aekkaladevi <paekkaladevi@linux.microsoft.com>
>
> Some newer hypervisor APIs are gated by feature bits in the so-called
> "vmm capabilities" partition property. Store the capabilities on
nit: s/xx/Some hypervisor APIs are gated by feature bits exposed in
"vmm capabilities" partition property./g> mshv_root module init, using
HVCALL_GET_PARTITION_PROPERTY_EX.
>
> Signed-off-by: Purna Pavan Chandra Aekkaladevi <paekkaladevi@linux.microsoft.com>
> Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
> ---
> drivers/hv/mshv_root.h | 1 +
> drivers/hv/mshv_root_main.c | 28 ++++++++++++++++++++++++++++
> 2 files changed, 29 insertions(+)
>
> diff --git a/drivers/hv/mshv_root.h b/drivers/hv/mshv_root.h
> index 4aeb03bea6b6..0cb1e2589fe1 100644
> --- a/drivers/hv/mshv_root.h
> +++ b/drivers/hv/mshv_root.h
> @@ -178,6 +178,7 @@ struct mshv_root {
> struct hv_synic_pages __percpu *synic_pages;
> spinlock_t pt_ht_lock;
> DECLARE_HASHTABLE(pt_htable, MSHV_PARTITIONS_HASH_BITS);
> + struct hv_partition_property_vmm_capabilities vmm_caps;
> };
>
> /*
> diff --git a/drivers/hv/mshv_root_main.c b/drivers/hv/mshv_root_main.c
> index 56ababab57ce..29f61ecc9771 100644
> --- a/drivers/hv/mshv_root_main.c
> +++ b/drivers/hv/mshv_root_main.c
> @@ -2327,6 +2327,28 @@ static int __init mshv_root_partition_init(struct device *dev)
> return err;
> }
>
> +static int mshv_init_vmm_caps(struct device *dev)
> +{
> + int ret;
> +
> + memset(&mshv_root.vmm_caps, 0, sizeof(mshv_root.vmm_caps));
> + ret = hv_call_get_partition_property_ex(HV_PARTITION_ID_SELF,
> + HV_PARTITION_PROPERTY_VMM_CAPABILITIES,
> + 0, &mshv_root.vmm_caps,
> + sizeof(mshv_root.vmm_caps));
> +
> + /*
> + * HV_PARTITION_PROPERTY_VMM_CAPABILITIES is not supported in
> + * older hyperv. Ignore the -EIO error code.
> + */
> + if (ret && ret != -EIO)
> + return ret;
> +
> + dev_dbg(dev, "vmm_caps=0x%llx\n", mshv_root.vmm_caps.as_uint64[0]);
> +
> + return 0;
> +}
> +
> static int __init mshv_parent_partition_init(void)
> {
> int ret;
> @@ -2377,6 +2399,12 @@ static int __init mshv_parent_partition_init(void)
> if (ret)
> goto remove_cpu_state;
>
> + ret = mshv_init_vmm_caps(dev);
> + if (ret) {
> + dev_err(dev, "Failed to get VMM capabilities\n");
> + goto exit_partition;
> + }
> +
> ret = mshv_irqfd_wq_init();
> if (ret)
> goto exit_partition;
Reviewed-by: Praveen K Paladugu <prapal@linux.microsoft.com>
--
Regards,
Praveen K Paladugu
^ permalink raw reply
* Re: [PATCH 3/6] mshv: Add the HVCALL_GET_PARTITION_PROPERTY_EX hypercall
From: Praveen K Paladugu @ 2025-09-05 15:40 UTC (permalink / raw)
To: Nuno Das Neves, linux-hyperv, linux-kernel
Cc: kys, haiyangz, wei.liu, mhklinux, decui, paekkaladevi
In-Reply-To: <1756428230-3599-4-git-send-email-nunodasneves@linux.microsoft.com>
On 8/28/2025 7:43 PM, Nuno Das Neves wrote:
> From: Purna Pavan Chandra Aekkaladevi <paekkaladevi@linux.microsoft.com>
>
> This hypercall can be used to fetch extended properties of a
> partition. Extended properties are properties with values larger than
> a u64. Some of these also need additional input arguments.
>
> Add helper function for using the hypercall in the mshv_root driver.
>
> Signed-off-by: Purna Pavan Chandra Aekkaladevi <paekkaladevi@linux.microsoft.com>
> Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
> ---
> drivers/hv/mshv_root.h | 2 ++
> drivers/hv/mshv_root_hv_call.c | 31 ++++++++++++++++++++++++++
> include/hyperv/hvgdk_mini.h | 1 +
> include/hyperv/hvhdk.h | 40 ++++++++++++++++++++++++++++++++++
> include/hyperv/hvhdk_mini.h | 26 ++++++++++++++++++++++
> 5 files changed, 100 insertions(+)
>
> diff --git a/drivers/hv/mshv_root.h b/drivers/hv/mshv_root.h
> index e3931b0f1269..4aeb03bea6b6 100644
> --- a/drivers/hv/mshv_root.h
> +++ b/drivers/hv/mshv_root.h
> @@ -303,6 +303,8 @@ int hv_call_unmap_stat_page(enum hv_stats_object_type type,
> int hv_call_modify_spa_host_access(u64 partition_id, struct page **pages,
> u64 page_struct_count, u32 host_access,
> u32 flags, u8 acquire);
> +int hv_call_get_partition_property_ex(u64 partition_id, u64 property_code, u64 arg,
> + void *property_value, size_t property_value_sz);
>
> extern struct mshv_root mshv_root;
> extern enum hv_scheduler_type hv_scheduler_type;
> diff --git a/drivers/hv/mshv_root_hv_call.c b/drivers/hv/mshv_root_hv_call.c
> index 1c38576a673c..7589b1ff3515 100644
> --- a/drivers/hv/mshv_root_hv_call.c
> +++ b/drivers/hv/mshv_root_hv_call.c
> @@ -590,6 +590,37 @@ int hv_call_unmap_vp_state_page(u64 partition_id, u32 vp_index, u32 type,
> return hv_result_to_errno(status);
> }
>
> +int
> +hv_call_get_partition_property_ex(u64 partition_id, u64 property_code, u64 arg,
> + void *property_value, size_t property_value_sz)
> +{
> + u64 status;
> + unsigned long flags;
> + struct hv_input_get_partition_property_ex *input;
> + struct hv_output_get_partition_property_ex *output;
> +
> + local_irq_save(flags);
> + input = *this_cpu_ptr(hyperv_pcpu_input_arg);
> + output = *this_cpu_ptr(hyperv_pcpu_output_arg);
> +
> + memset(input, 0, sizeof(*input));
> + input->partition_id = partition_id;
> + input->property_code = property_code;
> + input->arg = arg;
> + status = hv_do_hypercall(HVCALL_GET_PARTITION_PROPERTY_EX, input, output);
> +
> + if (!hv_result_success(status)) {
> + hv_status_debug(status, "\n");
> + local_irq_restore(flags);
> + return hv_result_to_errno(status);
> + }
> + memcpy(property_value, &output->property_value, property_value_sz);
> +
> + local_irq_restore(flags);
> +
> + return 0;
> +}
> +
> int
> hv_call_clear_virtual_interrupt(u64 partition_id)
> {
> diff --git a/include/hyperv/hvgdk_mini.h b/include/hyperv/hvgdk_mini.h
> index 79b7324e4ef5..1bde0aa102ec 100644
> --- a/include/hyperv/hvgdk_mini.h
> +++ b/include/hyperv/hvgdk_mini.h
> @@ -490,6 +490,7 @@ union hv_vp_assist_msr_contents { /* HV_REGISTER_VP_ASSIST_PAGE */
> #define HVCALL_GET_VP_STATE 0x00e3
> #define HVCALL_SET_VP_STATE 0x00e4
> #define HVCALL_GET_VP_CPUID_VALUES 0x00f4
> +#define HVCALL_GET_PARTITION_PROPERTY_EX 0x0101
> #define HVCALL_MMIO_READ 0x0106
> #define HVCALL_MMIO_WRITE 0x0107
>
> diff --git a/include/hyperv/hvhdk.h b/include/hyperv/hvhdk.h
> index 57f3f9c2a685..fd3555def008 100644
> --- a/include/hyperv/hvhdk.h
> +++ b/include/hyperv/hvhdk.h
> @@ -411,6 +411,46 @@ struct hv_input_set_partition_property {
> u64 property_value;
> } __packed;
>
> +union hv_partition_property_arg {
> + u64 as_uint64;
> + struct {
> + union {
> + u32 arg;
> + u32 vp_index;
> + };
> + u16 reserved0;
> + u8 reserved1;
> + u8 object_type;
> + };
> +} __packed;
> +
> +struct hv_input_get_partition_property_ex {
> + u64 partition_id;
> + u32 property_code; /* enum hv_partition_property_code */
> + u32 padding;
> + union {
> + union hv_partition_property_arg arg_data;
> + u64 arg;
> + };
> +} __packed;
> +
> +/*
> + * NOTE: Should use hv_input_set_partition_property_ex_header to compute this
> + * size, but hv_input_get_partition_property_ex is identical so it suffices
> + */
> +#define HV_PARTITION_PROPERTY_EX_MAX_VAR_SIZE \
> + (HV_HYP_PAGE_SIZE - sizeof(struct hv_input_get_partition_property_ex))
> +
> +union hv_partition_property_ex {
> + u8 buffer[HV_PARTITION_PROPERTY_EX_MAX_VAR_SIZE];
> + struct hv_partition_property_vmm_capabilities vmm_capabilities;
> + /* More fields to be filled in when needed */
> +} __packed;
> +
> +struct hv_output_get_partition_property_ex {
> + union hv_partition_property_ex property_value;
> +} __packed;
> +
> enum hv_vp_state_page_type {
> HV_VP_STATE_PAGE_REGISTERS = 0,
> HV_VP_STATE_PAGE_INTERCEPT_MESSAGE = 1,
> diff --git a/include/hyperv/hvhdk_mini.h b/include/hyperv/hvhdk_mini.h
> index 858f6a3925b3..bf2ce27dfcc5 100644
> --- a/include/hyperv/hvhdk_mini.h
> +++ b/include/hyperv/hvhdk_mini.h
> @@ -96,8 +96,34 @@ enum hv_partition_property_code {
> HV_PARTITION_PROPERTY_XSAVE_STATES = 0x00060007,
> HV_PARTITION_PROPERTY_MAX_XSAVE_DATA_SIZE = 0x00060008,
> HV_PARTITION_PROPERTY_PROCESSOR_CLOCK_FREQUENCY = 0x00060009,
> +
> + /* Extended properties with larger property values */
> + HV_PARTITION_PROPERTY_VMM_CAPABILITIES = 0x00090007,
> };
>
> +#define HV_PARTITION_VMM_CAPABILITIES_BANK_COUNT 1
> +#define HV_PARTITION_VMM_CAPABILITIES_RESERVED_BITFIELD_COUNT 59
> +
> +struct hv_partition_property_vmm_capabilities {
> + u16 bank_count;
> + u16 reserved[3];
> + union {
> + u64 as_uint64[HV_PARTITION_VMM_CAPABILITIES_BANK_COUNT];
> + struct {
> + u64 map_gpa_preserve_adjustable: 1;
> + u64 vmm_can_provide_overlay_gpfn: 1;
> + u64 vp_affinity_property: 1;
> +#if IS_ENABLED(CONFIG_ARM64)
> + u64 vmm_can_provide_gic_overlay_locations: 1;
> +#else
> + u64 reservedbit3: 1;
> +#endif
> + u64 assignable_synthetic_proc_features: 1;
> + u64 reserved0: HV_PARTITION_VMM_CAPABILITIES_RESERVED_BITFIELD_COUNT;
> + } __packed;
> + };
> +} __packed;
> +
> enum hv_snp_status {
> HV_SNP_STATUS_NONE = 0,
> HV_SNP_STATUS_AVAILABLE = 1,
Reviewed-by: Praveen K Paladugu <prapal@linux.microsoft.com>
^ permalink raw reply
* Re: [PATCH 2/6] mshv: Ignore second stats page map result failure
From: Praveen K Paladugu @ 2025-09-05 15:31 UTC (permalink / raw)
To: Nuno Das Neves, linux-hyperv, linux-kernel
Cc: kys, haiyangz, wei.liu, mhklinux, decui, paekkaladevi
In-Reply-To: <1756428230-3599-3-git-send-email-nunodasneves@linux.microsoft.com>
On 8/28/2025 7:43 PM, Nuno Das Neves wrote:
> From: Purna Pavan Chandra Aekkaladevi <paekkaladevi@linux.microsoft.com>
>
> Some versions of the hypervisor do not support HV_STATUS_AREA_PARENT and
> return HV_STATUS_INVALID_PARAMETER for the second stats page mapping
> request.
>
Is this behavior limited to VP stats? Or does it extend to other
stats (hypervisor, partition, etc) as well?
> This results a failure in module init. Instead of failing, gracefully
nit: s/This results in a failure during module init/> fall back to
populating stats_pages[HV_STATS_AREA_PARENT] with the
> already-mapped stats_pages[HV_STATS_AREA_SELF].
>
> Signed-off-by: Purna Pavan Chandra Aekkaladevi <paekkaladevi@linux.microsoft.com>
> Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
> ---
> drivers/hv/mshv_root_hv_call.c | 43 ++++++++++++++++++++++++++++++----
> drivers/hv/mshv_root_main.c | 3 +++
> 2 files changed, 42 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/hv/mshv_root_hv_call.c b/drivers/hv/mshv_root_hv_call.c
> index c9c274f29c3c..1c38576a673c 100644
> --- a/drivers/hv/mshv_root_hv_call.c
> +++ b/drivers/hv/mshv_root_hv_call.c
> @@ -724,6 +724,24 @@ hv_call_notify_port_ring_empty(u32 sint_index)
> return hv_result_to_errno(status);
> }
>
> +static int
> +hv_stats_get_area_type(enum hv_stats_object_type type,
> + const union hv_stats_object_identity *identity)
> +{
> + switch (type) {
> + case HV_STATS_OBJECT_HYPERVISOR:
> + return identity->hv.stats_area_type;
> + case HV_STATS_OBJECT_LOGICAL_PROCESSOR:
> + return identity->lp.stats_area_type;
> + case HV_STATS_OBJECT_PARTITION:
> + return identity->partition.stats_area_type;
> + case HV_STATS_OBJECT_VP:
> + return identity->vp.stats_area_type;
> + }
> +
> + return -EINVAL;
> +}
> +
> int hv_call_map_stat_page(enum hv_stats_object_type type,
> const union hv_stats_object_identity *identity,
> void **addr)
> @@ -732,7 +750,7 @@ int hv_call_map_stat_page(enum hv_stats_object_type type,
> struct hv_input_map_stats_page *input;
> struct hv_output_map_stats_page *output;
> u64 status, pfn;
> - int ret = 0;
> + int hv_status, ret = 0;
>
> do {
> local_irq_save(flags);
> @@ -747,11 +765,28 @@ int hv_call_map_stat_page(enum hv_stats_object_type type,
> pfn = output->map_location;
>
> local_irq_restore(flags);
> - if (hv_result(status) != HV_STATUS_INSUFFICIENT_MEMORY) {
> - ret = hv_result_to_errno(status);
> +
> + hv_status = hv_result(status);
> + if (hv_status != HV_STATUS_INSUFFICIENT_MEMORY) {
> if (hv_result_success(status))
> break;
> - return ret;
> +
> + /*
> + * Some versions of the hypervisor do not support the
> + * PARENT stats area. In this case return "success" but
> + * set the page to NULL. The caller checks for this
> + * case instead just uses the SELF area.
> + */
> + if (hv_stats_get_area_type(type, identity) == HV_STATS_AREA_PARENT &&
> + hv_status == HV_STATUS_INVALID_PARAMETER) {
> + pr_debug_once("%s: PARENT area type is unsupported\n",
> + __func__);
> + *addr = NULL;
> + return 0;
> + }
> +
> + hv_status_debug(status, "\n");
> + return hv_result_to_errno(status);
> }
>
> ret = hv_call_deposit_pages(NUMA_NO_NODE,
> diff --git a/drivers/hv/mshv_root_main.c b/drivers/hv/mshv_root_main.c
> index bbdefe8a2e9c..56ababab57ce 100644
> --- a/drivers/hv/mshv_root_main.c
> +++ b/drivers/hv/mshv_root_main.c
> @@ -929,6 +929,9 @@ static int mshv_vp_stats_map(u64 partition_id, u32 vp_index,
> if (err)
> goto unmap_self;
>
> + if (!stats_pages[HV_STATS_AREA_PARENT])
> + stats_pages[HV_STATS_AREA_PARENT] = stats_pages[HV_STATS_AREA_SELF];
> +
> return 0;
>
> unmap_self:
--
Regards,
Praveen K Paladugu
^ permalink raw reply
* Re: [PATCH 1/6] mshv: Only map vp->vp_stats_pages if on root scheduler
From: Praveen K Paladugu @ 2025-09-05 15:20 UTC (permalink / raw)
To: Nuno Das Neves, linux-hyperv, linux-kernel
Cc: kys, haiyangz, wei.liu, mhklinux, decui, paekkaladevi
In-Reply-To: <1756428230-3599-2-git-send-email-nunodasneves@linux.microsoft.com>
On 8/28/2025 7:43 PM, Nuno Das Neves wrote:
> This mapping is only used for checking if the dispatch thread is
> blocked. This is only relevant for the root scheduler, so check the
> scheduler type to determine whether to map/unmap these pages, instead of
> the current check, which is incorrect.
>
> Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
> ---
> drivers/hv/mshv_root_main.c | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/hv/mshv_root_main.c b/drivers/hv/mshv_root_main.c
> index e4ee9beddaf5..bbdefe8a2e9c 100644
> --- a/drivers/hv/mshv_root_main.c
> +++ b/drivers/hv/mshv_root_main.c
> @@ -987,7 +987,11 @@ mshv_partition_ioctl_create_vp(struct mshv_partition *partition,
> goto unmap_register_page;
> }
>
> - if (hv_parent_partition()) {
> + /*
> + * This mapping of the stats page is for detecting if dispatch thread
> + * is blocked - only relevant for root scheduler
> + */
> + if (hv_scheduler_type == HV_SCHEDULER_TYPE_ROOT) {
> ret = mshv_vp_stats_map(partition->pt_id, args.vp_index,
> stats_pages);
> if (ret)
> @@ -1016,7 +1020,7 @@ mshv_partition_ioctl_create_vp(struct mshv_partition *partition,
> if (mshv_partition_encrypted(partition) && is_ghcb_mapping_available())
> vp->vp_ghcb_page = page_to_virt(ghcb_page);
>
> - if (hv_parent_partition())
> + if (hv_scheduler_type == HV_SCHEDULER_TYPE_ROOT)
> memcpy(vp->vp_stats_pages, stats_pages, sizeof(stats_pages));
>
> /*
> @@ -1039,7 +1043,7 @@ mshv_partition_ioctl_create_vp(struct mshv_partition *partition,
> free_vp:
> kfree(vp);
> unmap_stats_pages:
> - if (hv_parent_partition())
> + if (hv_scheduler_type == HV_SCHEDULER_TYPE_ROOT)
> mshv_vp_stats_unmap(partition->pt_id, args.vp_index);
> unmap_ghcb_page:
> if (mshv_partition_encrypted(partition) && is_ghcb_mapping_available()) {
> @@ -1793,7 +1797,7 @@ static void destroy_partition(struct mshv_partition *partition)
> if (!vp)
> continue;
>
> - if (hv_parent_partition())
> + if (hv_scheduler_type == HV_SCHEDULER_TYPE_ROOT)
> mshv_vp_stats_unmap(partition->pt_id, vp->vp_index);
>
> if (vp->vp_register_page) {
Reviewed-by: Praveen K Paladugu <prapal@linux.microsoft.com>
^ permalink raw reply
* Re: [PATCH v4] x86/hyperv: Fix kdump on Azure CVMs
From: Vitaly Kuznetsov @ 2025-09-05 7:48 UTC (permalink / raw)
To: Wei Liu
Cc: linux-hyperv, Michael Kelley, K. Y. Srinivasan, Haiyang Zhang,
Wei Liu, Dexuan Cui, x86, linux-kernel, Nuno Das Neves,
Tianyu Lan, Li Tian, Philipp Rudo
In-Reply-To: <aLoeQXAo5PMDA5hn@liuwe-devbox-ubuntu-v2.lamzopl0uupeniq2etz1fddiyg.xx.internal.cloudapp.net>
Wei Liu <wei.liu@kernel.org> writes:
> On Thu, Aug 28, 2025 at 12:16:18PM +0300, Vitaly Kuznetsov wrote:
>> Azure CVM instance types featuring a paravisor hang upon kdump. The
>> investigation shows that makedumpfile causes a hang when it steps on a page
>> which was previously share with the host
>> (HVCALL_MODIFY_SPARSE_GPA_PAGE_HOST_VISIBILITY). The new kernel has no
>> knowledge of these 'special' regions (which are Vmbus connection pages,
>> GPADL buffers, ...). There are several ways to approach the issue:
>> - Convey the knowledge about these regions to the new kernel somehow.
>> - Unshare these regions before accessing in the new kernel (it is unclear
>> if there's a way to query the status for a given GPA range).
>> - Unshare these regions before jumping to the new kernel (which this patch
>> implements).
>>
>> To make the procedure as robust as possible, store PFN ranges of shared
>> regions in a linked list instead of storing GVAs and re-using
>> hv_vtom_set_host_visibility(). This also allows to avoid memory allocation
>> on the kdump/kexec path.
>>
>> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>
> No fixes tag for this one?
>
Personally, I don't see this as a 'bug', it's rather a missing
feature. In theory, we can add something like
Fixes: 810a52126502 ("x86/hyperv: Add new hvcall guest address host visibility support")
but I'm on the fence whether this is accurate or not.
> Should it be marked as a stable backport?
I think it may make sense even without an explicit 'Fixes:': kdump is the
user's last resort when it comes to kernel crashes and doubly so on
CVMs. Pure kexec may also come handy.
--
Vitaly
^ permalink raw reply
* Re: [PATCH v2 0/7] Drivers: hv: Fix NEED_RESCHED_LAZY and use common APIs
From: Sean Christopherson @ 2025-09-05 5:39 UTC (permalink / raw)
To: Wei Liu
Cc: Marc Zyngier, Oliver Upton, Catalin Marinas, Will Deacon,
Tianrui Zhao, Bibo Mao, Huacai Chen, Anup Patel, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Paolo Bonzini, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, K. Y. Srinivasan,
Haiyang Zhang, Dexuan Cui, Peter Zijlstra, Andy Lutomirski,
Paul E. McKenney, Frederic Weisbecker, Neeraj Upadhyay,
Joel Fernandes, Josh Triplett, Boqun Feng, Uladzislau Rezki,
linux-kernel, linux-arm-kernel, kvmarm, kvm, loongarch, kvm-riscv,
linux-riscv, linux-hyperv, rcu, Nuno Das Neves, Mukesh R
In-Reply-To: <aLojpyTwAMdb1z6D@liuwe-devbox-ubuntu-v2.lamzopl0uupeniq2etz1fddiyg.xx.internal.cloudapp.net>
On Thu, Sep 04, 2025, Wei Liu wrote:
> On Wed, Aug 27, 2025 at 05:01:49PM -0700, Sean Christopherson wrote:
> > Fix a bug where MSHV root partitions (and upper-level VTL code) don't honor
> > NEED_RESCHED_LAZY, and then deduplicate the TIF related MSHV code by turning
> > the "kvm" entry APIs into more generic "virt" APIs.
> >
> > This version is based on
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git hyperv-next
> >
> > in order to pickup the VTL changes that are queued for 6.18. I also
> > squashed the NEED_RESCHED_LAZY fixes for root and VTL modes into a single
> > patch, as it should be easy/straightforward to drop the VTL change as needed
> > if we want this in 6.17 or earlier.
> >
> > That effectively means the full series is dependent on the VTL changes being
> > fully merged for 6.18. But I think that's ok as it's really only the MSHV
> > changes that have any urgency whatsoever, and I assume that Microsoft is
> > the only user that truly cares about the MSHV root fix. I.e. if the whole
> > thing gets delayed, I think it's only the Hyper-V folks that are impacted.
> >
> > I have no preference what tree this goes through, or when, and can respin
> > and/or split as needed.
> >
> > As with v1, the Hyper-V stuff and non-x86 architectures are compile-tested
> > only.
> >
> > v2:
> > - Rebase on hyperv-next.
> > - Fix and converge the VTL code as well. [Peter, Nuno]
> >
> > v1: https://lore.kernel.org/all/20250825200622.3759571-1-seanjc@google.com
> >
>
> I dropped the mshv_vtl changes in this series and applied the rest
> (including the KVM changes) to hyperv-next.
mshv_do_pre_guest_mode_work() ended up getting left behind since its removal was
in the last mshv_vtl patch.
$ git grep mshv_do_pre_guest_mode_work
drivers/hv/mshv.h:int mshv_do_pre_guest_mode_work(ulong th_flags);
drivers/hv/mshv_common.c:int mshv_do_pre_guest_mode_work(ulong th_flags)
drivers/hv/mshv_common.c:EXPORT_SYMBOL_GPL(mshv_do_pre_guest_mode_work);
Want to squash this into 3786d7d6b3c0 ("mshv: Use common "entry virt" APIs to do
work in root before running guest")?
---
drivers/hv/mshv.h | 2 --
drivers/hv/mshv_common.c | 22 ----------------------
2 files changed, 24 deletions(-)
diff --git a/drivers/hv/mshv.h b/drivers/hv/mshv.h
index 0340a67acd0a..d4813df92b9c 100644
--- a/drivers/hv/mshv.h
+++ b/drivers/hv/mshv.h
@@ -25,6 +25,4 @@ int hv_call_set_vp_registers(u32 vp_index, u64 partition_id, u16 count,
int hv_call_get_partition_property(u64 partition_id, u64 property_code,
u64 *property_value);
-int mshv_do_pre_guest_mode_work(ulong th_flags);
-
#endif /* _MSHV_H */
diff --git a/drivers/hv/mshv_common.c b/drivers/hv/mshv_common.c
index eb3df3e296bb..aa2be51979fd 100644
--- a/drivers/hv/mshv_common.c
+++ b/drivers/hv/mshv_common.c
@@ -138,25 +138,3 @@ int hv_call_get_partition_property(u64 partition_id,
return 0;
}
EXPORT_SYMBOL_GPL(hv_call_get_partition_property);
-
-/*
- * Handle any pre-processing before going into the guest mode on this cpu, most
- * notably call schedule(). Must be invoked with both preemption and
- * interrupts enabled.
- *
- * Returns: 0 on success, -errno on error.
- */
-int mshv_do_pre_guest_mode_work(ulong th_flags)
-{
- if (th_flags & (_TIF_SIGPENDING | _TIF_NOTIFY_SIGNAL))
- return -EINTR;
-
- if (th_flags & (_TIF_NEED_RESCHED | _TIF_NEED_RESCHED_LAZY))
- schedule();
-
- if (th_flags & _TIF_NOTIFY_RESUME)
- resume_user_mode_work(NULL);
-
- return 0;
-}
-EXPORT_SYMBOL_GPL(mshv_do_pre_guest_mode_work);
base-commit: 3786d7d6b3c0a412ebe4439ba4a7d4b0e27d9a12
--
^ permalink raw reply related
* RE: [PATCH v3 0/4] drm: Add vblank timers for devices without interrupts
From: Michael Kelley @ 2025-09-05 5:35 UTC (permalink / raw)
To: Thomas Zimmermann, louis.chauvet@bootlin.com,
drawat.floss@gmail.com, hamohammed.sa@gmail.com,
melissa.srw@gmail.com, simona@ffwll.ch, airlied@gmail.com,
maarten.lankhorst@linux.intel.com, ville.syrjala@linux.intel.com,
lyude@redhat.com, javierm@redhat.com
Cc: dri-devel@lists.freedesktop.org, linux-hyperv@vger.kernel.org
In-Reply-To: <20250904145806.430568-1-tzimmermann@suse.de>
From: Thomas Zimmermann <tzimmermann@suse.de> Sent: Thursday, September 4, 2025 7:56 AM
>
> Compositors often depend on vblanks to limit their display-update
> rate. Without, they see vblank events ASAP, which breaks the rate-
> limit feature. This creates high CPU overhead. It is especially a
> problem with virtual devices with fast framebuffer access.
>
> The series moves vkms' vblank timer to DRM and converts the hyperv
> DRM driver. An earlier version of this series contains examples of
> other updated drivers. In principle, any DRM driver without vblank
> hardware can use the timer.
I've tested this patch set in a Hyper-V guest against the linux-next20250829
kernel. All looks good. Results and perf are the same as reported here [4].
So far I haven't seen the "vblank timer overrun" error, which is consistent
with the changes you made since my earlier testing. I'll keep running this
test kernel for a while to see if anything anomalous occurs.
For Patches 1, 2, and 4 of the series on a Hyper-V guest,
Tested-by: Michael Kelley <mhklinux@outlook.com>
[4] https://lore.kernel.org/dri-devel/20250523161522.409504-1-mhklinux@outlook.com/T/#m2e288dddaf7b3c025bbbf88da4b4c39e7aa950a7
>
> The series has been motivated by a recent discussion about hypervdrm [1]
> and other long-standing bug reports. [2][3]
>
> v3:
> - fix deadlock (Ville, Lyude)
> v2:
> - rework interfaces
>
> [1] https://lore.kernel.org/dri-devel/20250523161522.409504-1-mhklinux@outlook.com/T/#ma2ebb52b60bfb0325879349377738fadcd7cb7ef
> [2] https://bugzilla.suse.com/show_bug.cgi?id=1189174
> [3] https://invent.kde.org/plasma/kwin/-/merge_requests/1229#note_284606
>
> Thomas Zimmermann (4):
> drm/vblank: Add vblank timer
> drm/vblank: Add CRTC helpers for simple use cases
> drm/vkms: Convert to DRM's vblank timer
> drm/hypervdrm: Use vblank timer
>
> Documentation/gpu/drm-kms-helpers.rst | 12 ++
> drivers/gpu/drm/Makefile | 3 +-
> drivers/gpu/drm/drm_vblank.c | 161 +++++++++++++++++-
> drivers/gpu/drm/drm_vblank_helper.c | 176 ++++++++++++++++++++
> drivers/gpu/drm/hyperv/hyperv_drm_modeset.c | 11 ++
> drivers/gpu/drm/vkms/vkms_crtc.c | 83 +--------
> drivers/gpu/drm/vkms/vkms_drv.h | 2 -
> include/drm/drm_modeset_helper_vtables.h | 12 ++
> include/drm/drm_vblank.h | 32 ++++
> include/drm/drm_vblank_helper.h | 56 +++++++
> 10 files changed, 467 insertions(+), 81 deletions(-)
> create mode 100644 drivers/gpu/drm/drm_vblank_helper.c
> create mode 100644 include/drm/drm_vblank_helper.h
>
> --
> 2.50.1
^ permalink raw reply
* Re: [PATCH v0 5/6] x86/hyperv: Implement hypervisor ram collection into vmcore
From: Mukesh R @ 2025-09-05 2:38 UTC (permalink / raw)
To: Stanislav Kinsburskii
Cc: linux-hyperv, linux-kernel, linux-arch, kys, haiyangz, wei.liu,
decui, tglx, mingo, bp, dave.hansen, x86, hpa, arnd
In-Reply-To: <aLoUsvfcAqGdV9Qr@skinsburskii.localdomain>
On 9/4/25 15:37, Stanislav Kinsburskii wrote:
> On Wed, Sep 03, 2025 at 07:10:16PM -0700, Mukesh Rathor wrote:
>> This commit introduces a new file to enable collection of hypervisor ram
>> into the vmcore collected by linux. By default, the hypervisor ram is locked,
>> ie, protected via hw page table. Hyper-V implements a disable hypercall which
>> essentially devirtualizes the system on the fly. This mechanism makes the
>> hypervisor ram accessible to linux without any extra work because it is
>> already mapped into linux address space. Details of the implementation
>> are available in the file prologue.
>>
>> Signed-off-by: Mukesh Rathor <mrathor@linux.microsoft.com>
>> ---
>> arch/x86/hyperv/hv_crash.c | 618 +++++++++++++++++++++++++++++++++++++
>> 1 file changed, 618 insertions(+)
>> create mode 100644 arch/x86/hyperv/hv_crash.c
>>
>
> <snip>
>
>> +
>> +/*
>> + * Common function for all cpus before devirtualization.
>> + *
>> + * Hypervisor crash: all cpus get here in nmi context.
>> + * Linux crash: the panicing cpu gets here at base level, all others in nmi
>> + * context. Note, panicing cpu may not be the bsp.
>> + *
>> + * The function is not inlined so it will show on the stack. It is named so
>> + * because the crash cmd looks for certain well known function names on the
>> + * stack before looking into the cpu saved note in the elf section, and
>> + * that work is currently incomplete.
>> + *
>> + * Notes:
>> + * Hypervisor crash:
>> + * - the hypervisor is in a very restrictive mode at this point and any
>> + * vmexit it cannot handle would result in reboot. For example, console
>> + * output from here would result in synic ipi hcall, which would result
>> + * in reboot. So, no mumbo jumbo, just get to kexec as quickly as possible.
>> + *
>> + * Devirtualization is supported from the bsp only.
>> + */
>> +static noinline __noclone void crash_nmi_callback(struct pt_regs *regs)
>> +{
>> + struct hv_input_disable_hyp_ex *input;
>> + u64 status;
>> + int msecs = 1000, ccpu = smp_processor_id();
>> +
>> + if (ccpu == 0) {
>> + /* crash_save_cpu() will be done in the kexec path */
>> + cpu_emergency_stop_pt(); /* disable performance trace */
>> + atomic_inc(&crash_cpus_wait);
>> + } else {
>> + crash_save_cpu(regs, ccpu);
>> + cpu_emergency_stop_pt(); /* disable performance trace */
>> + atomic_inc(&crash_cpus_wait);
>> + for (;;); /* cause no vmexits */
>> + }
>> +
>> + while (atomic_read(&crash_cpus_wait) < num_online_cpus() && msecs--)
>> + mdelay(1);
>> +
>> + stop_nmi();
>> + if (!hv_has_crashed)
>> + hv_notify_prepare_hyp();
>> +
>> + if (crashing_cpu == -1)
>> + crashing_cpu = ccpu; /* crash cmd uses this */
>> +
>> + hv_hvcrash_ctxt_save();
>> + hv_mark_tss_not_busy();
>> + hv_crash_fixup_kernpt();
>> +
>> + input = *this_cpu_ptr(hyperv_pcpu_input_arg);
>> + memset(input, 0, sizeof(*input));
>> + input->rip = trampoline_pa; /* PA of hv_crash_asm32 */
>> + input->arg = devirt_cr3arg; /* PA of trampoline page table L4 */
>> +
>> + status = hv_do_hypercall(HVCALL_DISABLE_HYP_EX, input, NULL);
>> + if (!hv_result_success(status)) {
>> + pr_emerg("%s: %s\n", __func__, hv_result_to_string(status));
>> + pr_emerg("Hyper-V: disable hyp failed. kexec not possible\n");
>
> These prints won't ever be printed to any console as prints in NMI
> handler are deffered.
It's mostly for debug. There are different config options allowing one
to build kernel easily dumping to either uart, led, speaker etc... There
are no easy ways to debug. kernel debuggers could trap EMERGENCY printks
also...
Are you 100% sure printk is async even if KERN_EMERG? If yes, I'd like to
propose someday to make it bypass all that for pr_emerg.
> Also, how are they aligned with the notice in the comment on top of
> the function stating that console output would lead to synic ipi call?
Comment says "Hypervisor Crash". Please reread the whole block.
>> + }
>> +
>> + native_wrmsrq(HV_X64_MSR_RESET, 1); /* get hv to reboot */
>
> Resetting the machine from an NMI handler is sloppy.
> There could be another NMI, which triggers the panic, leading to this handler.
> NMI handlers servicing is batched meanining that not only this handler
> won't output anything, but also any other prints from any other handlers
> executed before the same lock won't be written out to consoles.
>
> This introduces silent machine resets for the root partition. Can the
> intrusive logic me moved to a tasklet?
I really don't think you understand what is going on here. I've tried
telling you at least once in the past year, there is no return from the nmi
handler in case of hyp crash, and that this is panic mode, something
really bad has happened! It could be memory corruption, it could be
hw failure... The hyp goes in emergency mode that just mostly loops,
handling tiny number of hypercalls and msrs for support of dom0/root
like windows that implements custom core collection in raw mode.
Lastly, if disable hyp fails, things are in dire straits and we do last
ditch effort to print in case there is special debug printk or kernel
debugger over serial attached intercepting pr_emerg, or print to LED
for EMERGENCY etc ... before rebooting without hanging.
>> +}
>> +
>> +/*
>> + * generic nmi callback handler: could be called without any crash also.
>> + * hv crash: hypervisor injects nmi's into all cpus
>> + * lx crash: panicing cpu sends nmi to all but self via crash_stop_other_cpus
>> + */
>> +static int hv_crash_nmi_local(unsigned int cmd, struct pt_regs *regs)
>> +{
>> + int ccpu = smp_processor_id();
>> +
>> + if (!hv_has_crashed && hv_cda && hv_cda->cda_valid)
>> + hv_has_crashed = 1;
>> +
>> + if (!hv_has_crashed && !lx_has_crashed)
>> + return NMI_DONE; /* ignore the nmi */
>> +
>> + if (hv_has_crashed && !hv_crash_enabled) {
>> + if (ccpu == 0) {
>> + pr_emerg("Hyper-V: core collect not setup. Reboot\n");
>
> Same here: this print won't reach console.
>
>> + native_wrmsrq(HV_X64_MSR_RESET, 1); /* reboot */
>> + } else
>> + for (;;)
>> + cpu_relax();
>> + }
>> +
>> + crash_nmi_callback(regs);
>> + return NMI_DONE;
>> +}
>> +
>
> <snip>
>
>> +/* Setup for kdump kexec to collect hypervisor ram when running as mshv root */
>> +void hv_root_crash_init(void)
>> +{
>> + int rc;
>> + struct hv_input_get_system_property *input;
>> + struct hv_output_get_system_property *output;
>> + unsigned long flags;
>> + u64 status;
>> + union hv_pfn_range cda_info;
>> +
>> + if (pgtable_l5_enabled()) {
>> + pr_err("Hyper-V: crash dump not yet supported on 5level PTs\n");
>> + goto err_out;
>> + }
>> +
>> + local_irq_save(flags);
>> + input = *this_cpu_ptr(hyperv_pcpu_input_arg);
>> + output = *this_cpu_ptr(hyperv_pcpu_output_arg);
>> +
>> + memset(input, 0, sizeof(*input));
>> + memset(output, 0, sizeof(*output));
>> + input->property_id = HV_SYSTEM_PROPERTY_CRASHDUMPAREA;
>> +
>> + status = hv_do_hypercall(HVCALL_GET_SYSTEM_PROPERTY, input, output);
>> + local_irq_restore(flags);
>> + if (!hv_result_success(status))
>> + goto prop_err_out;
>> +
>> + cda_info.as_uint64 = output->hv_cda_info.as_uint64;
>> +
>> + if (cda_info.base_pfn == 0) {
>> + pr_err("Hyper-V: hypervisor crash dump area pfn is 0\n");
>> + goto err_out;
>> + }
>> +
>> + hv_cda = phys_to_virt(cda_info.base_pfn << PAGE_SHIFT);
>> +
>> + rc = hv_crash_trampoline_setup();
>> + if (rc)
>> + goto err_out;
>> +
>> + register_nmi_handler(NMI_LOCAL, hv_crash_nmi_local, NMI_FLAG_FIRST,
>> + "hv_crash_nmi");
>> +
>
> Rgistering NMI handler can fail and this should be handled.
Not sure if it "should be". There are other instances where this is
not done because the call is guaranteed to be not recursive.
> Stas
>
>> + smp_ops.crash_stop_other_cpus = hv_crash_stop_other_cpus;
>> +
>> + crash_kexec_post_notifiers = true;
>> + hv_crash_enabled = 1;
>> + pr_info("Hyper-V: linux and hv kdump support enabled\n");
>> +
>> + return;
>> +
>> +prop_err_out:
>> + pr_err("Hyper-V: %s: property:%d %s\n", __func__, input->property_id,
>> + hv_result_to_string(status));
>> +err_out:
>> + pr_err("Hyper-V: only linux (but not hv) kdump support enabled\n");
>> +}
>> +
>> --
>> 2.36.1.vfs.0.0
>>
^ permalink raw reply
* Re: [PATCH v3 1/1] x86/hyperv: Switch to msi_create_parent_irq_domain()
From: Wei Liu @ 2025-09-04 23:57 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Nuno Das Neves, Nam Cao, K . Y . Srinivasan, Marc Zyngier,
Haiyang Zhang, Wei Liu, Dexuan Cui, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H . Peter Anvin, linux-hyperv, linux-kernel
In-Reply-To: <87o6rqy1yk.ffs@tglx>
On Thu, Sep 04, 2025 at 11:57:39AM +0200, Thomas Gleixner wrote:
> On Wed, Sep 03 2025 at 12:40, Nuno Das Neves wrote:
> > On 7/18/2025 12:57 PM, Nam Cao wrote:
> >> Move away from the legacy MSI domain setup, switch to use
> >> msi_create_parent_irq_domain().
> >>
> >> While doing the conversion, I noticed that hv_irq_compose_msi_msg() is
> >> doing more than it is supposed to (composing message content). The
> >> interrupt allocation bits should be moved into hv_msi_domain_alloc().
> >> However, I have no hardware to test this change, therefore I leave a TODO
> >> note.
> >>
> >> Signed-off-by: Nam Cao <namcao@linutronix.de>
> >> ---
> >> arch/x86/hyperv/irqdomain.c | 111 ++++++++++++++++++++++++------------
> >> drivers/hv/Kconfig | 1 +
> >> 2 files changed, 77 insertions(+), 35 deletions(-)
> >
> > Tested on nested root partition.
> >
> > Looks good, thanks.
> >
> > Tested-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
> > Reviewed-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
>
> I assume this goes through the hyper-V tree.
>
> Acked-by: Thomas Gleixner <tglx@linutronix.de>
No problem -- applied to hyperv-next.
Thank you Nam and Thomas.
^ permalink raw reply
* Re: [PATCH v2 0/7] Drivers: hv: Fix NEED_RESCHED_LAZY and use common APIs
From: Wei Liu @ 2025-09-04 23:41 UTC (permalink / raw)
To: Sean Christopherson
Cc: Marc Zyngier, Oliver Upton, Catalin Marinas, Will Deacon,
Tianrui Zhao, Bibo Mao, Huacai Chen, Anup Patel, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Paolo Bonzini, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, K. Y. Srinivasan,
Haiyang Zhang, Wei Liu, Dexuan Cui, Peter Zijlstra,
Andy Lutomirski, Paul E. McKenney, Frederic Weisbecker,
Neeraj Upadhyay, Joel Fernandes, Josh Triplett, Boqun Feng,
Uladzislau Rezki, linux-kernel, linux-arm-kernel, kvmarm, kvm,
loongarch, kvm-riscv, linux-riscv, linux-hyperv, rcu,
Nuno Das Neves, Mukesh R
In-Reply-To: <20250828000156.23389-1-seanjc@google.com>
On Wed, Aug 27, 2025 at 05:01:49PM -0700, Sean Christopherson wrote:
> Fix a bug where MSHV root partitions (and upper-level VTL code) don't honor
> NEED_RESCHED_LAZY, and then deduplicate the TIF related MSHV code by turning
> the "kvm" entry APIs into more generic "virt" APIs.
>
> This version is based on
>
> git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git hyperv-next
>
> in order to pickup the VTL changes that are queued for 6.18. I also
> squashed the NEED_RESCHED_LAZY fixes for root and VTL modes into a single
> patch, as it should be easy/straightforward to drop the VTL change as needed
> if we want this in 6.17 or earlier.
>
> That effectively means the full series is dependent on the VTL changes being
> fully merged for 6.18. But I think that's ok as it's really only the MSHV
> changes that have any urgency whatsoever, and I assume that Microsoft is
> the only user that truly cares about the MSHV root fix. I.e. if the whole
> thing gets delayed, I think it's only the Hyper-V folks that are impacted.
>
> I have no preference what tree this goes through, or when, and can respin
> and/or split as needed.
>
> As with v1, the Hyper-V stuff and non-x86 architectures are compile-tested
> only.
>
> v2:
> - Rebase on hyperv-next.
> - Fix and converge the VTL code as well. [Peter, Nuno]
>
> v1: https://lore.kernel.org/all/20250825200622.3759571-1-seanjc@google.com
>
I dropped the mshv_vtl changes in this series and applied the rest
(including the KVM changes) to hyperv-next.
Thanks,
Wei
^ permalink raw reply
* Re: [PATCH v4] x86/hyperv: Fix kdump on Azure CVMs
From: Wei Liu @ 2025-09-04 23:18 UTC (permalink / raw)
To: Vitaly Kuznetsov
Cc: linux-hyperv, Michael Kelley, K. Y. Srinivasan, Haiyang Zhang,
Wei Liu, Dexuan Cui, x86, linux-kernel, Nuno Das Neves,
Tianyu Lan, Li Tian, Philipp Rudo
In-Reply-To: <20250828091618.884950-1-vkuznets@redhat.com>
On Thu, Aug 28, 2025 at 12:16:18PM +0300, Vitaly Kuznetsov wrote:
> Azure CVM instance types featuring a paravisor hang upon kdump. The
> investigation shows that makedumpfile causes a hang when it steps on a page
> which was previously share with the host
> (HVCALL_MODIFY_SPARSE_GPA_PAGE_HOST_VISIBILITY). The new kernel has no
> knowledge of these 'special' regions (which are Vmbus connection pages,
> GPADL buffers, ...). There are several ways to approach the issue:
> - Convey the knowledge about these regions to the new kernel somehow.
> - Unshare these regions before accessing in the new kernel (it is unclear
> if there's a way to query the status for a given GPA range).
> - Unshare these regions before jumping to the new kernel (which this patch
> implements).
>
> To make the procedure as robust as possible, store PFN ranges of shared
> regions in a linked list instead of storing GVAs and re-using
> hv_vtom_set_host_visibility(). This also allows to avoid memory allocation
> on the kdump/kexec path.
>
> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
No fixes tag for this one?
Should it be marked as a stable backport?
Thanks,
Wei
^ permalink raw reply
* Re: [PATCH 1/1] Drivers: hv: Simplify data structures for VMBus channel close message
From: Wei Liu @ 2025-09-04 23:11 UTC (permalink / raw)
To: Tianyu Lan
Cc: mhklinux, haiyangz, wei.liu, decui, kys, linux-kernel,
linux-hyperv, gustavoars
In-Reply-To: <CAMvTesBGma=mXDvY=3aqp0k3A3LQt1y7gnMLrD4CqJ1WW1dPSA@mail.gmail.com>
On Mon, Sep 01, 2025 at 01:56:17AM +0800, Tianyu Lan wrote:
> On Mon, Sep 1, 2025 at 12:06 AM <mhkelley58@gmail.com> wrote:
> >
> > From: Michael Kelley <mhklinux@outlook.com>
> >
> > struct vmbus_close_msg is used for sending the VMBus channel close
> > message. It contains a struct vmbus_channel_msginfo, which has a
> > flex array member at the end. The latter's presence in the middle
> > of struct vmbus_close_msg causes warnings when built with
> > -Wflex-array-member-not-at-end.
> >
> > But the struct vmbus_channel_msginfo is unused because the Hyper-V host
> > does not send a response to the channel close message. So remove the
> > struct vmbus_channel_msginfo. Then, since the only remaining field is
> > struct vmbus_channel_close_channel, also remove the containing struct
> > vmbus_close_msg and directly use struct vmbus_channel_close_channel.
> > Besides eliminating unnecessary complexity, these changes resolve the
> > -Wflex-array-member-not-at-end warnings.
> >
> > Signed-off-by: Michael Kelley <mhklinux@outlook.com>
> > ---
>
> Reviewed-by: Tianyu Lan <tiala@microsoft.com>
Applied. Thanks.
^ permalink raw reply
* Re: [PATCH v2] Drivers: hv: util: Cosmetic changes for hv_utils_transport.c
From: Wei Liu @ 2025-09-04 23:10 UTC (permalink / raw)
To: Abhishek Tiwari
Cc: abhitiwari, kys, haiyangz, wei.liu, decui, linux-hyperv,
linux-kernel, ssengar
In-Reply-To: <1756728000-8324-1-git-send-email-abhitiwari@linux.microsoft.com>
On Mon, Sep 01, 2025 at 05:00:00AM -0700, Abhishek Tiwari wrote:
> Fix issues reported by checkpatch.pl script for hv_utils_transport.c file
> - Update pr_warn() calls to use __func__ for consistent logging context.
> - else should follow close brace '}'
>
> No functional changes intended.
>
> Signed-off-by: Abhishek Tiwari <abhitiwari@linux.microsoft.com>
> Reviewed-by: Naman Jain <namjain@linux.microsoft.com>
Applied. Thanks.
^ permalink raw reply
* Re: [PATCH v2] mshv: Add support for a new parent partition configuration
From: Wei Liu @ 2025-09-04 23:07 UTC (permalink / raw)
To: Nuno Das Neves
Cc: linux-hyperv, linux-kernel, linux-arch, wei.liu, mhklinux, kys,
haiyangz, decui, arnd
In-Reply-To: <1756856913-27197-1-git-send-email-nunodasneves@linux.microsoft.com>
On Tue, Sep 02, 2025 at 04:48:33PM -0700, Nuno Das Neves wrote:
> Detect booting as an "L1VH" partition. This is a new scenario very
> similar to root partition where the mshv_root driver can be used to
> create and manage guest partitions.
>
> It mostly works the same as root partition, but there are some
> differences in how various features are handled. hv_l1vh_partition()
> is introduced to handle these cases. Add hv_parent_partition()
> which returns true for either case, replacing some hv_root_partition()
> checks.
>
> Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
> Acked-by: Wei Liu <wei.liu@kernel.org>
> Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Applied. Thanks.
^ permalink raw reply
* Re: [PATCH v0 5/6] x86/hyperv: Implement hypervisor ram collection into vmcore
From: Stanislav Kinsburskii @ 2025-09-04 22:37 UTC (permalink / raw)
To: Mukesh Rathor
Cc: linux-hyperv, linux-kernel, linux-arch, kys, haiyangz, wei.liu,
decui, tglx, mingo, bp, dave.hansen, x86, hpa, arnd
In-Reply-To: <20250904021017.1628993-6-mrathor@linux.microsoft.com>
On Wed, Sep 03, 2025 at 07:10:16PM -0700, Mukesh Rathor wrote:
> This commit introduces a new file to enable collection of hypervisor ram
> into the vmcore collected by linux. By default, the hypervisor ram is locked,
> ie, protected via hw page table. Hyper-V implements a disable hypercall which
> essentially devirtualizes the system on the fly. This mechanism makes the
> hypervisor ram accessible to linux without any extra work because it is
> already mapped into linux address space. Details of the implementation
> are available in the file prologue.
>
> Signed-off-by: Mukesh Rathor <mrathor@linux.microsoft.com>
> ---
> arch/x86/hyperv/hv_crash.c | 618 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 618 insertions(+)
> create mode 100644 arch/x86/hyperv/hv_crash.c
>
<snip>
> +
> +/*
> + * Common function for all cpus before devirtualization.
> + *
> + * Hypervisor crash: all cpus get here in nmi context.
> + * Linux crash: the panicing cpu gets here at base level, all others in nmi
> + * context. Note, panicing cpu may not be the bsp.
> + *
> + * The function is not inlined so it will show on the stack. It is named so
> + * because the crash cmd looks for certain well known function names on the
> + * stack before looking into the cpu saved note in the elf section, and
> + * that work is currently incomplete.
> + *
> + * Notes:
> + * Hypervisor crash:
> + * - the hypervisor is in a very restrictive mode at this point and any
> + * vmexit it cannot handle would result in reboot. For example, console
> + * output from here would result in synic ipi hcall, which would result
> + * in reboot. So, no mumbo jumbo, just get to kexec as quickly as possible.
> + *
> + * Devirtualization is supported from the bsp only.
> + */
> +static noinline __noclone void crash_nmi_callback(struct pt_regs *regs)
> +{
> + struct hv_input_disable_hyp_ex *input;
> + u64 status;
> + int msecs = 1000, ccpu = smp_processor_id();
> +
> + if (ccpu == 0) {
> + /* crash_save_cpu() will be done in the kexec path */
> + cpu_emergency_stop_pt(); /* disable performance trace */
> + atomic_inc(&crash_cpus_wait);
> + } else {
> + crash_save_cpu(regs, ccpu);
> + cpu_emergency_stop_pt(); /* disable performance trace */
> + atomic_inc(&crash_cpus_wait);
> + for (;;); /* cause no vmexits */
> + }
> +
> + while (atomic_read(&crash_cpus_wait) < num_online_cpus() && msecs--)
> + mdelay(1);
> +
> + stop_nmi();
> + if (!hv_has_crashed)
> + hv_notify_prepare_hyp();
> +
> + if (crashing_cpu == -1)
> + crashing_cpu = ccpu; /* crash cmd uses this */
> +
> + hv_hvcrash_ctxt_save();
> + hv_mark_tss_not_busy();
> + hv_crash_fixup_kernpt();
> +
> + input = *this_cpu_ptr(hyperv_pcpu_input_arg);
> + memset(input, 0, sizeof(*input));
> + input->rip = trampoline_pa; /* PA of hv_crash_asm32 */
> + input->arg = devirt_cr3arg; /* PA of trampoline page table L4 */
> +
> + status = hv_do_hypercall(HVCALL_DISABLE_HYP_EX, input, NULL);
> + if (!hv_result_success(status)) {
> + pr_emerg("%s: %s\n", __func__, hv_result_to_string(status));
> + pr_emerg("Hyper-V: disable hyp failed. kexec not possible\n");
These prints won't ever be printed to any console as prints in NMI
handler are deffered.
Also, how are they aligned with the notice in the comment on top of
the function stating that console output would lead to synic ipi call?
> + }
> +
> + native_wrmsrq(HV_X64_MSR_RESET, 1); /* get hv to reboot */
Resetting the machine from an NMI handler is sloppy.
There could be another NMI, which triggers the panic, leading to this handler.
NMI handlers servicing is batched meanining that not only this handler
won't output anything, but also any other prints from any other handlers
executed before the same lock won't be written out to consoles.
This introduces silent machine resets for the root partition. Can the
intrusive logic me moved to a tasklet?
> +}
> +
> +/*
> + * generic nmi callback handler: could be called without any crash also.
> + * hv crash: hypervisor injects nmi's into all cpus
> + * lx crash: panicing cpu sends nmi to all but self via crash_stop_other_cpus
> + */
> +static int hv_crash_nmi_local(unsigned int cmd, struct pt_regs *regs)
> +{
> + int ccpu = smp_processor_id();
> +
> + if (!hv_has_crashed && hv_cda && hv_cda->cda_valid)
> + hv_has_crashed = 1;
> +
> + if (!hv_has_crashed && !lx_has_crashed)
> + return NMI_DONE; /* ignore the nmi */
> +
> + if (hv_has_crashed && !hv_crash_enabled) {
> + if (ccpu == 0) {
> + pr_emerg("Hyper-V: core collect not setup. Reboot\n");
Same here: this print won't reach console.
> + native_wrmsrq(HV_X64_MSR_RESET, 1); /* reboot */
> + } else
> + for (;;)
> + cpu_relax();
> + }
> +
> + crash_nmi_callback(regs);
> + return NMI_DONE;
> +}
> +
<snip>
> +/* Setup for kdump kexec to collect hypervisor ram when running as mshv root */
> +void hv_root_crash_init(void)
> +{
> + int rc;
> + struct hv_input_get_system_property *input;
> + struct hv_output_get_system_property *output;
> + unsigned long flags;
> + u64 status;
> + union hv_pfn_range cda_info;
> +
> + if (pgtable_l5_enabled()) {
> + pr_err("Hyper-V: crash dump not yet supported on 5level PTs\n");
> + goto err_out;
> + }
> +
> + local_irq_save(flags);
> + input = *this_cpu_ptr(hyperv_pcpu_input_arg);
> + output = *this_cpu_ptr(hyperv_pcpu_output_arg);
> +
> + memset(input, 0, sizeof(*input));
> + memset(output, 0, sizeof(*output));
> + input->property_id = HV_SYSTEM_PROPERTY_CRASHDUMPAREA;
> +
> + status = hv_do_hypercall(HVCALL_GET_SYSTEM_PROPERTY, input, output);
> + local_irq_restore(flags);
> + if (!hv_result_success(status))
> + goto prop_err_out;
> +
> + cda_info.as_uint64 = output->hv_cda_info.as_uint64;
> +
> + if (cda_info.base_pfn == 0) {
> + pr_err("Hyper-V: hypervisor crash dump area pfn is 0\n");
> + goto err_out;
> + }
> +
> + hv_cda = phys_to_virt(cda_info.base_pfn << PAGE_SHIFT);
> +
> + rc = hv_crash_trampoline_setup();
> + if (rc)
> + goto err_out;
> +
> + register_nmi_handler(NMI_LOCAL, hv_crash_nmi_local, NMI_FLAG_FIRST,
> + "hv_crash_nmi");
> +
Rgistering NMI handler can fail and this should be handled.
Stas
> + smp_ops.crash_stop_other_cpus = hv_crash_stop_other_cpus;
> +
> + crash_kexec_post_notifiers = true;
> + hv_crash_enabled = 1;
> + pr_info("Hyper-V: linux and hv kdump support enabled\n");
> +
> + return;
> +
> +prop_err_out:
> + pr_err("Hyper-V: %s: property:%d %s\n", __func__, input->property_id,
> + hv_result_to_string(status));
> +err_out:
> + pr_err("Hyper-V: only linux (but not hv) kdump support enabled\n");
> +}
> +
> --
> 2.36.1.vfs.0.0
>
^ permalink raw reply
* Re: [PATCH V0 0/2] Fix CONFIG_HYPERV and vmbus related anamoly
From: Mukesh R @ 2025-09-04 18:18 UTC (permalink / raw)
To: Michael Kelley, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
linux-hyperv@vger.kernel.org, netdev@vger.kernel.org,
linux-pci@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-fbdev@vger.kernel.org, linux-arch@vger.kernel.org,
virtualization@lists.linux.dev
Cc: maarten.lankhorst@linux.intel.com, mripard@kernel.org,
tzimmermann@suse.de, airlied@gmail.com, simona@ffwll.ch,
jikos@kernel.org, bentiss@kernel.org, kys@microsoft.com,
haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com,
dmitry.torokhov@gmail.com, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, bhelgaas@google.com,
James.Bottomley@HansenPartnership.com, martin.petersen@oracle.com,
gregkh@linuxfoundation.org, deller@gmx.de, arnd@arndb.de,
sgarzare@redhat.com, horms@kernel.org
In-Reply-To: <SN6PR02MB41573C5451F21286667C5441D400A@SN6PR02MB4157.namprd02.prod.outlook.com>
On 9/4/25 09:26, Michael Kelley wrote:
> From: Mukesh R <mrathor@linux.microsoft.com> Sent: Wednesday, September 3, 2025 7:17 PM
>>
>> On 9/2/25 07:42, Michael Kelley wrote:
>>> From: Mukesh Rathor <mrathor@linux.microsoft.com> Sent: Wednesday, August 27, 2025 6:00 PM
>>>>
>>>> At present, drivers/Makefile will subst =m to =y for CONFIG_HYPERV for hv
>>>> subdir. Also, drivers/hv/Makefile replaces =m to =y to build in
>>>> hv_common.c that is needed for the drivers. Moreover, vmbus driver is
>>>> built if CONFIG_HYPER is set, either loadable or builtin.
>>>>
>>>> This is not a good approach. CONFIG_HYPERV is really an umbrella config that
>>>> encompasses builtin code and various other things and not a dedicated config
>>>> option for VMBUS. Vmbus should really have a config option just like
>>>> CONFIG_HYPERV_BALLOON etc. This small series introduces CONFIG_HYPERV_VMBUS
>>>> to build VMBUS driver and make that distinction explicit. With that
>>>> CONFIG_HYPERV could be changed to bool.
>>>
>>> Separating the core hypervisor support (CONFIG_HYPERV) from the VMBus
>>> support (CONFIG_HYPERV_VMBUS) makes sense to me. Overall the code
>>> is already mostly in separate source files code, though there's some
>>> entanglement in the handling of VMBus interrupts, which could be
>>> improved later.
>>>
>>> However, I have a compatibility concern. Consider this scenario:
>>>
>>> 1) Assume running in a Hyper-V VM with a current Linux kernel version
>>> built with CONFIG_HYPERV=m.
>>> 2) Grab a new version of kernel source code that contains this patch set.
>>> 3) Run 'make olddefconfig' to create the .config file for the new kernel.
>>> 4) Build the new kernel. This succeeds.
>>> 5) Install and run the new kernel in the Hyper-V VM. This fails.
>>>
>>> The failure occurs because CONFIG_HYPERV=m is no longer legal,
>>> so the .config file created in Step 3 has CONFIG_HYPERV=n. The
>>> newly built kernel has no Hyper-V support and won't run in a
>>> Hyper-V VM.
>>>
>>> As a second issue, if in Step 1 the current kernel was built with
>>> CONFIG_HYPERV=y, then the .config file for the new kernel will have
>>> CONFIG_HYPERV=y, which is better. But CONFIG_HYPERV_VMBUS
>>> defaults to 'n', so the new kernel doesn't have any VMBus drivers
>>> and won't run in a typical Hyper-V VM.
>>>
>>> The second issue could be fixed by assigning CONFIG_HYPERV_VMBUS
>>> a default value, such as whatever CONFIG_HYPERV is set to. But
>>> I'm not sure how to fix the first issue, except by continuing to
>>> allow CONFIG_HYPERV=m.
>>
>> To certain extent, imo, users are expected to check config files
>> for changes when moving to new versions/releases, so it would be a
>> one time burden.
>
> I'm not so sanguine about the impact. For those of us who work with
> Hyper-V frequently, yes, it's probably not that big of an issue -- we can
> figure it out. But a lot of Azure/Hyper-V users aren't that familiar with
> the details of how the Kconfig files are put together. And the issue occurs
> with no error messages that something has gone wrong in building
> the kernel, except that it won't boot. Just running "make olddefconfig"
> has worked in the past, so some users will be befuddled and end up
> generating Azure support incidents. I also wonder about breaking
> automated test suites for new kernels, as they are likely to be running
> "make olddefconfig" or something similar as part of the automation.
>
>> CONFIG_HYPERV=m is just broken imo as one sees that
>> in .config but magically symbols in drivers/hv are in kerenel.
>>
>
> I agree that's not ideal. But note that some Hyper-V code and symbols
> like ms_hyperv_init_platform() and related functions show up when
> CONFIG_HYPERVISOR_GUEST=y, even if CONFIG_HYPERV=n. That's
> the code in arch/x86/kernel/cpu/mshyperv.c and it's because Hyper-V
> is one of the recognized and somewhat hardwired hypervisors (like
> VMware, for example).
>
> Finally, there are about a dozen other places in the kernel that use
> the same Makefile construct to make some code built-in even though
> the CONFIG option is set to "m". That may not be enough occurrences
> to make it standard practice, but Hyper-V guests are certainly not the
> only case.
>
> In my mind, this is judgment call with no absolute right answer. What
> do others think about the tradeoffs?
Wei had said in private message that he agrees this is a good idea. Nuno
said earlier above:
"FWIW I think it's a good idea, interested to hear what others think."
Thanks,
-Mukesh
^ permalink raw reply
* Re: [PATCH v0 1/6] x86/hyperv: Rename guest shutdown functions
From: Anirudh Rayabharam @ 2025-09-04 17:22 UTC (permalink / raw)
To: Mukesh Rathor
Cc: linux-hyperv, linux-kernel, linux-arch, kys, haiyangz, wei.liu,
decui, tglx, mingo, bp, dave.hansen, x86, hpa, arnd
In-Reply-To: <20250904021017.1628993-2-mrathor@linux.microsoft.com>
On Wed, Sep 03, 2025 at 07:10:12PM -0700, Mukesh Rathor wrote:
> This commit renames hv_machine_crash_shutdown to more appropriate
https://www.kernel.org/doc/html/latest/process/submitting-patches.html
Please describe your changes in imperative mood. For e.g.:
“make xyzzy do frotz” instead of “[This patch] makes xyzzy do frotz”
Please fix this for all the patches in this series.
Thanks,
Anirudh.
> hv_guest_crash_shutdown and makes it applicable to guests only. This
> in preparation for the subsequent hypervisor root/dom0 crash support
> patches.
>
> Signed-off-by: Mukesh Rathor <mrathor@linux.microsoft.com>
> ---
> arch/x86/kernel/cpu/mshyperv.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
> index b8caf78c4336..f5d76d854d39 100644
> --- a/arch/x86/kernel/cpu/mshyperv.c
> +++ b/arch/x86/kernel/cpu/mshyperv.c
> @@ -237,7 +237,7 @@ static void hv_machine_shutdown(void)
> #endif /* CONFIG_KEXEC_CORE */
>
> #ifdef CONFIG_CRASH_DUMP
> -static void hv_machine_crash_shutdown(struct pt_regs *regs)
> +static void hv_guest_crash_shutdown(struct pt_regs *regs)
> {
> if (hv_crash_handler)
> hv_crash_handler(regs);
> @@ -824,7 +824,8 @@ static void __init ms_hyperv_init_platform(void)
> machine_ops.shutdown = hv_machine_shutdown;
> #endif
> #if defined(CONFIG_CRASH_DUMP)
> - machine_ops.crash_shutdown = hv_machine_crash_shutdown;
> + if (!hv_root_partition)
> + machine_ops.crash_shutdown = hv_guest_crash_shutdown;
> #endif
> #endif
> /*
> --
> 2.36.1.vfs.0.0
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox