From: Easwar Hariharan <[email protected]> Sent: Friday, January 9, 2026 10:47 AM > > 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. >
In the C language, the size of an enum is implementation defined. Do a Co-Pilot search on "How many bytes is an enum in C", and you'll get a fairly long answer explaining the idiosyncrasies. For gcc, and for MSVC on the hypervisor side, the default is that an "enum" size is the same as an "int", so everything works in current practice. But the compiler is allowed to optimize the size of an enum if a smaller integer type can contain all the values, and that would mess things up in an ABI. Hence the intent to not use "enum" in the hypervisor ABI. Windows/Hyper-V historically didn't have to worry about such things since they controlled both sides of the ABI, but the more Linux uses the ABI, the greater potential for something to go wrong. I wish Windows/Hyper-V would tighten up their ABI specification, but it is what it is. So I'm not sure how best to deal with the issue in light of wanting to take the hypervisor ABI definitions directly from the Windows environment and not modify them. I did a quick grep of the hv*.h files in include/hyperv from linux-next, and while there are many enum types defined, none are used as fields in a structure. There are many cases of u32, and a couple u16's, followed by a comment identifying the enum type that should be used to populate the field. Michael
