On 1/8/2026 10:47 AM, Michael Kelley wrote:
> From: Yu Zhang <[email protected]> Sent: Monday, December 8, 2025
> 9:11 PM
>>
>> From: Wei Liu <[email protected]>
>>
<snip>
>> +struct hv_input_get_iommu_capabilities {
>> + u64 partition_id;
>> + u64 reserved;
>> +} __packed;
>> +
>> +struct hv_output_get_iommu_capabilities {
>> + u32 size;
>> + u16 reserved;
>> + u8 max_iova_width;
>> + u8 max_pasid_width;
>> +
>> +#define HV_IOMMU_CAP_PRESENT (1ULL << 0)
>> +#define HV_IOMMU_CAP_S2 (1ULL << 1)
>> +#define HV_IOMMU_CAP_S1 (1ULL << 2)
>> +#define HV_IOMMU_CAP_S1_5LVL (1ULL << 3)
>> +#define HV_IOMMU_CAP_PASID (1ULL << 4)
>> +#define HV_IOMMU_CAP_ATS (1ULL << 5)
>> +#define HV_IOMMU_CAP_PRI (1ULL << 6)
>> +
>> + u64 iommu_cap;
>> + u64 pgsize_bitmap;
>> +} __packed;
>> +
>> +enum hv_logical_device_property_code {
>> + HV_LOGICAL_DEVICE_PROPERTY_PVIOMMU = 10,
>> +};
>> +
>> +struct hv_input_get_logical_device_property {
>> + u64 partition_id;
>> + u64 logical_device_id;
>> + enum hv_logical_device_property_code code;
>
> Historically we've avoided "enum" types in structures that are part of
> the hypervisor ABI. Use u32 here?
<snip>
What has been the reasoning for that practice? Since the introduction of the
include/hyperv/ headers, we have generally wanted to import as directly as
possible the relevant definitions from the hypervisor code base. If there's
a strong reason, we could consider switching the enum for a u32 here
since, at least for the moment, there's only a single value being used.
Thanks,
Easwar (he/him)
