ioctls: Fix device fd ioctl numbers to match kernel UAPI

[weltling]

The kernel 6.18 reorganized the mshv device fd UAPI. In 6.6:

#define MSHV_SET_DEVICE_ATTR  _IOW(MSHV_IOCTL, 0x00, struct mshv_device_attr)
#define MSHV_GET_DEVICE_ATTR  _IOW(MSHV_IOCTL, 0x01, struct mshv_device_attr)
#define MSHV_HAS_DEVICE_ATTR  _IOW(MSHV_IOCTL, 0x02, struct mshv_device_attr)

In 6.18, MSHV_GET_DEVICE_ATTR was removed and MSHV_HAS_DEVICE_ATTR was renumbered to 0x01:

#define MSHV_SET_DEVICE_ATTR  _IOW(MSHV_IOCTL, 0x00, struct mshv_device_attr)
#define MSHV_HAS_DEVICE_ATTR  _IOW(MSHV_IOCTL, 0x01, struct mshv_device_attr)

The crate still uses the 6.6 layout, causing has_device_attr() to send ioctl command 0x02 which the 6.18 kernel does not recognize, returning -ENOTTY. This makes test_create_device panic on:

assertion failed: device.has_device_attr(&dist_attr).is_ok()

Update the crate to match the 6.18 UAPI:

• Remove MSHV_GET_DEVICE_ATTR ioctl definition
• Fix MSHV_HAS_DEVICE_ATTR number from 0x02 to 0x01
• Remove get_device_attr() method from DeviceFd
• Update test_create_device accordingly

Note: this breaks compatibility with the 6.6 kernel.

[russell-islam]

@weltling The test failure seems due to Kernel version in test host. it is still 6.6. Right?

[weltling]

@weltling The test failure seems due to Kernel version in test host. it is still 6.6. Right?

Correct. 6.18 will have the mentioned IOCTLs changes which is incompatible. We can perhaps consider bumping the minor version of the crate after this change, as it's going to breach backward compatibility.

Thanks

[weltling]

Now confirmed through a manual run ioctls::device::tests::test_create_device is passing on a 6.18 powered host.

Thanks

[weltling]

Thinking more we need a strategy for this, because this kind of breach requires a swap on the CI side. The MSHV runner needs to use 6.18 based imag. Which would probably mean an impact on testability of the older versions of this crate. @gamora12 @anirudhrb WDYT?

Thanks