> On 2. Oct 2025, at 11:10, Magnus Kulke <[email protected]>
> wrote:
>
> On Thu, Oct 02, 2025 at 10:30:56AM +0200, Philippe Mathieu-Daudé wrote:
>> Due to my generic work on accelerators, I'll have to refactor these
>> patches. Obviously I don't want to break your implementation! Can
>> you add some (functional?) tests? Ideally we should be running
>> tests on our CI to ensure code doesn't bitrot.
>>
>> Regards,
>>
>> Phil.
>
> Hey Phil,
>
> yes, that's a good point. I assume for functional tests we
> will face the challenge those will require external infra, because
> eventually there needs to be a HyperV Hypervisor running somewhere.
Worth noting that x86_64 MSHV on Linux is available to the public as part of
Azure Linux,
and runs inside of a Qemu VM just fine. (with the catch that MBEC isn’t
currently emulated by KVM)
Perhaps having an Azure Linux instance in CI could be the right thing to do?
Thank you,
> Is there any precedent/prior art in QEMU (e.g. for HVF or WHPX) that we
> could follow?
>
> FWIW, in smoke tests for the patch series I've been using a nested
> HyperV hypervisor that is shipped as dll and made available as UEFI
> protocol to the MSHV driver (I _think_ that is how it works, I'm a
> bit out of my depth here since I don't know how those things are
> glued together in detail).
>
> For reference: https://github.com/mkulke/qemu/actions/runs/18187719634
>
> There will be other virt topologies supported by the MSHV driver and
> the nested option is not upstreamed to mainline yet. However, from
> QEMU's perspective those topologies do not matter, they share the same
> ABI of the kernel driver.
>
> So we could do something similar, provide/maintain a VM on Azure with a
> similar nested HyperV hypervisor configuration that we can used for
> testing. Would this make sense?
>
> Best,
>
> magnus
>
