MAINTAINERS | 8 +
accel/mshv/irq.c | 2 +
accel/mshv/meson.build | 4 +-
accel/mshv/mshv-all.c | 73 +++-
accel/mshv/mshv-cpu-common.c | 151 +++++++++
hw/arm/virt.c | 11 +-
hw/intc/arm_gicv3_common.c | 3 +
hw/intc/arm_gicv3_mshv.c | 180 ++++++++++
hw/intc/meson.build | 1 +
include/hw/hyperv/hvgdk_mini.h | 130 ++++++++
include/hw/hyperv/hvhdk.h | 97 +++++-
include/hw/hyperv/hvhdk_mini.h | 6 +
include/hw/intc/arm_gicv3_common.h | 1 +
include/system/hw_accel.h | 3 +-
include/system/mshv.h | 2 +
include/system/mshv_int.h | 5 +
meson.build | 7 +-
target/arm/cpu.c | 7 +-
target/arm/cpu64.c | 24 +-
target/arm/meson.build | 1 +
target/arm/mshv/meson.build | 7 +
target/arm/mshv/mshv-all.c | 665 +++++++++++++++++++++++++++++++++++++
target/arm/mshv_arm.h | 18 +
target/i386/mshv/meson.build | 2 +
target/i386/mshv/mshv-all.c | 85 +++++
target/i386/mshv/mshv-cpu.c | 170 +---------
{accel => target/i386}/mshv/msr.c | 0
27 files changed, 1465 insertions(+), 198 deletions(-)
This series adds ARM64 guest support to the MSHV (Microsoft Hypervisor)
accelerator, enabling QEMU to run aarch64 VMs on Microsoft's hypervisor
using the mshv Linux kernel module.
The first few patches refactor the existing x86 MSHV code to separate
arch-specific pieces from common infrastructure: moving MSR handling to
target/i386, extracting shared register hypercall helpers, provisioning
host CPU features, and introducing arch-specific init hooks.
The remaining patches add the ARM64 backend:
- vCPU state get/set using hypervisor register hypercalls
- -cpu host support by querying ID registers from the hypervisor
- vCPU run loop with MMIO emulation via ESR_EL2 syndrome decoding
- In-kernel vGICv3 backed by HVCALL_ASSERT_VIRTUAL_INTERRUPT
- Interrupt control structure adjustments for arm64
With this series, a standard aarch64 virt machine can be launched with:
qemu-system-aarch64 -accel mshv -cpu host -M virt ...
Caveats:
- Currently only direct kernel is supported. We're still debugging edk2
firmware boot.
- Live migration is not yet supported.
---
Aastha Rawat (7):
accel/mshv: move msr.c to target/i386
accel/mshv: extract common CPU register helpers
meson, target/arm/mshv: Enable arm64 build & add initial MSHV support
target/arm/mshv: implement vcpu state operations for ARM64
target/arm/mshv: implement -cpu host for MSHV
accel/mshv: Add access_vp_regs synthetic proc features
target/arm: cpu: Mark MSHV supporting PSCI 1.3
Anirudh Rayabharam (Microsoft) (6):
accel/mshv: provision guests with the same features as host
accel/mshv: add arch-specific accelerator init hook
target/arm/mshv: add vCPU run loop
include/hw/hyperv: adjust hv_interrupt_control structure for arm64
hw/intc,target/arm/mshv: add MSHV vGICv3 implementation
MAINTAINERS: updates for MSHV arm64 code
Magnus Kulke (1):
accel/mshv: implement cpu_thread_is_idle() hook
MAINTAINERS | 8 +
accel/mshv/irq.c | 2 +
accel/mshv/meson.build | 4 +-
accel/mshv/mshv-all.c | 73 +++-
accel/mshv/mshv-cpu-common.c | 151 +++++++++
hw/arm/virt.c | 11 +-
hw/intc/arm_gicv3_common.c | 3 +
hw/intc/arm_gicv3_mshv.c | 180 ++++++++++
hw/intc/meson.build | 1 +
include/hw/hyperv/hvgdk_mini.h | 130 ++++++++
include/hw/hyperv/hvhdk.h | 97 +++++-
include/hw/hyperv/hvhdk_mini.h | 6 +
include/hw/intc/arm_gicv3_common.h | 1 +
include/system/hw_accel.h | 3 +-
include/system/mshv.h | 2 +
include/system/mshv_int.h | 5 +
meson.build | 7 +-
target/arm/cpu.c | 7 +-
target/arm/cpu64.c | 24 +-
target/arm/meson.build | 1 +
target/arm/mshv/meson.build | 7 +
target/arm/mshv/mshv-all.c | 665 +++++++++++++++++++++++++++++++++++++
target/arm/mshv_arm.h | 18 +
target/i386/mshv/meson.build | 2 +
target/i386/mshv/mshv-all.c | 85 +++++
target/i386/mshv/mshv-cpu.c | 170 +---------
{accel => target/i386}/mshv/msr.c | 0
27 files changed, 1465 insertions(+), 198 deletions(-)
---
base-commit: 1fd5ff9d76d23ab23a68419cbc76d5ee33e8b455
change-id: 20260311-mshv_accel_arm64_supp-e86b0082aee4
Best regards,
--
Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>
"Anirudh Rayabharam (Microsoft)" <anirudh@anirudhrb.com> writes:
> This series adds ARM64 guest support to the MSHV (Microsoft Hypervisor)
> accelerator, enabling QEMU to run aarch64 VMs on Microsoft's hypervisor
> using the mshv Linux kernel module.
Does GitLab (or anything we plug into it) support runners on Arm64 with
HyperV and a Linux Dom0?
I looks like we would need a dedicated runner to defend the
functionality on CI.
>
> The first few patches refactor the existing x86 MSHV code to separate
> arch-specific pieces from common infrastructure: moving MSR handling to
> target/i386, extracting shared register hypercall helpers, provisioning
> host CPU features, and introducing arch-specific init hooks.
>
> The remaining patches add the ARM64 backend:
> - vCPU state get/set using hypervisor register hypercalls
> - -cpu host support by querying ID registers from the hypervisor
> - vCPU run loop with MMIO emulation via ESR_EL2 syndrome decoding
> - In-kernel vGICv3 backed by HVCALL_ASSERT_VIRTUAL_INTERRUPT
> - Interrupt control structure adjustments for arm64
>
> With this series, a standard aarch64 virt machine can be launched with:
> qemu-system-aarch64 -accel mshv -cpu host -M virt ...
>
> Caveats:
> - Currently only direct kernel is supported. We're still debugging edk2
> firmware boot.
> - Live migration is not yet supported.
>
> ---
> Aastha Rawat (7):
> accel/mshv: move msr.c to target/i386
> accel/mshv: extract common CPU register helpers
> meson, target/arm/mshv: Enable arm64 build & add initial MSHV support
> target/arm/mshv: implement vcpu state operations for ARM64
> target/arm/mshv: implement -cpu host for MSHV
> accel/mshv: Add access_vp_regs synthetic proc features
> target/arm: cpu: Mark MSHV supporting PSCI 1.3
>
> Anirudh Rayabharam (Microsoft) (6):
> accel/mshv: provision guests with the same features as host
> accel/mshv: add arch-specific accelerator init hook
> target/arm/mshv: add vCPU run loop
> include/hw/hyperv: adjust hv_interrupt_control structure for arm64
> hw/intc,target/arm/mshv: add MSHV vGICv3 implementation
> MAINTAINERS: updates for MSHV arm64 code
>
> Magnus Kulke (1):
> accel/mshv: implement cpu_thread_is_idle() hook
>
> MAINTAINERS | 8 +
> accel/mshv/irq.c | 2 +
> accel/mshv/meson.build | 4 +-
> accel/mshv/mshv-all.c | 73 +++-
> accel/mshv/mshv-cpu-common.c | 151 +++++++++
> hw/arm/virt.c | 11 +-
> hw/intc/arm_gicv3_common.c | 3 +
> hw/intc/arm_gicv3_mshv.c | 180 ++++++++++
> hw/intc/meson.build | 1 +
> include/hw/hyperv/hvgdk_mini.h | 130 ++++++++
> include/hw/hyperv/hvhdk.h | 97 +++++-
> include/hw/hyperv/hvhdk_mini.h | 6 +
> include/hw/intc/arm_gicv3_common.h | 1 +
> include/system/hw_accel.h | 3 +-
> include/system/mshv.h | 2 +
> include/system/mshv_int.h | 5 +
> meson.build | 7 +-
> target/arm/cpu.c | 7 +-
> target/arm/cpu64.c | 24 +-
> target/arm/meson.build | 1 +
> target/arm/mshv/meson.build | 7 +
> target/arm/mshv/mshv-all.c | 665 +++++++++++++++++++++++++++++++++++++
> target/arm/mshv_arm.h | 18 +
> target/i386/mshv/meson.build | 2 +
> target/i386/mshv/mshv-all.c | 85 +++++
> target/i386/mshv/mshv-cpu.c | 170 +---------
> {accel => target/i386}/mshv/msr.c | 0
> 27 files changed, 1465 insertions(+), 198 deletions(-)
> ---
> base-commit: 1fd5ff9d76d23ab23a68419cbc76d5ee33e8b455
> change-id: 20260311-mshv_accel_arm64_supp-e86b0082aee4
>
> Best regards,
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
On Wed, Mar 11, 2026 at 04:54:45PM +0000, Alex Bennée wrote: > "Anirudh Rayabharam (Microsoft)" <anirudh@anirudhrb.com> writes: > > > This series adds ARM64 guest support to the MSHV (Microsoft Hypervisor) > > accelerator, enabling QEMU to run aarch64 VMs on Microsoft's hypervisor > > using the mshv Linux kernel module. > > Does GitLab (or anything we plug into it) support runners on Arm64 with > HyperV and a Linux Dom0? > > I looks like we would need a dedicated runner to defend the > functionality on CI. Right. I think we would need to onboard a custom self-hosted runner for this. That's what we did on GitHub for the Cloud Hypervisor project. Thanks, Anirudh.
> On 12. Mar 2026, at 11:32, Anirudh Rayabharam <anirudh@anirudhrb.com> wrote: > > On Wed, Mar 11, 2026 at 04:35:31PM +0100, Mohamed Mediouni wrote: >> >> >>> On 11. Mar 2026, at 16:15, Anirudh Rayabharam <anirudh@anirudhrb.com> wrote: >>> >>> From: Aastha Rawat <aastharawat@linux.microsoft.com> >>> >>> Enable access_vp_regs feature for regs. In arm64, this feature bit >>> allows the guest to set VP registers using hypercall. This wasn't >>> required for x86 because such registers are set using wrmsr instead of >>> hypercall. >>> >> Hello, >> >> Could you split this into two patches? With the hvhdk.h changes in another patch. > > Any reason why? > > Throughout this series we're introducing hv*dk changes along with the > code using them. Isn't that a good idea? > Hello, I think that because of some of the content of header updates aren’t immediately related to the commits at hand, it’d be better to just have a single big commit at the beginning of the series for any GDK/HDK updates. Oh also, preemptively adding some header definitions before they’re immediately needed could be simpler for everyone - especially given that WHP exists and is overlapping a lot. Also makes me think of whether it could be better to share some code between WHPX and MSHV, but that’s a separate story… Thanks, -Mohamed
On Thu, Mar 12, 2026 at 11:45:48AM +0100, Mohamed Mediouni wrote: > > > > On 12. Mar 2026, at 11:32, Anirudh Rayabharam <anirudh@anirudhrb.com> wrote: > > > > On Wed, Mar 11, 2026 at 04:35:31PM +0100, Mohamed Mediouni wrote: > >> > >> > >>> On 11. Mar 2026, at 16:15, Anirudh Rayabharam <anirudh@anirudhrb.com> wrote: > >>> > >>> From: Aastha Rawat <aastharawat@linux.microsoft.com> > >>> > >>> Enable access_vp_regs feature for regs. In arm64, this feature bit > >>> allows the guest to set VP registers using hypercall. This wasn't > >>> required for x86 because such registers are set using wrmsr instead of > >>> hypercall. > >>> > >> Hello, > >> > >> Could you split this into two patches? With the hvhdk.h changes in another patch. > > > > Any reason why? > > > > Throughout this series we're introducing hv*dk changes along with the > > code using them. Isn't that a good idea? > > > Hello, > > I think that because of some of the content of header updates aren’t immediately related to the commits at hand, it’d be better to > just have a single big commit at the beginning of the series for any GDK/HDK updates. I think that in this series all the header updates are closely related to the commits they're made in. Do you see a discrepancy? > > Oh also, preemptively adding some header definitions before they’re immediately needed could be simpler for everyone > - especially given that WHP exists and is overlapping a lot. Could you please elaborate? How would it be simpler? Do you mean simpler for reviewing? Thanks, Anirudh. > > Also makes me think of whether it could be better to share some code between WHPX and MSHV, but that’s a separate > story… > > Thanks, > -Mohamed > >
> On 13. Mar 2026, at 10:01, Anirudh Rayabharam <anirudh@anirudhrb.com> wrote:
>
> On Thu, Mar 12, 2026 at 11:45:48AM +0100, Mohamed Mediouni wrote:
>>
>>
>>> On 12. Mar 2026, at 11:32, Anirudh Rayabharam <anirudh@anirudhrb.com> wrote:
>>>
>>> On Wed, Mar 11, 2026 at 04:35:31PM +0100, Mohamed Mediouni wrote:
>>>>
>>>>
>>>>> On 11. Mar 2026, at 16:15, Anirudh Rayabharam <anirudh@anirudhrb.com> wrote:
>>>>>
>>>>> From: Aastha Rawat <aastharawat@linux.microsoft.com>
>>>>>
>>>>> Enable access_vp_regs feature for regs. In arm64, this feature bit
>>>>> allows the guest to set VP registers using hypercall. This wasn't
>>>>> required for x86 because such registers are set using wrmsr instead of
>>>>> hypercall.
>>>>>
>>>> Hello,
>>>>
>>>> Could you split this into two patches? With the hvhdk.h changes in another patch.
>>>
>>> Any reason why?
>>>
>>> Throughout this series we're introducing hv*dk changes along with the
>>> code using them. Isn't that a good idea?
>>>
>> Hello,
>>
>> I think that because of some of the content of header updates aren’t immediately related to the commits at hand, it’d be better to
>> just have a single big commit at the beginning of the series for any GDK/HDK updates.
>
> I think that in this series all the header updates are closely related
> to the commits they're made in. Do you see a discrepancy?
>
Hello,
As a random example https://lore.kernel.org/qemu-devel/20260312202209.GA124403@liuwe-devbox-debian-v2.local/T/#madb0f563a418a8fa1ebe35edd782aa4414893e5c ("accel/mshv: Add access_vp_regs synthetic proc features”) adds a bunch of other bits that aren’t that directly related to it.
It doesn’t mean that this info is not useful to have upstream - that’s great to have - but I think that a separate commit for the header updates at the beginning (combining them all) is best.
>>
>>
>> Oh also, preemptively adding some header definitions before they’re immediately needed could be simpler for everyone
>> - especially given that WHP exists and is overlapping a lot.
>
> Could you please elaborate? How would it be simpler? Do you mean simpler
> for reviewing?
>
Yes.
Thank you,
-Mohamed
> Thanks,
> Anirudh.
>
>>
>> Also makes me think of whether it could be better to share some code between WHPX and MSHV, but that’s a separate
>> story…
>>
>> Thanks,
>> -Mohamed
>>
>>
On Fri, Mar 13, 2026 at 12:29:32PM +0100, Mohamed Mediouni wrote:
>
>
> > On 13. Mar 2026, at 10:01, Anirudh Rayabharam <anirudh@anirudhrb.com> wrote:
> >
> > On Thu, Mar 12, 2026 at 11:45:48AM +0100, Mohamed Mediouni wrote:
> >>
> >>
> >>> On 12. Mar 2026, at 11:32, Anirudh Rayabharam <anirudh@anirudhrb.com> wrote:
> >>>
> >>> On Wed, Mar 11, 2026 at 04:35:31PM +0100, Mohamed Mediouni wrote:
> >>>>
> >>>>
> >>>>> On 11. Mar 2026, at 16:15, Anirudh Rayabharam <anirudh@anirudhrb.com> wrote:
> >>>>>
> >>>>> From: Aastha Rawat <aastharawat@linux.microsoft.com>
> >>>>>
> >>>>> Enable access_vp_regs feature for regs. In arm64, this feature bit
> >>>>> allows the guest to set VP registers using hypercall. This wasn't
> >>>>> required for x86 because such registers are set using wrmsr instead of
> >>>>> hypercall.
> >>>>>
> >>>> Hello,
> >>>>
> >>>> Could you split this into two patches? With the hvhdk.h changes in another patch.
> >>>
> >>> Any reason why?
> >>>
> >>> Throughout this series we're introducing hv*dk changes along with the
> >>> code using them. Isn't that a good idea?
> >>>
> >> Hello,
> >>
> >> I think that because of some of the content of header updates aren’t immediately related to the commits at hand, it’d be better to
> >> just have a single big commit at the beginning of the series for any GDK/HDK updates.
> >
> > I think that in this series all the header updates are closely related
> > to the commits they're made in. Do you see a discrepancy?
> >
> Hello,
>
> As a random example https://lore.kernel.org/qemu-devel/20260312202209.GA124403@liuwe-devbox-debian-v2.local/T/#madb0f563a418a8fa1ebe35edd782aa4414893e5c ("accel/mshv: Add access_vp_regs synthetic proc features”) adds a bunch of other bits that aren’t that directly related to it.
Sure, there are some additional fields but they must be added along with
the commit to preserve the correct layout of the struct. So, I would
argue that in spite of the additional fields this header update belongs
in this commit.
In general, I do agree that if the header updates are completely
unrelated or if they're massive they should be in a commit of their own.
But IMO the updates in this patch series don't fall into either category
Thanks,
Anirudh.
>
> It doesn’t mean that this info is not useful to have upstream - that’s great to have - but I think that a separate commit for the header updates at the beginning (combining them all) is best.
>
> >>
> >>
> >> Oh also, preemptively adding some header definitions before they’re immediately needed could be simpler for everyone
> >> - especially given that WHP exists and is overlapping a lot.
> >
> > Could you please elaborate? How would it be simpler? Do you mean simpler
> > for reviewing?
> >
> Yes.
>
> Thank you,
> -Mohamed
> > Thanks,
> > Anirudh.
> >
> >>
> >> Also makes me think of whether it could be better to share some code between WHPX and MSHV, but that’s a separate
> >> story…
> >>
> >> Thanks,
> >> -Mohamed
> >>
> >>
>
>
> On 11. Mar 2026, at 17:54, Alex Bennée <alex.bennee@linaro.org> wrote:
>
> "Anirudh Rayabharam (Microsoft)" <anirudh@anirudhrb.com> writes:
>
>> This series adds ARM64 guest support to the MSHV (Microsoft Hypervisor)
>> accelerator, enabling QEMU to run aarch64 VMs on Microsoft's hypervisor
>> using the mshv Linux kernel module.
>
> Does GitLab (or anything we plug into it) support runners on Arm64 with
> HyperV and a Linux Dom0?
>
> I looks like we would need a dedicated runner to defend the
> functionality on CI.
The MSHV license doesn’t allow for any use outside of Azure Kubernetes Service,
despite MSHV (for x86) being public.
And Dom0 is technically not required as there’s L1VH, but that’s even less documented to
the outside and not set up for more local use - but hopefully will make its way to Windows
client at some point :/
>>
>> The first few patches refactor the existing x86 MSHV code to separate
>> arch-specific pieces from common infrastructure: moving MSR handling to
>> target/i386, extracting shared register hypercall helpers, provisioning
>> host CPU features, and introducing arch-specific init hooks.
>>
>> The remaining patches add the ARM64 backend:
>> - vCPU state get/set using hypervisor register hypercalls
>> - -cpu host support by querying ID registers from the hypervisor
>> - vCPU run loop with MMIO emulation via ESR_EL2 syndrome decoding
>> - In-kernel vGICv3 backed by HVCALL_ASSERT_VIRTUAL_INTERRUPT
>> - Interrupt control structure adjustments for arm64
>>
>> With this series, a standard aarch64 virt machine can be launched with:
>> qemu-system-aarch64 -accel mshv -cpu host -M virt ...
>>
>> Caveats:
>> - Currently only direct kernel is supported. We're still debugging edk2
>> firmware boot.
>> - Live migration is not yet supported.
>>
>> ---
>> Aastha Rawat (7):
>> accel/mshv: move msr.c to target/i386
>> accel/mshv: extract common CPU register helpers
>> meson, target/arm/mshv: Enable arm64 build & add initial MSHV support
>> target/arm/mshv: implement vcpu state operations for ARM64
>> target/arm/mshv: implement -cpu host for MSHV
>> accel/mshv: Add access_vp_regs synthetic proc features
>> target/arm: cpu: Mark MSHV supporting PSCI 1.3
>>
>> Anirudh Rayabharam (Microsoft) (6):
>> accel/mshv: provision guests with the same features as host
>> accel/mshv: add arch-specific accelerator init hook
>> target/arm/mshv: add vCPU run loop
>> include/hw/hyperv: adjust hv_interrupt_control structure for arm64
>> hw/intc,target/arm/mshv: add MSHV vGICv3 implementation
>> MAINTAINERS: updates for MSHV arm64 code
>>
>> Magnus Kulke (1):
>> accel/mshv: implement cpu_thread_is_idle() hook
>>
>> MAINTAINERS | 8 +
>> accel/mshv/irq.c | 2 +
>> accel/mshv/meson.build | 4 +-
>> accel/mshv/mshv-all.c | 73 +++-
>> accel/mshv/mshv-cpu-common.c | 151 +++++++++
>> hw/arm/virt.c | 11 +-
>> hw/intc/arm_gicv3_common.c | 3 +
>> hw/intc/arm_gicv3_mshv.c | 180 ++++++++++
>> hw/intc/meson.build | 1 +
>> include/hw/hyperv/hvgdk_mini.h | 130 ++++++++
>> include/hw/hyperv/hvhdk.h | 97 +++++-
>> include/hw/hyperv/hvhdk_mini.h | 6 +
>> include/hw/intc/arm_gicv3_common.h | 1 +
>> include/system/hw_accel.h | 3 +-
>> include/system/mshv.h | 2 +
>> include/system/mshv_int.h | 5 +
>> meson.build | 7 +-
>> target/arm/cpu.c | 7 +-
>> target/arm/cpu64.c | 24 +-
>> target/arm/meson.build | 1 +
>> target/arm/mshv/meson.build | 7 +
>> target/arm/mshv/mshv-all.c | 665 +++++++++++++++++++++++++++++++++++++
>> target/arm/mshv_arm.h | 18 +
>> target/i386/mshv/meson.build | 2 +
>> target/i386/mshv/mshv-all.c | 85 +++++
>> target/i386/mshv/mshv-cpu.c | 170 +---------
>> {accel => target/i386}/mshv/msr.c | 0
>> 27 files changed, 1465 insertions(+), 198 deletions(-)
>> ---
>> base-commit: 1fd5ff9d76d23ab23a68419cbc76d5ee33e8b455
>> change-id: 20260311-mshv_accel_arm64_supp-e86b0082aee4
>>
>> Best regards,
>
> --
> Alex Bennée
> Virtualisation Tech Lead @ Linaro
>
On Wed, Mar 11, 2026 at 06:02:26PM +0100, Mohamed Mediouni wrote: > > > > On 11. Mar 2026, at 17:54, Alex Bennée <alex.bennee@linaro.org> wrote: > > > > "Anirudh Rayabharam (Microsoft)" <anirudh@anirudhrb.com> writes: > > > >> This series adds ARM64 guest support to the MSHV (Microsoft Hypervisor) > >> accelerator, enabling QEMU to run aarch64 VMs on Microsoft's hypervisor > >> using the mshv Linux kernel module. > > > > Does GitLab (or anything we plug into it) support runners on Arm64 with > > HyperV and a Linux Dom0? > > > > I looks like we would need a dedicated runner to defend the > > functionality on CI. > > > The MSHV license doesn’t allow for any use outside of Azure Kubernetes Service, > despite MSHV (for x86) being public. > > And Dom0 is technically not required as there’s L1VH, but that’s even less documented to > the outside and not set up for more local use - but hopefully will make its way to Windows > client at some point :/ Direct Virtualization (the marketing name for L1VH) will become generally available on Azure at some point (hopefully within this calendar year). I am not sure about Windows client though. Thanks, Wei
> On 11. Mar 2026, at 18:12, Wei Liu <wei.liu@kernel.org> wrote: > > On Wed, Mar 11, 2026 at 06:02:26PM +0100, Mohamed Mediouni wrote: >> >> >>> On 11. Mar 2026, at 17:54, Alex Bennée <alex.bennee@linaro.org> wrote: >>> >>> "Anirudh Rayabharam (Microsoft)" <anirudh@anirudhrb.com> writes: >>> >>>> This series adds ARM64 guest support to the MSHV (Microsoft Hypervisor) >>>> accelerator, enabling QEMU to run aarch64 VMs on Microsoft's hypervisor >>>> using the mshv Linux kernel module. >>> >>> Does GitLab (or anything we plug into it) support runners on Arm64 with >>> HyperV and a Linux Dom0? >>> >>> I looks like we would need a dedicated runner to defend the >>> functionality on CI. >> >> >> The MSHV license doesn’t allow for any use outside of Azure Kubernetes Service, >> despite MSHV (for x86) being public. >> >> And Dom0 is technically not required as there’s L1VH, but that’s even less documented to >> the outside and not set up for more local use - but hopefully will make its way to Windows >> client at some point :/ > > Direct Virtualization (the marketing name for L1VH) will become > generally available on Azure at some point (hopefully within this > calendar year). I am not sure about Windows client though. Hi, Could you ask if it’d be possible to have Windows client as an L1VH host, if even just Insider builds? Either as a Windows Hypervisor Platform privilege (even no save/restore is okay, just being able to enable the privilege is good enough for testing), or through HCS for WSL2 (or just Hyper-V VMs)? Because at this point that’d solve the testability issue… Thank you, -Mohamed > > Thanks, > Wei
On Thu, Mar 12, 2026 at 06:20:10AM +0100, Mohamed Mediouni wrote: > > > > On 11. Mar 2026, at 18:12, Wei Liu <wei.liu@kernel.org> wrote: > > > > On Wed, Mar 11, 2026 at 06:02:26PM +0100, Mohamed Mediouni wrote: > >> > >> > >>> On 11. Mar 2026, at 17:54, Alex Bennée <alex.bennee@linaro.org> wrote: > >>> > >>> "Anirudh Rayabharam (Microsoft)" <anirudh@anirudhrb.com> writes: > >>> > >>>> This series adds ARM64 guest support to the MSHV (Microsoft Hypervisor) > >>>> accelerator, enabling QEMU to run aarch64 VMs on Microsoft's hypervisor > >>>> using the mshv Linux kernel module. > >>> > >>> Does GitLab (or anything we plug into it) support runners on Arm64 with > >>> HyperV and a Linux Dom0? > >>> > >>> I looks like we would need a dedicated runner to defend the > >>> functionality on CI. > >> > >> > >> The MSHV license doesn’t allow for any use outside of Azure Kubernetes Service, > >> despite MSHV (for x86) being public. > >> > >> And Dom0 is technically not required as there’s L1VH, but that’s even less documented to > >> the outside and not set up for more local use - but hopefully will make its way to Windows > >> client at some point :/ > > > > Direct Virtualization (the marketing name for L1VH) will become > > generally available on Azure at some point (hopefully within this > > calendar year). I am not sure about Windows client though. > > Hi, > > Could you ask if it’d be possible to have Windows client as an L1VH host, if even just Insider builds? > > Either as a Windows Hypervisor Platform privilege (even no save/restore is okay, just being able > to enable the privilege is good enough for testing), or through HCS for WSL2 (or just Hyper-V VMs)? > I can pass on the question. Don't hold your breath though -- it is not something engineers decide. > Because at this point that’d solve the testability issue… I agree. The more accessible this technology is, the better. Wei
Hi Anirudh,
On 3/11/26 8:15 AM, Anirudh Rayabharam (Microsoft) wrote:
> This series adds ARM64 guest support to the MSHV (Microsoft Hypervisor)
> accelerator, enabling QEMU to run aarch64 VMs on Microsoft's hypervisor
> using the mshv Linux kernel module.
>
> The first few patches refactor the existing x86 MSHV code to separate
> arch-specific pieces from common infrastructure: moving MSR handling to
> target/i386, extracting shared register hypercall helpers, provisioning
> host CPU features, and introducing arch-specific init hooks.
>
> The remaining patches add the ARM64 backend:
> - vCPU state get/set using hypervisor register hypercalls
> - -cpu host support by querying ID registers from the hypervisor
> - vCPU run loop with MMIO emulation via ESR_EL2 syndrome decoding
> - In-kernel vGICv3 backed by HVCALL_ASSERT_VIRTUAL_INTERRUPT
> - Interrupt control structure adjustments for arm64
>
> With this series, a standard aarch64 virt machine can be launched with:
> qemu-system-aarch64 -accel mshv -cpu host -M virt ...
>
> Caveats:
> - Currently only direct kernel is supported. We're still debugging edk2
> firmware boot.
> - Live migration is not yet supported.
>
> ---
> Aastha Rawat (7):
> accel/mshv: move msr.c to target/i386
> accel/mshv: extract common CPU register helpers
> meson, target/arm/mshv: Enable arm64 build & add initial MSHV support
> target/arm/mshv: implement vcpu state operations for ARM64
> target/arm/mshv: implement -cpu host for MSHV
> accel/mshv: Add access_vp_regs synthetic proc features
> target/arm: cpu: Mark MSHV supporting PSCI 1.3
>
> Anirudh Rayabharam (Microsoft) (6):
> accel/mshv: provision guests with the same features as host
> accel/mshv: add arch-specific accelerator init hook
> target/arm/mshv: add vCPU run loop
> include/hw/hyperv: adjust hv_interrupt_control structure for arm64
> hw/intc,target/arm/mshv: add MSHV vGICv3 implementation
> MAINTAINERS: updates for MSHV arm64 code
>
> Magnus Kulke (1):
> accel/mshv: implement cpu_thread_is_idle() hook
>
> MAINTAINERS | 8 +
> accel/mshv/irq.c | 2 +
> accel/mshv/meson.build | 4 +-
> accel/mshv/mshv-all.c | 73 +++-
> accel/mshv/mshv-cpu-common.c | 151 +++++++++
> hw/arm/virt.c | 11 +-
> hw/intc/arm_gicv3_common.c | 3 +
> hw/intc/arm_gicv3_mshv.c | 180 ++++++++++
> hw/intc/meson.build | 1 +
> include/hw/hyperv/hvgdk_mini.h | 130 ++++++++
> include/hw/hyperv/hvhdk.h | 97 +++++-
> include/hw/hyperv/hvhdk_mini.h | 6 +
> include/hw/intc/arm_gicv3_common.h | 1 +
> include/system/hw_accel.h | 3 +-
> include/system/mshv.h | 2 +
> include/system/mshv_int.h | 5 +
> meson.build | 7 +-
> target/arm/cpu.c | 7 +-
> target/arm/cpu64.c | 24 +-
> target/arm/meson.build | 1 +
> target/arm/mshv/meson.build | 7 +
> target/arm/mshv/mshv-all.c | 665 +++++++++++++++++++++++++++++++++++++
> target/arm/mshv_arm.h | 18 +
> target/i386/mshv/meson.build | 2 +
> target/i386/mshv/mshv-all.c | 85 +++++
> target/i386/mshv/mshv-cpu.c | 170 +---------
> {accel => target/i386}/mshv/msr.c | 0
> 27 files changed, 1465 insertions(+), 198 deletions(-)
> ---
> base-commit: 1fd5ff9d76d23ab23a68419cbc76d5ee33e8b455
> change-id: 20260311-mshv_accel_arm64_supp-e86b0082aee4
>
> Best regards,
I have a question about MSHV itself.
Is it possible to get access to it through a Windows install, or a
custom binary or disk image, or is it not redistributed and available
only through Azure instances?
Regards,
Pierrick
© 2016 - 2026 Red Hat, Inc.