* Re: [PATCH 2/6] mshv: Ignore second stats page map result failure
From: Easwar Hariharan @ 2025-09-08 17:22 UTC (permalink / raw)
To: Nuno Das Neves
Cc: easwar.hariharan, linux-hyperv, linux-kernel, kys, haiyangz,
wei.liu, mhklinux, decui, paekkaladevi
In-Reply-To: <874a2370-84f1-4cec-bb06-a13fe11b49ca@linux.microsoft.com>
On 9/8/2025 10:04 AM, Nuno Das Neves wrote:
> On 9/5/2025 12:21 PM, Easwar Hariharan wrote:
>> 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.
>>
> This is going out of scope of this series a bit but I'll explain briefly.
>
> When we do add the code to expose these stats to userspace, the SELF and
> PARENT pages won't be exposed separately, there is no duplication.
>
> For each stat counter in the page, we'll expose either the SELF or PARENT
> value, depending on whether there is anything in that slot (whether it's zero
> or not).
>
> Some stats are available via the SELF page, and some via the PARENT page, but
> the counters in the page have the same layout. So some counters in the SELF
> page will all stay zero while on the PARENT page they are updated, and vice
> versa.
>
> I believe the hypervisor takes this strange approach for the purpose of
> backward compatibility. Introducing L1VH created the need for this SELF/PARENT
> distinction.
>
> Hope that makes some kind of sense...it will be clearer when we post the mshv
> debugfs code itself.
>
> To put it another way, falling back to the SELF page won't cause any impact
> to userspace because the distinction between the pages is all handled in the
> driver, and we only read each stat value from either SELF or PARENT.
>
> Nuno
Thank you for that explanation, it sorta makes sense.
I think it'd be better if this patch is part of the series that exposes the stats
to userspace, so that it can be reviewed in context with the rest of the code in
the driver that manages the pick-and-choose of a stat value from the SELF/PARENT
page.
Unless there's an active problem now in the upstream kernel that this patch solves?
i.e. are the versions of the hypervisor that don't support the PARENT stats
page available in the wild?
Thanks,
Easwar (he/him)
^ permalink raw reply
* Re: [PATCH 2/6] mshv: Ignore second stats page map result failure
From: Nuno Das Neves @ 2025-09-08 17:04 UTC (permalink / raw)
To: Easwar Hariharan
Cc: linux-hyperv, linux-kernel, kys, haiyangz, wei.liu, mhklinux,
decui, paekkaladevi
In-Reply-To: <efc78065-3556-410a-866f-961a7f1fc1ac@linux.microsoft.com>
On 9/5/2025 12:21 PM, Easwar Hariharan wrote:
> 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.
>
This is going out of scope of this series a bit but I'll explain briefly.
When we do add the code to expose these stats to userspace, the SELF and
PARENT pages won't be exposed separately, there is no duplication.
For each stat counter in the page, we'll expose either the SELF or PARENT
value, depending on whether there is anything in that slot (whether it's zero
or not).
Some stats are available via the SELF page, and some via the PARENT page, but
the counters in the page have the same layout. So some counters in the SELF
page will all stay zero while on the PARENT page they are updated, and vice
versa.
I believe the hypervisor takes this strange approach for the purpose of
backward compatibility. Introducing L1VH created the need for this SELF/PARENT
distinction.
Hope that makes some kind of sense...it will be clearer when we post the mshv
debugfs code itself.
To put it another way, falling back to the SELF page won't cause any impact
to userspace because the distinction between the pages is all handled in the
driver, and we only read each stat value from either SELF or PARENT.
Nuno
>>
>> 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 6/6] mshv: Introduce new hypercall to map stats page for L1VH partitions
From: Easwar Hariharan @ 2025-09-08 16:26 UTC (permalink / raw)
To: Nuno Das Neves
Cc: easwar.hariharan, linux-hyperv, linux-kernel, kys, haiyangz,
wei.liu, mhklinux, decui, paekkaladevi, Jinank Jain
In-Reply-To: <15532d34-0005-4cba-9fca-212c30db1f18@linux.microsoft.com>
On 9/5/2025 4:12 PM, Nuno Das Neves wrote:
> On 9/5/2025 12:50 PM, Easwar Hariharan wrote:
>> On 8/28/2025 5:43 PM, Nuno Das Neves wrote:
>>> From: Jinank Jain <jinankjain@linux.microsoft.com>
>>>
>>> Introduce HVCALL_MAP_STATS_PAGE2 which provides a map location (GPFN)
>>> to map the stats to. This hypercall is required for L1VH partitions,
>>> depending on the hypervisor version. This uses the same check as the
>>> state page map location; mshv_use_overlay_gpfn().
>>>
>>> Add mshv_map_vp_state_page() helpers to use this new hypercall or the
>>> old one depending on availability.
>>>
>>> For unmapping, the original HVCALL_UNMAP_STATS_PAGE works for both
>>> cases.
>>>
>>> Signed-off-by: Jinank Jain <jinankjain@linux.microsoft.com>
>>> Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
>>> ---
>>> drivers/hv/mshv_root.h | 10 ++--
>>> drivers/hv/mshv_root_hv_call.c | 92 ++++++++++++++++++++++++++++++++--
>>> drivers/hv/mshv_root_main.c | 25 +++++----
>>> include/hyperv/hvgdk_mini.h | 1 +
>>> include/hyperv/hvhdk_mini.h | 7 +++
>>> 5 files changed, 115 insertions(+), 20 deletions(-)
>>>
<snip>
>>
>> Shouldn't this be in the previous patch where the other hv_call_map_stat_page() calls were
>> converted, same below?
>>
> The previous patch converts hv_call_(un)map_vp_state_page to hv_(un)map_vp_state_page, i.e.
> "state" not "stats".
>
Ugh, thanks for the catch. I guess my eyes glazed over a little bit with the diffs.
Thanks,
Easwar (he/him)
^ permalink raw reply
* Re: [PATCH v0 5/6] x86/hyperv: Implement hypervisor ram collection into vmcore
From: Stanislav Kinsburskii @ 2025-09-08 16:21 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
>
> diff --git a/arch/x86/hyperv/hv_crash.c b/arch/x86/hyperv/hv_crash.c
> new file mode 100644
> index 000000000000..50c54d39f0e2
> --- /dev/null
> +++ b/arch/x86/hyperv/hv_crash.c
> +
<snip>
> +/*
> + * 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");
> + native_wrmsrq(HV_X64_MSR_RESET, 1); /* reboot */
> + } else
> + for (;;)
> + cpu_relax();
> + }
> +
> + crash_nmi_callback(regs);
> + return NMI_DONE;
> +}
One more thing.
It looks like the function above goes through the new logic even when
hypervisor is intact and there is no crash kernel loaded.
This is redundant and it should rather return back to the existent
generic kernel panic logic.
Stanislav
^ permalink raw reply
* Re: [PATCH net] net/mlx5: Not returning mlx5_link_info table when speed is unknown
From: Tariq Toukan @ 2025-09-08 12:43 UTC (permalink / raw)
To: Vitaly Kuznetsov, Li Tian, netdev, linux-hyperv
Cc: Saeed Mahameed, Tariq Toukan, Mark Bloch, Leon Romanovsky,
Haiyang Zhang, Benjamin Poirier, Carolina Jubran, Shahar Shitrit
In-Reply-To: <877by9fep2.fsf@redhat.com>
On 08/09/2025 12:58, Vitaly Kuznetsov wrote:
> Li Tian <litian@redhat.com> writes:
>
>> Because mlx5e_link_mode is sparse e.g. Azure mlx5 reports PTYS 19.
>> Do not return it when speed unless retrieved successfully.
>>
>> Fixes: 65a5d35571849 ("net/mlx5: Refactor link speed handling with mlx5_link_info struct")
++
Adding author and reviewer of offending patch.
>> Suggested-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>> Signed-off-by: Li Tian <litian@redhat.com>
>> ---
>> drivers/net/ethernet/mellanox/mlx5/core/port.c | 6 +++++-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/port.c b/drivers/net/ethernet/mellanox/mlx5/core/port.c
>> index 2d7adf7444ba..a69c83da2542 100644
>> --- a/drivers/net/ethernet/mellanox/mlx5/core/port.c
>> +++ b/drivers/net/ethernet/mellanox/mlx5/core/port.c
>> @@ -1170,7 +1170,11 @@ const struct mlx5_link_info *mlx5_port_ptys2info(struct mlx5_core_dev *mdev,
>> mlx5e_port_get_link_mode_info_arr(mdev, &table, &max_size,
>> force_legacy);
>> i = find_first_bit(&temp, max_size);
>> - if (i < max_size)
Keep an empty line before comment.
>> + /*
Can have the comment text starting from the first line.
>> + * mlx5e_link_mode is sparse. Check speed
>
> The array is either 'mlx5e_link_mode' or 'mlx5e_ext_link_info' but both
> have holes in them.
>
You mean 'mlx5e_link_info' and 'mlx5e_ext_link_info'.
I wouldn't say they are sparse. They have holes indeed.
>> + * is non-zero as indication of a hole.
>> + */
>> + if (i < max_size && table[i].speed)
>> return &table[i];
>>
>> return NULL;
>
^ permalink raw reply
* Re: [PATCH net] net/mlx5: Not returning mlx5_link_info table when speed is unknown
From: Vitaly Kuznetsov @ 2025-09-08 9:58 UTC (permalink / raw)
To: Li Tian, netdev, linux-hyperv
Cc: Saeed Mahameed, Tariq Toukan, Mark Bloch, Leon Romanovsky,
Haiyang Zhang, Benjamin Poirier
In-Reply-To: <20250908085313.18768-1-litian@redhat.com>
Li Tian <litian@redhat.com> writes:
> Because mlx5e_link_mode is sparse e.g. Azure mlx5 reports PTYS 19.
> Do not return it when speed unless retrieved successfully.
>
> Fixes: 65a5d35571849 ("net/mlx5: Refactor link speed handling with mlx5_link_info struct")
> Suggested-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> Signed-off-by: Li Tian <litian@redhat.com>
> ---
> drivers/net/ethernet/mellanox/mlx5/core/port.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/port.c b/drivers/net/ethernet/mellanox/mlx5/core/port.c
> index 2d7adf7444ba..a69c83da2542 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/port.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/port.c
> @@ -1170,7 +1170,11 @@ const struct mlx5_link_info *mlx5_port_ptys2info(struct mlx5_core_dev *mdev,
> mlx5e_port_get_link_mode_info_arr(mdev, &table, &max_size,
> force_legacy);
> i = find_first_bit(&temp, max_size);
> - if (i < max_size)
> + /*
> + * mlx5e_link_mode is sparse. Check speed
The array is either 'mlx5e_link_mode' or 'mlx5e_ext_link_info' but both
have holes in them.
> + * is non-zero as indication of a hole.
> + */
> + if (i < max_size && table[i].speed)
> return &table[i];
>
> return NULL;
--
Vitaly
^ permalink raw reply
* [PATCH net] net/mlx5: Not returning mlx5_link_info table when speed is unknown
From: Li Tian @ 2025-09-08 8:53 UTC (permalink / raw)
To: netdev, linux-hyperv
Cc: Saeed Mahameed, Tariq Toukan, Mark Bloch, Leon Romanovsky,
Haiyang Zhang, Benjamin Poirier, Vitaly Kuznetsov
Because mlx5e_link_mode is sparse e.g. Azure mlx5 reports PTYS 19.
Do not return it when speed unless retrieved successfully.
Fixes: 65a5d35571849 ("net/mlx5: Refactor link speed handling with mlx5_link_info struct")
Suggested-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Li Tian <litian@redhat.com>
---
drivers/net/ethernet/mellanox/mlx5/core/port.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/port.c b/drivers/net/ethernet/mellanox/mlx5/core/port.c
index 2d7adf7444ba..a69c83da2542 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/port.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/port.c
@@ -1170,7 +1170,11 @@ const struct mlx5_link_info *mlx5_port_ptys2info(struct mlx5_core_dev *mdev,
mlx5e_port_get_link_mode_info_arr(mdev, &table, &max_size,
force_legacy);
i = find_first_bit(&temp, max_size);
- if (i < max_size)
+ /*
+ * mlx5e_link_mode is sparse. Check speed
+ * is non-zero as indication of a hole.
+ */
+ if (i < max_size && table[i].speed)
return &table[i];
return NULL;
--
2.50.0
^ permalink raw reply related
* Re: [PATCH] PCI: hv: Remove unused parameter of hv_msi_free()
From: Manivannan Sadhasivam @ 2025-09-08 5:01 UTC (permalink / raw)
To: K . Y . Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui,
Lorenzo Pieralisi, Krzysztof Wilczyński, Rob Herring,
Bjorn Helgaas, linux-hyperv, linux-pci, linux-kernel, Nam Cao
In-Reply-To: <20250813055350.1670245-1-namcao@linutronix.de>
On Wed, 13 Aug 2025 07:53:50 +0200, Nam Cao wrote:
> The 'info' parameter of hv_msi_free() is unused. Delete it.
>
>
Applied, thanks!
[1/1] PCI: hv: Remove unused parameter of hv_msi_free()
commit: ce47f81925ed73f9d27b1a01f07afdb031949c68
Best regards,
--
Manivannan Sadhasivam <mani@kernel.org>
^ permalink raw reply
* Re: [PATCH 4/6] mshv: Get the vmm capabilities offered by the hypervisor
From: Tianyu Lan @ 2025-09-06 17:34 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 Fri, Aug 29, 2025 at 8:44 AM Nuno Das Neves
<nunodasneves@linux.microsoft.com> 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>
> ---
Reviewed-by: Tianyu Lan <tiala@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;
> --
> 2.34.1
>
>
--
Thanks
Tianyu Lan
^ permalink raw reply
* Re: [PATCH 2/6] mshv: Ignore second stats page map result failure
From: Tianyu Lan @ 2025-09-06 17:30 UTC (permalink / raw)
To: Nuno Das Neves
Cc: linux-hyperv, linux-kernel, kys, haiyangz, wei.liu, mhklinux,
decui, paekkaladevi
In-Reply-To: <1756428230-3599-3-git-send-email-nunodasneves@linux.microsoft.com>
On Fri, Aug 29, 2025 at 8:44 AM Nuno Das Neves
<nunodasneves@linux.microsoft.com> 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].
>
> 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(-)
>
Reviewed-by: Tianyu Lan <tiala@microsoft.com>
> 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:
> --
> 2.34.1
>
>
--
Thanks
Tianyu Lan
^ permalink raw reply
* Re: [PATCH v1 2/2] Drivers: hv: Make CONFIG_HYPERV bool
From: Greg KH @ 2025-09-06 11:36 UTC (permalink / raw)
To: Mukesh Rathor
Cc: dri-devel, linux-kernel, linux-input, linux-hyperv, netdev,
linux-pci, linux-scsi, linux-fbdev, linux-arch, virtualization,
maarten.lankhorst, mripard, tzimmermann, airlied, simona, jikos,
bentiss, kys, haiyangz, wei.liu, decui, dmitry.torokhov,
andrew+netdev, davem, edumazet, kuba, pabeni, bhelgaas,
James.Bottomley, martin.petersen, deller, arnd, sgarzare, horms
In-Reply-To: <20250906010952.2145389-3-mrathor@linux.microsoft.com>
On Fri, Sep 05, 2025 at 06:09:52PM -0700, Mukesh Rathor wrote:
> With CONFIG_HYPERV and CONFIG_HYPERV_VMBUS separated, change CONFIG_HYPERV
> to bool from tristate. CONFIG_HYPERV now becomes the core Hyper-V
> hypervisor support, such as hypercalls, clocks/timers, Confidential
> Computing setup, PCI passthru, etc. that doesn't involve VMBus or VMBus
> devices.
But why are you making it so that this can not be a module anymore? You
are now forcing ALL Linux distro users to always have this code in their
system, despite not ever using the feature. That feels like a waste to
me.
What is preventing this from staying as a module? Why must you always
have this code loaded at all times for everyone?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 1/6] mshv: Only map vp->vp_stats_pages if on root scheduler
From: Tianyu Lan @ 2025-09-06 7:11 UTC (permalink / raw)
To: Nuno Das Neves
Cc: linux-hyperv, linux-kernel, kys, haiyangz, wei.liu, mhklinux,
decui, paekkaladevi
In-Reply-To: <1756428230-3599-2-git-send-email-nunodasneves@linux.microsoft.com>
On Fri, Aug 29, 2025 at 9:08 AM Nuno Das Neves
<nunodasneves@linux.microsoft.com> 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) {
> --
> 2.34.1
>
>
Reviewed-by: Tianyu Lan <tiala@microsoft.com>
--
Thanks
Tianyu Lan
^ permalink raw reply
* [PATCH v1 2/2] Drivers: hv: Make CONFIG_HYPERV bool
From: Mukesh Rathor @ 2025-09-06 1:09 UTC (permalink / raw)
To: dri-devel, linux-kernel, linux-input, linux-hyperv, netdev,
linux-pci, linux-scsi, linux-fbdev, linux-arch, virtualization
Cc: maarten.lankhorst, mripard, tzimmermann, airlied, simona, jikos,
bentiss, kys, haiyangz, wei.liu, decui, dmitry.torokhov,
andrew+netdev, davem, edumazet, kuba, pabeni, bhelgaas,
James.Bottomley, martin.petersen, gregkh, deller, arnd, sgarzare,
horms
In-Reply-To: <20250906010952.2145389-1-mrathor@linux.microsoft.com>
With CONFIG_HYPERV and CONFIG_HYPERV_VMBUS separated, change CONFIG_HYPERV
to bool from tristate. CONFIG_HYPERV now becomes the core Hyper-V
hypervisor support, such as hypercalls, clocks/timers, Confidential
Computing setup, PCI passthru, etc. that doesn't involve VMBus or VMBus
devices.
Signed-off-by: Mukesh Rathor <mrathor@linux.microsoft.com>
---
drivers/Makefile | 2 +-
drivers/hv/Kconfig | 2 +-
drivers/hv/Makefile | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/Makefile b/drivers/Makefile
index b5749cf67044..7ad5744db0b6 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -161,7 +161,7 @@ obj-$(CONFIG_SOUNDWIRE) += soundwire/
# Virtualization drivers
obj-$(CONFIG_VIRT_DRIVERS) += virt/
-obj-$(subst m,y,$(CONFIG_HYPERV)) += hv/
+obj-$(CONFIG_HYPERV) += hv/
obj-$(CONFIG_PM_DEVFREQ) += devfreq/
obj-$(CONFIG_EXTCON) += extcon/
diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
index fe29f8dca2b5..7e56c51c5080 100644
--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -3,7 +3,7 @@
menu "Microsoft Hyper-V guest support"
config HYPERV
- tristate "Microsoft Hyper-V client drivers"
+ bool "Microsoft Hyper-V core hypervisor support"
depends on (X86 && X86_LOCAL_APIC && HYPERVISOR_GUEST) \
|| (ARM64 && !CPU_BIG_ENDIAN)
select PARAVIRT
diff --git a/drivers/hv/Makefile b/drivers/hv/Makefile
index 050517756a82..8b04a33e4dd8 100644
--- a/drivers/hv/Makefile
+++ b/drivers/hv/Makefile
@@ -18,7 +18,7 @@ mshv_root-y := mshv_root_main.o mshv_synic.o mshv_eventfd.o mshv_irq.o \
mshv_vtl-y := mshv_vtl_main.o
# Code that must be built-in
-obj-$(subst m,y,$(CONFIG_HYPERV)) += hv_common.o
+obj-$(CONFIG_HYPERV) += hv_common.o
obj-$(subst m,y,$(CONFIG_MSHV_ROOT)) += hv_proc.o
ifneq ($(CONFIG_MSHV_ROOT) $(CONFIG_MSHV_VTL),)
obj-y += mshv_common.o
--
2.36.1.vfs.0.0
^ permalink raw reply related
* [PATCH v1 1/2] Driver: hv: Add CONFIG_HYPERV_VMBUS option
From: Mukesh Rathor @ 2025-09-06 1:09 UTC (permalink / raw)
To: dri-devel, linux-kernel, linux-input, linux-hyperv, netdev,
linux-pci, linux-scsi, linux-fbdev, linux-arch, virtualization
Cc: maarten.lankhorst, mripard, tzimmermann, airlied, simona, jikos,
bentiss, kys, haiyangz, wei.liu, decui, dmitry.torokhov,
andrew+netdev, davem, edumazet, kuba, pabeni, bhelgaas,
James.Bottomley, martin.petersen, gregkh, deller, arnd, sgarzare,
horms
In-Reply-To: <20250906010952.2145389-1-mrathor@linux.microsoft.com>
At present VMBus driver is hinged off of CONFIG_HYPERV which entails
lot of builtin code and encompasses too much. It's not always clear
what depends on builtin hv code and what depends on VMBus. Setting
CONFIG_HYPERV as a module and fudging the Makefile to switch to builtin
adds even more confusion. VMBus is an independent module and should have
its own config option. Also, there are scenarios like baremetal dom0/root
where support is built in with CONFIG_HYPERV but without VMBus. Lastly,
there are more features coming down that use CONFIG_HYPERV and add more
dependencies on it.
So, create a fine grained HYPERV_VMBUS option and update Kconfigs for
dependency on VMBus.
Signed-off-by: Mukesh Rathor <mrathor@linux.microsoft.com>
---
drivers/gpu/drm/Kconfig | 2 +-
drivers/hid/Kconfig | 2 +-
drivers/hv/Kconfig | 13 ++++++++++---
drivers/hv/Makefile | 2 +-
drivers/input/serio/Kconfig | 4 ++--
drivers/net/hyperv/Kconfig | 2 +-
drivers/pci/Kconfig | 2 +-
drivers/scsi/Kconfig | 2 +-
drivers/uio/Kconfig | 2 +-
drivers/video/fbdev/Kconfig | 2 +-
include/asm-generic/mshyperv.h | 8 +++++---
net/vmw_vsock/Kconfig | 2 +-
12 files changed, 26 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index f7ea8e895c0c..58f34da061c6 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -398,7 +398,7 @@ source "drivers/gpu/drm/imagination/Kconfig"
config DRM_HYPERV
tristate "DRM Support for Hyper-V synthetic video device"
- depends on DRM && PCI && HYPERV
+ depends on DRM && PCI && HYPERV_VMBUS
select DRM_CLIENT_SELECTION
select DRM_KMS_HELPER
select DRM_GEM_SHMEM_HELPER
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index a57901203aeb..fe3dc8c0db99 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -1162,7 +1162,7 @@ config GREENASIA_FF
config HID_HYPERV_MOUSE
tristate "Microsoft Hyper-V mouse driver"
- depends on HYPERV
+ depends on HYPERV_VMBUS
help
Select this option to enable the Hyper-V mouse driver.
diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
index 2e8df09db599..fe29f8dca2b5 100644
--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -44,18 +44,25 @@ config HYPERV_TIMER
config HYPERV_UTILS
tristate "Microsoft Hyper-V Utilities driver"
- depends on HYPERV && CONNECTOR && NLS
+ depends on HYPERV_VMBUS && CONNECTOR && NLS
depends on PTP_1588_CLOCK_OPTIONAL
help
Select this option to enable the Hyper-V Utilities.
config HYPERV_BALLOON
tristate "Microsoft Hyper-V Balloon driver"
- depends on HYPERV
+ depends on HYPERV_VMBUS
select PAGE_REPORTING
help
Select this option to enable Hyper-V Balloon driver.
+config HYPERV_VMBUS
+ tristate "Microsoft Hyper-V VMBus driver"
+ depends on HYPERV
+ default HYPERV
+ help
+ Select this option to enable Hyper-V Vmbus driver.
+
config MSHV_ROOT
tristate "Microsoft Hyper-V root partition support"
depends on HYPERV && (X86_64 || ARM64)
@@ -75,7 +82,7 @@ config MSHV_ROOT
config MSHV_VTL
tristate "Microsoft Hyper-V VTL driver"
- depends on X86_64 && HYPERV_VTL_MODE
+ depends on X86_64 && HYPERV_VTL_MODE && HYPERV_VMBUS
# Mapping VTL0 memory to a userspace process in VTL2 is supported in OpenHCL.
# VTL2 for OpenHCL makes use of Huge Pages to improve performance on VMs,
# specially with large memory requirements.
diff --git a/drivers/hv/Makefile b/drivers/hv/Makefile
index c53a0df746b7..050517756a82 100644
--- a/drivers/hv/Makefile
+++ b/drivers/hv/Makefile
@@ -1,5 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
-obj-$(CONFIG_HYPERV) += hv_vmbus.o
+obj-$(CONFIG_HYPERV_VMBUS) += hv_vmbus.o
obj-$(CONFIG_HYPERV_UTILS) += hv_utils.o
obj-$(CONFIG_HYPERV_BALLOON) += hv_balloon.o
obj-$(CONFIG_MSHV_ROOT) += mshv_root.o
diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig
index 17edc1597446..c7ef347a4dff 100644
--- a/drivers/input/serio/Kconfig
+++ b/drivers/input/serio/Kconfig
@@ -276,8 +276,8 @@ config SERIO_OLPC_APSP
config HYPERV_KEYBOARD
tristate "Microsoft Synthetic Keyboard driver"
- depends on HYPERV
- default HYPERV
+ depends on HYPERV_VMBUS
+ default HYPERV_VMBUS
help
Select this option to enable the Hyper-V Keyboard driver.
diff --git a/drivers/net/hyperv/Kconfig b/drivers/net/hyperv/Kconfig
index c8cbd85adcf9..982964c1a9fb 100644
--- a/drivers/net/hyperv/Kconfig
+++ b/drivers/net/hyperv/Kconfig
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
config HYPERV_NET
tristate "Microsoft Hyper-V virtual network driver"
- depends on HYPERV
+ depends on HYPERV_VMBUS
select UCS2_STRING
select NLS
help
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 9a249c65aedc..7065a8e5f9b1 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -221,7 +221,7 @@ config PCI_LABEL
config PCI_HYPERV
tristate "Hyper-V PCI Frontend"
- depends on ((X86 && X86_64) || ARM64) && HYPERV && PCI_MSI && SYSFS
+ depends on ((X86 && X86_64) || ARM64) && HYPERV_VMBUS && PCI_MSI && SYSFS
select PCI_HYPERV_INTERFACE
select IRQ_MSI_LIB
help
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 5522310bab8d..19d0884479a2 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -589,7 +589,7 @@ config XEN_SCSI_FRONTEND
config HYPERV_STORAGE
tristate "Microsoft Hyper-V virtual storage driver"
- depends on SCSI && HYPERV
+ depends on SCSI && HYPERV_VMBUS
depends on m || SCSI_FC_ATTRS != m
default HYPERV
help
diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index b060dcd7c635..6f86a61231e6 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -140,7 +140,7 @@ config UIO_MF624
config UIO_HV_GENERIC
tristate "Generic driver for Hyper-V VMBus"
- depends on HYPERV
+ depends on HYPERV_VMBUS
help
Generic driver that you can bind, dynamically, to any
Hyper-V VMBus device. It is useful to provide direct access
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index c21484d15f0c..72c63eaeb983 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1774,7 +1774,7 @@ config FB_BROADSHEET
config FB_HYPERV
tristate "Microsoft Hyper-V Synthetic Video support"
- depends on FB && HYPERV
+ depends on FB && HYPERV_VMBUS
select DMA_CMA if HAVE_DMA_CONTIGUOUS && CMA
select FB_IOMEM_HELPERS_DEFERRED
help
diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyperv.h
index 1d2ad1304ad4..66c58c91b530 100644
--- a/include/asm-generic/mshyperv.h
+++ b/include/asm-generic/mshyperv.h
@@ -165,6 +165,7 @@ static inline u64 hv_generate_guest_id(u64 kernel_version)
void __init hv_mark_resources(void);
+#if IS_ENABLED(CONFIG_HYPERV_VMBUS)
/* Free the message slot and signal end-of-message if required */
static inline void vmbus_signal_eom(struct hv_message *msg, u32 old_msg_type)
{
@@ -200,6 +201,10 @@ static inline void vmbus_signal_eom(struct hv_message *msg, u32 old_msg_type)
}
}
+extern int vmbus_interrupt;
+extern int vmbus_irq;
+#endif /* CONFIG_HYPERV_VMBUS */
+
int hv_get_hypervisor_version(union hv_hypervisor_version_info *info);
void hv_setup_vmbus_handler(void (*handler)(void));
@@ -213,9 +218,6 @@ void hv_setup_crash_handler(void (*handler)(struct pt_regs *regs));
void hv_remove_crash_handler(void);
void hv_setup_mshv_handler(void (*handler)(void));
-extern int vmbus_interrupt;
-extern int vmbus_irq;
-
#if IS_ENABLED(CONFIG_HYPERV)
/*
* Hypervisor's notion of virtual processor ID is different from
diff --git a/net/vmw_vsock/Kconfig b/net/vmw_vsock/Kconfig
index 56356d2980c8..8e803c4828c4 100644
--- a/net/vmw_vsock/Kconfig
+++ b/net/vmw_vsock/Kconfig
@@ -72,7 +72,7 @@ config VIRTIO_VSOCKETS_COMMON
config HYPERV_VSOCKETS
tristate "Hyper-V transport for Virtual Sockets"
- depends on VSOCKETS && HYPERV
+ depends on VSOCKETS && HYPERV_VMBUS
help
This module implements a Hyper-V transport for Virtual Sockets.
--
2.36.1.vfs.0.0
^ permalink raw reply related
* [PATCH v1 0/2] Fix CONFIG_HYPERV and vmbus related anamoly
From: Mukesh Rathor @ 2025-09-06 1:09 UTC (permalink / raw)
To: dri-devel, linux-kernel, linux-input, linux-hyperv, netdev,
linux-pci, linux-scsi, linux-fbdev, linux-arch, virtualization
Cc: maarten.lankhorst, mripard, tzimmermann, airlied, simona, jikos,
bentiss, kys, haiyangz, wei.liu, decui, dmitry.torokhov,
andrew+netdev, davem, edumazet, kuba, pabeni, bhelgaas,
James.Bottomley, martin.petersen, gregkh, deller, arnd, sgarzare,
horms
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.
For now, hv_common.c is left as is to reduce conflicts for upcoming
patches, but once merges are mostly done, that and some others should
be moved to virt/hyperv directory.
V1:
o Change subject from hyper-v to "Drivers: hv:"
o Rewrite commit messages paying attention to VMBus and not vmbus
o Change some wordings in Kconfig
o Make new VMBUS config option default to HYPERV option for a smoother
transition
Mukesh Rathor (2):
Driver: hv: Add CONFIG_HYPERV_VMBUS option
Drivers: hv: Make CONFIG_HYPERV bool
drivers/Makefile | 2 +-
drivers/gpu/drm/Kconfig | 2 +-
drivers/hid/Kconfig | 2 +-
drivers/hv/Kconfig | 15 +++++++++++----
drivers/hv/Makefile | 4 ++--
drivers/input/serio/Kconfig | 4 ++--
drivers/net/hyperv/Kconfig | 2 +-
drivers/pci/Kconfig | 2 +-
drivers/scsi/Kconfig | 2 +-
drivers/uio/Kconfig | 2 +-
drivers/video/fbdev/Kconfig | 2 +-
include/asm-generic/mshyperv.h | 8 +++++---
net/vmw_vsock/Kconfig | 2 +-
13 files changed, 29 insertions(+), 20 deletions(-)
--
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-06 0:34 UTC (permalink / raw)
To: Nuno Das Neves, 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: <6a26cbf8-7877-4f39-0ed3-7bbc306f9fe5@linux.microsoft.com>
On 9/5/25 14:41, Mukesh R wrote:
> On 9/5/25 13:08, Nuno Das Neves wrote:
>> On 9/4/2025 11:18 AM, Mukesh R wrote:
>>> 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.
>>
>> It surprises me a little that =m doesn't get 'fixed up' to =y in this case.
>> I guess any invalid value turns to =n, which makes sense most of the time.
>>
>>>>>>
>>>>>> 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.
>>
>> I'm wondering, is there a path for this change, then? Are there some
>> intermediate step/s we could take to minimize the problem?
>>
>>>>>
>>>>> 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."
>>>
>> That was before Michael pointed out the potential issues which I was
>> unaware of. Let's see if there's a path that is smoother for all the
>> downstream users who may be compiling with CONFIG_HYPERV=m.
>
> Ok, we've already thought of it for sometime and not able to come up
> with any. IMO, it's a minor hickup, not major. This is stalling
> upcoming iommu and other patches which will use CONFIG_HYPERV and
> add more dependencies, and it would be much harder to straighten
> out then. So I hope you guys can come up with some solution sooner than
> later, I can't think of any.
Played around a bit, setting it to "default HYPERV" like Michael suggested
gives it a default value of y. I thought it fail if one is bool and other
is tristate. So that should help with transition.
Thanks,
-Mukesh
^ permalink raw reply
* Re: [PATCH 3/6] mshv: Add the HVCALL_GET_PARTITION_PROPERTY_EX hypercall
From: Nuno Das Neves @ 2025-09-05 23:13 UTC (permalink / raw)
To: Easwar Hariharan
Cc: linux-hyperv, linux-kernel, kys, haiyangz, wei.liu, mhklinux,
decui, paekkaladevi
In-Reply-To: <daa0202d-3f9e-42eb-a356-2a1ac08e69d2@linux.microsoft.com>
On 9/5/2025 12:28 PM, Easwar Hariharan wrote:
> 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..
Ack, thanks>
> <snip>
>
> Thanks,
> Easwar (he/him)
^ permalink raw reply
* Re: [PATCH 6/6] mshv: Introduce new hypercall to map stats page for L1VH partitions
From: Nuno Das Neves @ 2025-09-05 23:12 UTC (permalink / raw)
To: Easwar Hariharan
Cc: linux-hyperv, linux-kernel, kys, haiyangz, wei.liu, mhklinux,
decui, paekkaladevi, Jinank Jain
In-Reply-To: <ed4ebc67-dc98-4ce4-af5e-b2f371d27c5b@linux.microsoft.com>
On 9/5/2025 12:50 PM, Easwar Hariharan wrote:
> On 8/28/2025 5:43 PM, Nuno Das Neves wrote:
>> From: Jinank Jain <jinankjain@linux.microsoft.com>
>>
>> Introduce HVCALL_MAP_STATS_PAGE2 which provides a map location (GPFN)
>> to map the stats to. This hypercall is required for L1VH partitions,
>> depending on the hypervisor version. This uses the same check as the
>> state page map location; mshv_use_overlay_gpfn().
>>
>> Add mshv_map_vp_state_page() helpers to use this new hypercall or the
>> old one depending on availability.
>>
>> For unmapping, the original HVCALL_UNMAP_STATS_PAGE works for both
>> cases.
>>
>> Signed-off-by: Jinank Jain <jinankjain@linux.microsoft.com>
>> Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
>> ---
>> drivers/hv/mshv_root.h | 10 ++--
>> drivers/hv/mshv_root_hv_call.c | 92 ++++++++++++++++++++++++++++++++--
>> drivers/hv/mshv_root_main.c | 25 +++++----
>> include/hyperv/hvgdk_mini.h | 1 +
>> include/hyperv/hvhdk_mini.h | 7 +++
>> 5 files changed, 115 insertions(+), 20 deletions(-)
>>
>> diff --git a/drivers/hv/mshv_root.h b/drivers/hv/mshv_root.h
>> index d7c9520ef788..d16a020ae0ee 100644
>> --- a/drivers/hv/mshv_root.h
>> +++ b/drivers/hv/mshv_root.h
>> @@ -297,11 +297,11 @@ int hv_call_connect_port(u64 port_partition_id, union hv_port_id port_id,
>> int hv_call_disconnect_port(u64 connection_partition_id,
>> union hv_connection_id connection_id);
>> int hv_call_notify_port_ring_empty(u32 sint_index);
>> -int hv_call_map_stat_page(enum hv_stats_object_type type,
>> - const union hv_stats_object_identity *identity,
>> - void **addr);
>> -int hv_call_unmap_stat_page(enum hv_stats_object_type type,
>> - const union hv_stats_object_identity *identity);
>> +int hv_map_stats_page(enum hv_stats_object_type type,
>> + const union hv_stats_object_identity *identity,
>> + void **addr);
>> +int hv_unmap_stats_page(enum hv_stats_object_type type, void *page_addr,
>> + const union hv_stats_object_identity *identity);
>> int hv_call_modify_spa_host_access(u64 partition_id, struct page **pages,
>> u64 page_struct_count, u32 host_access,
>> u32 flags, u8 acquire);
>> diff --git a/drivers/hv/mshv_root_hv_call.c b/drivers/hv/mshv_root_hv_call.c
>> index 1882cc90f2f5..44013751cfc1 100644
>> --- a/drivers/hv/mshv_root_hv_call.c
>> +++ b/drivers/hv/mshv_root_hv_call.c
>> @@ -804,6 +804,45 @@ hv_call_notify_port_ring_empty(u32 sint_index)
>> return hv_result_to_errno(status);
>> }
>>
>> +static int
>> +hv_call_map_stats_page2(enum hv_stats_object_type type,
>
> Again, one line please. Also below.
>
Ack
>> + const union hv_stats_object_identity *identity,
>> + u64 map_location)
>> +{
>> + unsigned long flags;
>> + struct hv_input_map_stats_page2 *input;
>> + u64 status;
>> + int ret;
>> +
>> + if (!map_location || !mshv_use_overlay_gpfn())
>> + return -EINVAL;
>> +
>> + do {
>> + local_irq_save(flags);
>> + input = *this_cpu_ptr(hyperv_pcpu_input_arg);
>> +
>> + memset(input, 0, sizeof(*input));
>> + input->type = type;
>> + input->identity = *identity;
>> + input->map_location = map_location;
>> +
>> + status = hv_do_hypercall(HVCALL_MAP_STATS_PAGE2, input, NULL);
>> +
>> + local_irq_restore(flags);
>> + if (hv_result(status) != HV_STATUS_INSUFFICIENT_MEMORY) {
>> + if (hv_result_success(status))
>> + break;
>> + hv_status_debug(status, "\n");
>> + return hv_result_to_errno(status);
>> + }
>> +
>> + ret = hv_call_deposit_pages(NUMA_NO_NODE,
>> + hv_current_partition_id, 1);
>> + } while (!ret);
>> +
>> + return ret;
>> +}
>> +
>> static int
>> hv_stats_get_area_type(enum hv_stats_object_type type,
>> const union hv_stats_object_identity *identity)
>> @@ -822,9 +861,10 @@ hv_stats_get_area_type(enum hv_stats_object_type type,
>> return -EINVAL;
>> }
>>
>> -int hv_call_map_stat_page(enum hv_stats_object_type type,
>> - const union hv_stats_object_identity *identity,
>> - void **addr)
>> +static int
>> +hv_call_map_stats_page(enum hv_stats_object_type type,
>> + const union hv_stats_object_identity *identity,
>> + void **addr)
>
> ...
>
ack
>> {
>> unsigned long flags;
>> struct hv_input_map_stats_page *input;
>> @@ -880,8 +920,37 @@ int hv_call_map_stat_page(enum hv_stats_object_type type,
>> return ret;
>> }
>>
>> -int hv_call_unmap_stat_page(enum hv_stats_object_type type,
>> - const union hv_stats_object_identity *identity)
>> +int hv_map_stats_page(enum hv_stats_object_type type,
>> + const union hv_stats_object_identity *identity,
>> + void **addr)
>> +{
>> + int ret;
>> + struct page *allocated_page = NULL;
>> +
>> + if (!addr)
>> + return -EINVAL;
>> +
>> + if (mshv_use_overlay_gpfn()) {
>> + allocated_page = alloc_page(GFP_KERNEL);
>> + if (!allocated_page)
>> + return -ENOMEM;
>> +
>> + ret = hv_call_map_stats_page2(type, identity,
>> + page_to_pfn(allocated_page));
>> + *addr = page_address(allocated_page);
>> + } else {
>> + ret = hv_call_map_stats_page(type, identity, addr);
>> + }
>> +
>> + if (ret && allocated_page)
>> + __free_page(allocated_page);
>> +
>> + return ret;
>> +}
>> +
>> +static int
>> +hv_call_unmap_stats_page(enum hv_stats_object_type type,
>
> ...
>
ack
>> + const union hv_stats_object_identity *identity)
>> {
>> unsigned long flags;
>> struct hv_input_unmap_stats_page *input;
>> @@ -900,6 +969,19 @@ int hv_call_unmap_stat_page(enum hv_stats_object_type type,
>> return hv_result_to_errno(status);
>> }
>>
>> +int hv_unmap_stats_page(enum hv_stats_object_type type, void *page_addr,
>> + const union hv_stats_object_identity *identity)
>> +{
>> + int ret;
>> +
>> + ret = hv_call_unmap_stats_page(type, identity);
>> +
>> + if (mshv_use_overlay_gpfn() && page_addr)
>> + __free_page(virt_to_page(page_addr));
>> +
>> + return ret;
>> +}
>> +
>> int hv_call_modify_spa_host_access(u64 partition_id, struct page **pages,
>> u64 page_struct_count, u32 host_access,
>> u32 flags, u8 acquire)
>> diff --git a/drivers/hv/mshv_root_main.c b/drivers/hv/mshv_root_main.c
>> index f91880cc9e29..1699423cc524 100644
>> --- a/drivers/hv/mshv_root_main.c
>> +++ b/drivers/hv/mshv_root_main.c
>> @@ -894,7 +894,8 @@ mshv_vp_release(struct inode *inode, struct file *filp)
>> return 0;
>> }
>>
>> -static void mshv_vp_stats_unmap(u64 partition_id, u32 vp_index)
>> +static void mshv_vp_stats_unmap(u64 partition_id, u32 vp_index,
>> + void *stats_pages[])
>> {
>> union hv_stats_object_identity identity = {
>> .vp.partition_id = partition_id,
>> @@ -902,10 +903,13 @@ static void mshv_vp_stats_unmap(u64 partition_id, u32 vp_index)
>> };
>>
>> identity.vp.stats_area_type = HV_STATS_AREA_SELF;
>> - hv_call_unmap_stat_page(HV_STATS_OBJECT_VP, &identity);
>> + hv_unmap_stats_page(HV_STATS_OBJECT_VP, NULL, &identity);
>> +
>> + if (stats_pages[HV_STATS_AREA_PARENT] == stats_pages[HV_STATS_AREA_SELF])
>> + return;
>>
>> identity.vp.stats_area_type = HV_STATS_AREA_PARENT;
>> - hv_call_unmap_stat_page(HV_STATS_OBJECT_VP, &identity);
>> + hv_unmap_stats_page(HV_STATS_OBJECT_VP, NULL, &identity);
>> }
>>
>> static int mshv_vp_stats_map(u64 partition_id, u32 vp_index,
>> @@ -918,14 +922,14 @@ static int mshv_vp_stats_map(u64 partition_id, u32 vp_index,
>> int err;
>>
>> identity.vp.stats_area_type = HV_STATS_AREA_SELF;
>> - err = hv_call_map_stat_page(HV_STATS_OBJECT_VP, &identity,
>> - &stats_pages[HV_STATS_AREA_SELF]);
>> + err = hv_map_stats_page(HV_STATS_OBJECT_VP, &identity,
>> + &stats_pages[HV_STATS_AREA_SELF]);
>
> Shouldn't this be in the previous patch where the other hv_call_map_stat_page() calls were
> converted, same below?
>
The previous patch converts hv_call_(un)map_vp_state_page to hv_(un)map_vp_state_page, i.e.
"state" not "stats".
>> if (err)
>> return err;
>>
>> identity.vp.stats_area_type = HV_STATS_AREA_PARENT;
>> - err = hv_call_map_stat_page(HV_STATS_OBJECT_VP, &identity,
>> - &stats_pages[HV_STATS_AREA_PARENT]);
>> + err = hv_map_stats_page(HV_STATS_OBJECT_VP, &identity,
>> + &stats_pages[HV_STATS_AREA_PARENT]);
>
> ...
>
>> if (err)
>> goto unmap_self;
>>
>> @@ -936,7 +940,7 @@ static int mshv_vp_stats_map(u64 partition_id, u32 vp_index,
>>
>> unmap_self:
>> identity.vp.stats_area_type = HV_STATS_AREA_SELF;
>> - hv_call_unmap_stat_page(HV_STATS_OBJECT_VP, &identity);
>> + hv_unmap_stats_page(HV_STATS_OBJECT_VP, NULL, &identity);
>> return err;
>> }
>>
>
> <snip>
^ permalink raw reply
* Re: [PATCH 4/6] mshv: Get the vmm capabilities offered by the hypervisor
From: Nuno Das Neves @ 2025-09-05 23:07 UTC (permalink / raw)
To: Anirudh Rayabharam
Cc: linux-hyperv, linux-kernel, kys, haiyangz, wei.liu, mhklinux,
decui, paekkaladevi
In-Reply-To: <aLsz78GrA_mqucOb@anirudh-surface.localdomain>
On 9/5/2025 12:03 PM, Anirudh Rayabharam wrote:
> 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.
>
I agree. It can continue with vmm_caps set to zero, and print an error.
The check for -EIO is meant to achieve something similar but it's kind of
unreliable since so many HV_STATUS's map to EIO. So this idea is better,
thanks.
Nuno
> Thanks,
> Anirudh.
>
>> + }
>> +
>> ret = mshv_irqfd_wq_init();
>> if (ret)
>> goto exit_partition;
>> --
>> 2.34.1
>>
^ permalink raw reply
* Re: [PATCH V0 0/2] Fix CONFIG_HYPERV and vmbus related anamoly
From: Mukesh R @ 2025-09-05 21:41 UTC (permalink / raw)
To: Nuno Das Neves, 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: <231f05cb-4f33-48ac-bb2e-1359ed52e606@linux.microsoft.com>
On 9/5/25 13:08, Nuno Das Neves wrote:
> On 9/4/2025 11:18 AM, Mukesh R wrote:
>> 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.
>
> It surprises me a little that =m doesn't get 'fixed up' to =y in this case.
> I guess any invalid value turns to =n, which makes sense most of the time.
>
>>>>>
>>>>> 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.
>
> I'm wondering, is there a path for this change, then? Are there some
> intermediate step/s we could take to minimize the problem?
>
>>>>
>>>> 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."
>>
> That was before Michael pointed out the potential issues which I was
> unaware of. Let's see if there's a path that is smoother for all the
> downstream users who may be compiling with CONFIG_HYPERV=m.
Ok, we've already thought of it for sometime and not able to come up
with any. IMO, it's a minor hickup, not major. This is stalling
upcoming iommu and other patches which will use CONFIG_HYPERV and
add more dependencies, and it would be much harder to straighten
out then. So I hope you guys can come up with some solution sooner than
later, I can't think of any.
Thanks,
-Mukesh
^ permalink raw reply
* Re: [PATCH V0 0/2] Fix CONFIG_HYPERV and vmbus related anamoly
From: Nuno Das Neves @ 2025-09-05 20:08 UTC (permalink / raw)
To: Mukesh R, 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: <4f38c613-255c-eaf6-0d50-28f8ffc02fff@linux.microsoft.com>
On 9/4/2025 11:18 AM, Mukesh R wrote:
> 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.
It surprises me a little that =m doesn't get 'fixed up' to =y in this case.
I guess any invalid value turns to =n, which makes sense most of the time.
>>>>
>>>> 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.
I'm wondering, is there a path for this change, then? Are there some
intermediate step/s we could take to minimize the problem?
>>>
>>> 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."
>
That was before Michael pointed out the potential issues which I was
unaware of. Let's see if there's a path that is smoother for all the
downstream users who may be compiling with CONFIG_HYPERV=m.
Nuno
> Thanks,> -Mukesh
>
>
^ permalink raw reply
* Re: [PATCH 6/6] mshv: Introduce new hypercall to map stats page for L1VH partitions
From: Easwar Hariharan @ 2025-09-05 19:50 UTC (permalink / raw)
To: Nuno Das Neves
Cc: linux-hyperv, linux-kernel, easwar.hariharan, kys, haiyangz,
wei.liu, mhklinux, decui, paekkaladevi, Jinank Jain
In-Reply-To: <1756428230-3599-7-git-send-email-nunodasneves@linux.microsoft.com>
On 8/28/2025 5:43 PM, Nuno Das Neves wrote:
> From: Jinank Jain <jinankjain@linux.microsoft.com>
>
> Introduce HVCALL_MAP_STATS_PAGE2 which provides a map location (GPFN)
> to map the stats to. This hypercall is required for L1VH partitions,
> depending on the hypervisor version. This uses the same check as the
> state page map location; mshv_use_overlay_gpfn().
>
> Add mshv_map_vp_state_page() helpers to use this new hypercall or the
> old one depending on availability.
>
> For unmapping, the original HVCALL_UNMAP_STATS_PAGE works for both
> cases.
>
> Signed-off-by: Jinank Jain <jinankjain@linux.microsoft.com>
> Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
> ---
> drivers/hv/mshv_root.h | 10 ++--
> drivers/hv/mshv_root_hv_call.c | 92 ++++++++++++++++++++++++++++++++--
> drivers/hv/mshv_root_main.c | 25 +++++----
> include/hyperv/hvgdk_mini.h | 1 +
> include/hyperv/hvhdk_mini.h | 7 +++
> 5 files changed, 115 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/hv/mshv_root.h b/drivers/hv/mshv_root.h
> index d7c9520ef788..d16a020ae0ee 100644
> --- a/drivers/hv/mshv_root.h
> +++ b/drivers/hv/mshv_root.h
> @@ -297,11 +297,11 @@ int hv_call_connect_port(u64 port_partition_id, union hv_port_id port_id,
> int hv_call_disconnect_port(u64 connection_partition_id,
> union hv_connection_id connection_id);
> int hv_call_notify_port_ring_empty(u32 sint_index);
> -int hv_call_map_stat_page(enum hv_stats_object_type type,
> - const union hv_stats_object_identity *identity,
> - void **addr);
> -int hv_call_unmap_stat_page(enum hv_stats_object_type type,
> - const union hv_stats_object_identity *identity);
> +int hv_map_stats_page(enum hv_stats_object_type type,
> + const union hv_stats_object_identity *identity,
> + void **addr);
> +int hv_unmap_stats_page(enum hv_stats_object_type type, void *page_addr,
> + const union hv_stats_object_identity *identity);
> int hv_call_modify_spa_host_access(u64 partition_id, struct page **pages,
> u64 page_struct_count, u32 host_access,
> u32 flags, u8 acquire);
> diff --git a/drivers/hv/mshv_root_hv_call.c b/drivers/hv/mshv_root_hv_call.c
> index 1882cc90f2f5..44013751cfc1 100644
> --- a/drivers/hv/mshv_root_hv_call.c
> +++ b/drivers/hv/mshv_root_hv_call.c
> @@ -804,6 +804,45 @@ hv_call_notify_port_ring_empty(u32 sint_index)
> return hv_result_to_errno(status);
> }
>
> +static int
> +hv_call_map_stats_page2(enum hv_stats_object_type type,
Again, one line please. Also below.
> + const union hv_stats_object_identity *identity,
> + u64 map_location)
> +{
> + unsigned long flags;
> + struct hv_input_map_stats_page2 *input;
> + u64 status;
> + int ret;
> +
> + if (!map_location || !mshv_use_overlay_gpfn())
> + return -EINVAL;
> +
> + do {
> + local_irq_save(flags);
> + input = *this_cpu_ptr(hyperv_pcpu_input_arg);
> +
> + memset(input, 0, sizeof(*input));
> + input->type = type;
> + input->identity = *identity;
> + input->map_location = map_location;
> +
> + status = hv_do_hypercall(HVCALL_MAP_STATS_PAGE2, input, NULL);
> +
> + local_irq_restore(flags);
> + if (hv_result(status) != HV_STATUS_INSUFFICIENT_MEMORY) {
> + if (hv_result_success(status))
> + break;
> + hv_status_debug(status, "\n");
> + return hv_result_to_errno(status);
> + }
> +
> + ret = hv_call_deposit_pages(NUMA_NO_NODE,
> + hv_current_partition_id, 1);
> + } while (!ret);
> +
> + return ret;
> +}
> +
> static int
> hv_stats_get_area_type(enum hv_stats_object_type type,
> const union hv_stats_object_identity *identity)
> @@ -822,9 +861,10 @@ hv_stats_get_area_type(enum hv_stats_object_type type,
> return -EINVAL;
> }
>
> -int hv_call_map_stat_page(enum hv_stats_object_type type,
> - const union hv_stats_object_identity *identity,
> - void **addr)
> +static int
> +hv_call_map_stats_page(enum hv_stats_object_type type,
> + const union hv_stats_object_identity *identity,
> + void **addr)
...
> {
> unsigned long flags;
> struct hv_input_map_stats_page *input;
> @@ -880,8 +920,37 @@ int hv_call_map_stat_page(enum hv_stats_object_type type,
> return ret;
> }
>
> -int hv_call_unmap_stat_page(enum hv_stats_object_type type,
> - const union hv_stats_object_identity *identity)
> +int hv_map_stats_page(enum hv_stats_object_type type,
> + const union hv_stats_object_identity *identity,
> + void **addr)
> +{
> + int ret;
> + struct page *allocated_page = NULL;
> +
> + if (!addr)
> + return -EINVAL;
> +
> + if (mshv_use_overlay_gpfn()) {
> + allocated_page = alloc_page(GFP_KERNEL);
> + if (!allocated_page)
> + return -ENOMEM;
> +
> + ret = hv_call_map_stats_page2(type, identity,
> + page_to_pfn(allocated_page));
> + *addr = page_address(allocated_page);
> + } else {
> + ret = hv_call_map_stats_page(type, identity, addr);
> + }
> +
> + if (ret && allocated_page)
> + __free_page(allocated_page);
> +
> + return ret;
> +}
> +
> +static int
> +hv_call_unmap_stats_page(enum hv_stats_object_type type,
...
> + const union hv_stats_object_identity *identity)
> {
> unsigned long flags;
> struct hv_input_unmap_stats_page *input;
> @@ -900,6 +969,19 @@ int hv_call_unmap_stat_page(enum hv_stats_object_type type,
> return hv_result_to_errno(status);
> }
>
> +int hv_unmap_stats_page(enum hv_stats_object_type type, void *page_addr,
> + const union hv_stats_object_identity *identity)
> +{
> + int ret;
> +
> + ret = hv_call_unmap_stats_page(type, identity);
> +
> + if (mshv_use_overlay_gpfn() && page_addr)
> + __free_page(virt_to_page(page_addr));
> +
> + return ret;
> +}
> +
> int hv_call_modify_spa_host_access(u64 partition_id, struct page **pages,
> u64 page_struct_count, u32 host_access,
> u32 flags, u8 acquire)
> diff --git a/drivers/hv/mshv_root_main.c b/drivers/hv/mshv_root_main.c
> index f91880cc9e29..1699423cc524 100644
> --- a/drivers/hv/mshv_root_main.c
> +++ b/drivers/hv/mshv_root_main.c
> @@ -894,7 +894,8 @@ mshv_vp_release(struct inode *inode, struct file *filp)
> return 0;
> }
>
> -static void mshv_vp_stats_unmap(u64 partition_id, u32 vp_index)
> +static void mshv_vp_stats_unmap(u64 partition_id, u32 vp_index,
> + void *stats_pages[])
> {
> union hv_stats_object_identity identity = {
> .vp.partition_id = partition_id,
> @@ -902,10 +903,13 @@ static void mshv_vp_stats_unmap(u64 partition_id, u32 vp_index)
> };
>
> identity.vp.stats_area_type = HV_STATS_AREA_SELF;
> - hv_call_unmap_stat_page(HV_STATS_OBJECT_VP, &identity);
> + hv_unmap_stats_page(HV_STATS_OBJECT_VP, NULL, &identity);
> +
> + if (stats_pages[HV_STATS_AREA_PARENT] == stats_pages[HV_STATS_AREA_SELF])
> + return;
>
> identity.vp.stats_area_type = HV_STATS_AREA_PARENT;
> - hv_call_unmap_stat_page(HV_STATS_OBJECT_VP, &identity);
> + hv_unmap_stats_page(HV_STATS_OBJECT_VP, NULL, &identity);
> }
>
> static int mshv_vp_stats_map(u64 partition_id, u32 vp_index,
> @@ -918,14 +922,14 @@ static int mshv_vp_stats_map(u64 partition_id, u32 vp_index,
> int err;
>
> identity.vp.stats_area_type = HV_STATS_AREA_SELF;
> - err = hv_call_map_stat_page(HV_STATS_OBJECT_VP, &identity,
> - &stats_pages[HV_STATS_AREA_SELF]);
> + err = hv_map_stats_page(HV_STATS_OBJECT_VP, &identity,
> + &stats_pages[HV_STATS_AREA_SELF]);
Shouldn't this be in the previous patch where the other hv_call_map_stat_page() calls were
converted, same below?
> if (err)
> return err;
>
> identity.vp.stats_area_type = HV_STATS_AREA_PARENT;
> - err = hv_call_map_stat_page(HV_STATS_OBJECT_VP, &identity,
> - &stats_pages[HV_STATS_AREA_PARENT]);
> + err = hv_map_stats_page(HV_STATS_OBJECT_VP, &identity,
> + &stats_pages[HV_STATS_AREA_PARENT]);
...
> if (err)
> goto unmap_self;
>
> @@ -936,7 +940,7 @@ static int mshv_vp_stats_map(u64 partition_id, u32 vp_index,
>
> unmap_self:
> identity.vp.stats_area_type = HV_STATS_AREA_SELF;
> - hv_call_unmap_stat_page(HV_STATS_OBJECT_VP, &identity);
> + hv_unmap_stats_page(HV_STATS_OBJECT_VP, NULL, &identity);
> return err;
> }
>
<snip>
^ permalink raw reply
* Re: [PATCH 1/6] mshv: Only map vp->vp_stats_pages if on root scheduler
From: Easwar Hariharan @ 2025-09-05 19:43 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-2-git-send-email-nunodasneves@linux.microsoft.com>
On 8/28/2025 5: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(-)
<snip>
Reviewed-by: Easwar Hariharan <easwar.hariharan@linux.microsoft.com>
^ permalink raw reply
* Re: [PATCH 5/6] mshv: Allocate vp state page for HVCALL_MAP_VP_STATE_PAGE on L1VH
From: Easwar Hariharan @ 2025-09-05 19:41 UTC (permalink / raw)
To: Nuno Das Neves
Cc: linux-hyperv, linux-kernel, easwar.hariharan, 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 5: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(-)
<snip>
Reviewed-by: Easwar Hariharan <easwar.hariharan@linux.microsoft.com>
^ permalink raw reply
* 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
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