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
