Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] mshv: incorrect bitfield layout for union hv_device_domain_id corrupts hypercall ABI --
commit a37c5c0ca47021bec11c9aa7d2a0eb2626dc10ce Author: Mukesh R <[email protected]> mshv: Import data structs around device domains from hyperv headers Copy/import from Hyper-V public headers, definitions and declarations that are related to creating iommu domains in the hypervisor, attaching devices to them, doing the reverse, etc. > 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_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 incorrectly define type and reserved before id, placing id in the upper 32 bits of the 64-bit union instead of the lower 32 bits? The imported constant HV_DEVICE_DOMAIN_ID_S2_NULL is defined as 0xFFFFFFFFULL, which has 0xFFFFFFFF in the lower 32 bits and 0 in the upper 32 bits. This indicates the hypervisor expects the 32-bit id field to be in the lower 32 bits (LSB) and the type to be in the upper 32 bits. Because C bitfields in little-endian architectures populate the lowest bits first, defining type and reserved before id places the type field in the lower 32 bits and the id field in the upper 32 bits. Could this layout mismatch cause hypercalls to create or attach device domains to send a corrupted 64-bit domain ID? If the hypervisor misinterprets the domain type and ID, this would lead to hypercall failures and break IOMMU isolation for devices when the driver populates domain_id.type and domain_id.id. -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=2
