Compiliation error on Linux with 0.5.0 release

[qbradley]

What happened?

There seems to be a regression related to #408

If I create a new project and add a reference to hyperlight_host, it does not build.

it seems to be because mshv-bindings and mshv-ioctls dependencies bring in vmm-sys-util version 0.14.0. By force-downgraded that dependency to 0.13.0, build works.

What did you expect to happen?

I expected it to compile, but instead get error:

error[E0277]: ? couldn't convert the error to HyperlightError

However, if I modify Cargo.lock and change vmm-sys-util dependency from 0.14.0 to 0.13.0 for mshv-bindings and mshv-ioctls, build now works

Steps to reproduce the behavior

1. cargo init test
2. cd test
3. cargo add hyperlight_host
4. cargo build

Hyperlight Version

0.5.0

OS version

vscode [ /workspaces/debugtest ]$ cat /etc/os-release 
NAME="Microsoft Azure Linux"
VERSION="3.0.20250521"
ID=azurelinux
VERSION_ID="3.0"
PRETTY_NAME="Microsoft Azure Linux 3.0"
ANSI_COLOR="1;34"
HOME_URL="https://aka.ms/azurelinux"
BUG_REPORT_URL="https://aka.ms/azurelinux"
SUPPORT_URL="https://aka.ms/azurelinux"
vscode [ /workspaces/debugtest ]$ uname -a
Linux 75b2257d5bbb 5.15.167.4-microsoft-standard-WSL2 #1 SMP Tue Nov 5 00:21:55 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Additional Information

No response

[ludfjig]

Thanks for the issue, I can reproduce it. Will investigate how to fix and how this was possible

[simongdavies]

This issue also shows up in https://github.com/hyperlight-dev/hyperlight/actions/runs/15322786485/job/43110061809 .

Not sure why this impacts v0.5.0 https://github.com/hyperlight-dev/hyperlight/blob/main/Cargo.lock seems to be locked to v0.13.0.

Anyway if we fix and merge #523 it should resolve this.

[ludfjig]

Fixed in newly released 0.5.1

[jsturtevant]

did we find out how CI missed it and if there was anything we could to prevent an issue like this from happening again?

[simongdavies]

@jsturtevant Sort of, we have an error enum that uses thiserror and converts errors from one type to another , in this type we had conversions for kvm_ioctls::error, mshv_ioctls::MshvError and vmm_sys_util::errno::Error. kvm_ioctls::error is a re-export of vmm_sys_util::errno::Error and mshv_ioctls::MshvError is also a thiserror implementation that converts from vmm_sys_util::errno::Error to mshv_ioctls::MshvError.

Our dependency is/was for 0.13.0, mshv specifies its dependency as = >=0.12.1.
We check in Cargo.lock which locked all dependencies to 0.13.0. This means that our tests and CI would not see this issue.

So if we had not checked in Cargo.lock I think this would have shown up in our CI, I don't recall why we decided to check in Cargo.lock, but maybe we should revisit this.

That said this still could have happened had we not checked in Cargo.lock since if a new version of vmm_sys_util was released after we released a version of hyperlight .

I dont know if we can patch the version so we point to a git repo

[patch.crates-io]
vmm_sys_util = "git=...."

in our Cargo.toml (and that version should match the version that hyperlight is using), I don't know if that would prevent us publishing the crate.

Another option might be for us to specify our dependency to match mshv (>=0.12.1)

I will create a new issue for us to look at this