On 04/04/2023 3:50 pm, Jan Beulich wrote: > This insn differs from WRMSR solely in the lack of serialization. Hence > the code used there can simply be used here as well, plus a feature > check of course.
I have a feeling this is a bit stale now that 0f01.c has moved into a separate file ? > As there's no other infrastructure needed beyond > permitting the insn for PV privileged-op emulation (in particular no > separate new VMEXIT) we can expose the insn to guests right away. There are good reasons not to expose this to PV guests. The #GP fault to trigger emulation is serialising, so from the guest's point of view there is literally no difference between WRMSR and WRMSRNS. All code is going to need to default to WRMSR for compatibility reasons, so not advertising WRMSRNS will save the guest going through and self-modifying itself to use a "more efficient" instruction which is not actually more efficient. But, in general and as said before, I feel it is irresponsible to be continuing to add slow guest-fastpaths without introducing a real fastpath. We desperately need HYPERCALL_pv_priv_op which can take an array of inputs, and has an sub-op for each of CPUID, RDMSR, WRMSR and whatever other ops are trapping because of no fastpath. Perf testing routinely shows that #GP/#UD faults are only 2 orders of magnitude less rare in PV guests than #PF, which is an insane wastage when guests are supposed to be enlightened and use fastpaths in the first place. The emulation implementation is fine, so Reviewed-by: Andrew Cooper <andrew.coop...@citrix.com> but dependent on the PV guest changes being dropped. ~Andrew
