Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] hv: ABI contract violation due to inverted struct layout in union hv_device_domain_id --
commit c28c527a68422d4f65cc6bf951a593dabdfd536b Author: Mukesh R <[email protected]> mshv: Import data structs around device domains from hyperv headers This commit copies and imports definitions and declarations from Hyper-V public headers related to creating iommu domains, attaching devices to them, and other related operations. > diff --git a/include/hyperv/hvhdk_mini.h b/include/hyperv/hvhdk_mini.h > index 035ba20870f73..3dbfb338bcba1 100644 > --- a/include/hyperv/hvhdk_mini.h > +++ b/include/hyperv/hvhdk_mini.h [ ... ] > +#define HV_DEVICE_DOMAIN_TYPE_S2 0 /* HV_DEVICE_DOMAIN_ID_TYPE_S2 */ > +#define HV_DEVICE_DOMAIN_TYPE_S1 1 /* HV_DEVICE_DOMAIN_ID_TYPE_S1 */ > + > +#define HV_DEVICE_DOMAIN_ID_S2_DEFAULT 0 > +#define HV_DEVICE_DOMAIN_ID_S2_NULL 0xFFFFFFFFULL > + > +union hv_device_domain_id { > + u64 as_uint64; > + struct { > + u32 type : 4; > + u32 reserved : 28; > + u32 id; > + }; > +} __packed; [Severity: High] Does this struct layout correctly match the hypervisor ABI expectations? The macro HV_DEVICE_DOMAIN_ID_S2_NULL is defined as 0xFFFFFFFFULL, representing an invalid S2 domain. For a 64-bit value to have a type of 0 (S2) and an id of 0xFFFFFFFF and evaluate to 0xFFFFFFFFULL, the id field must occupy the lower 32 bits, and type must occupy the upper 32 bits. However, the current layout places type in the first 32-bit word (lower 32 bits) and id in the second (upper 32 bits). If the driver populates type 0 and id 0xFFFFFFFF during domain creation or attachment via HVCALL_CREATE_DEVICE_DOMAIN, wouldn't it produce 0xFFFFFFFF00000000ULL? Will the hypervisor misinterpret this as an id of 0 and a type of 15 instead, causing the hypercalls to fail or operate on the wrong domains? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=3
