Re: [PATCH v3 1/5] hyperv: Introduce new hypercall interfaces used by Hyper-V guest IOMMU

Yu Zhang <[email protected]>
Newsgroups org.kernel.vger.linux-hyperv,dev.linux.lists.iommu,org.kernel.vger.linux-arch,org.kernel.vger.linux-kernel,org.kernel.vger.linux-pci
Message-ID <rpzpjbalau22m7f2s2ljxm6byzspuewqcu4awfih6qavkkazq6@mpraxcbidlar>
On Fri, Aug 14, 2026 at 03:31:08PM +0000, Michael Kelley wrote:
> From: Yu Zhang <[email protected]> Sent: Tuesday, August 11, 2026 8:50 AM
> > 
> > From: Wei Liu <[email protected]>
> > 
> > Hyper-V guest IOMMU is a para-virtualized IOMMU based on hypercalls.
> > Introduce the hypercalls used by the child partition to interact with
> > this facility.
> > 
> > These hypercalls fall into below categories:
> > - Detection and capability: HVCALL_GET_IOMMU_CAPABILITIES is used to
> >   detect the existence and capabilities of the guest IOMMU.
> > 
> > - Device management: HVCALL_GET_LOGICAL_DEVICE_PROPERTY is used to
> >   check whether an endpoint device is managed by the guest IOMMU.
> > 
> > - Domain management: A set of hypercalls is provided to handle the
> >   creation, configuration, and deletion of guest domains, as well as
> >   the attachment/detachment of endpoint devices to/from those domains.
> > 
> > - IOTLB flushing: HVCALL_FLUSH_DEVICE_DOMAIN is used to ask Hyper-V
> >   for a domain-selective IOTLB flush (which in its handler may flush
> >   the device TLB as well).
> > 
> 
> [snip]
> 
> > +
> > +struct hv_input_device_domain {
> > +	u64 partition_id;
> > +	union hv_input_vtl owner_vtl;
> > +	u8 padding[7];
> > +	union hv_device_domain_id domain_id;
> > +} __packed;
> > +
> > +union hv_create_device_domain_flags {
> > +	u32 as_uint32;
> > +	struct {
> > +		u32 forward_progress_required: 1;
> > +		u32 inherit_owning_vtl: 1;
> > +		u32 reserved: 30;
> > +	} __packed;
> > +};
> > +
> > +struct hv_input_create_device_domain {
> > +	struct hv_input_device_domain device_domain;
> > +	union hv_create_device_domain_flags create_device_domain_flags;
> > +	u32 padding;
> > +} __packed;
> > +static_assert(sizeof(struct hv_input_create_device_domain) == 32);
> 
> The static_assert() here is unusual. For all the other hypercall
> inputs/outputs where we rely on the structure definition to
> be correct and the __packed to prevent the compiler from
> adding/changing anything. If there's a reason for this one to be
> different, a comment would help. If there's not really a reason,
> I'd suggest dropping the static_assert() as superfluous.
> 

Thank you, Michael.
Indeed, there's no reason to treat this data structure differently.
Will drop the static_assert() and keep the explicit padding.

B.R.
Yu

> Michael
> 
> > +
> > +struct hv_input_delete_device_domain {
> > +	struct hv_input_device_domain device_domain;
> > +} __packed;
> > +
> > +struct hv_input_attach_device_domain {
> > +	struct hv_input_device_domain device_domain;
> > +	union hv_device_id device_id;
> > +} __packed;
> > +
> > +struct hv_input_detach_device_domain {
> > +	u64 partition_id;
> > +	union hv_device_id device_id;
> > +} __packed;
> > +
> > +struct hv_device_domain_settings {
> > +	struct {
> > +		/*
> > +		 * Enable translations. If not enabled, all transaction bypass
> > +		 * S1 translations.
> > +		 */
> > +		u64 translation_enabled: 1;
> > +		u64 blocked: 1;
> > +		/*
> > +		 * First stage address translation paging mode:
> > +		 * 0: 4-level paging (default)
> > +		 * 1: 5-level paging
> > +		 */
> > +		u64 first_stage_paging_mode: 1;
> > +		u64 reserved: 61;
> > +	} flags;
> > +
> > +	/* Address of translation table */
> > +	u64 page_table_root;
> > +} __packed;
> > +
> > +struct hv_input_configure_device_domain {
> > +	struct hv_input_device_domain device_domain;
> > +	struct hv_device_domain_settings settings;
> > +} __packed;
> > +
> > +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    BIT_ULL(0)
> > +#define HV_IOMMU_CAP_S2         BIT_ULL(1)
> > +#define HV_IOMMU_CAP_S1         BIT_ULL(2)
> > +#define HV_IOMMU_CAP_S1_5LVL    BIT_ULL(3)
> > +#define HV_IOMMU_CAP_PASID      BIT_ULL(4)
> > +#define HV_IOMMU_CAP_ATS        BIT_ULL(5)
> > +#define HV_IOMMU_CAP_PRI        BIT_ULL(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;
> > +	/* Takes values from enum hv_logical_device_property_code. */
> > +	u32 code;
> > +	u32 reserved;
> > +} __packed;
> > +
> > +struct hv_output_get_logical_device_property {
> > +#define HV_DEVICE_IOMMU_ENABLED	BIT_ULL(0)
> > +	u64 device_iommu;
> > +	u64 reserved;
> > +} __packed;
> > +
> > +struct hv_input_flush_device_domain {
> > +	struct hv_input_device_domain device_domain;
> > +	u32 flags;
> > +	u32 reserved;
> > +} __packed;
> > +
> >  #endif /* _HV_HVHDK_MINI_H */
> > --
> > 2.52.0
> > 
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.