Re: [PATCH 00/10] Support QEMU cpu models in MSHV accelerator

[Magnus Kulke <magnuskulke@linux.microsoft.com>]

On Mon, Mar 02, 2026 at 07:34:21PM +0100, Paolo Bonzini wrote:
> Hi Magnus,
> 
> I went back to reviewing this series.
> 
> More or less, using "-cpu host" should work because MSHV already runs in a
> partition.  Therefore, it should be safe to assume that whatever bits were
> allowed in the current partition's CPUID will also be allowed in the nested
> guest.
> 
> However, you still need to mask the features corresponding to MSRs that you
> do not save/restore; this includes for example TSC deadline timer, AMX
> (XFD), FRED, PMU, UMWAIT are the first few that came to mind.  Or
> alternatively, just add them to get/put_msrs.
> 

Hey Paolo,

thanks for taking a look at this. I am currently staging follow up
patch-sets in which the MSR handling is reworked as part of the live
migration support. In those there will be more MSRs that are being
covered in a migration, using a hardcoded list in rust-vmm/mshv as
base, with some additional ones added:

https://docs.rs/crate/mshv-ioctls/0.6.7/source/src/ioctls/system.rs#363

in the future I think we want to have a MSHV_GET_SUPPORTED_MSRS ioctl
that we can query, similar to what's available for KVM.

There are "hv_partition_processor_features" that we query from the
hypervisor to filter out MSRs that are not available for a given
partition, e.g.

		uint64_t tsc_adjust_support:1;

> Later on, we probably want to share some of the code to handle MSRs between
> Hyper-V and KVM.  Please add some comments about the hypercalls, since they
> are poorly documented, explaining how to find out which MSRs are supported
> by the hypervisor.
> 

If the hypercalls are not documented, we probably want to fix it either
in the rust-vmm/mshv create (which at the moment provides authorative
headers (until we have moved everything to the mshv uapi headers), but
i'll double check.

> With respect to live migration, here are a few bits of states that should be
> migrated:
> 
> - the FPU registers (MshvFPU is dead code and can be removed; I missed it
> during my initial review).

yup, the FPU registers handling has also been reworked a bit to
accomodate XSAVE migration.

> 
> - the PDPTRs.  That is probably okay (because you never set nor read
> env->pdptrs_valid) but please check if Hyper-V supports reading them.
> 

I'll try to find that out. Haven't stumbled over this so far, but I
understand it's relevant for 32bit PAE guest, which we probably haven't
tested thoroughly yet.

> - KVM also has support for migrating in the middle of an exception being
> delivered (for example if an EPT violation happens due to a write to the
> stack); this is handled with fields such as these:
> 
>         VMSTATE_UINT8(env.exception_pending, X86CPU),
>         VMSTATE_UINT8(env.exception_injected, X86CPU),
>         VMSTATE_UINT8(env.exception_has_payload, X86CPU),
>         VMSTATE_UINT64(env.exception_payload, X86CPU),
>         VMSTATE_INT32(env.exception_nr, X86CPU),
>         VMSTATE_INT32(env.interrupt_injected, X86CPU),
>         VMSTATE_UINT8(env.soft_interrupt, X86CPU),
>         VMSTATE_UINT8(env.nmi_injected, X86CPU),
>         VMSTATE_UINT8(env.nmi_pending, X86CPU),
> 
> please check how Hyper-V handles this situation so that it can be
> implemented in QEMU as well.
> 

Those are covered in MSHV's "vCPU Events", I think they map quite
cleanly to the QEMU representation:

https://docs.rs/mshv-bindings/0.6.7/src/mshv_bindings/x86_64/regs.rs.html#404

thanks,

magnus