[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c3097a7e-9cce-4152-b94c-924018064b22@linux.microsoft.com>
Date: Fri, 5 Sep 2025 16:07:59 -0700
From: Nuno Das Neves <nunodasneves@...ux.microsoft.com>
To: Anirudh Rayabharam <anirudh@...rudhrb.com>
Cc: linux-hyperv@...r.kernel.org, linux-kernel@...r.kernel.org,
kys@...rosoft.com, haiyangz@...rosoft.com, wei.liu@...nel.org,
mhklinux@...look.com, decui@...rosoft.com, paekkaladevi@...ux.microsoft.com
Subject: Re: [PATCH 4/6] mshv: Get the vmm capabilities offered by the
hypervisor
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@...ux.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@...ux.microsoft.com>
>> Signed-off-by: Nuno Das Neves <nunodasneves@...ux.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
>>
Powered by blists - more mailing lists