On 23/02/2018 08:36, Jan Beulich wrote:
> ... for non-existent MSRs: wrmsr_hypervisor_regs()'s comment clearly
> says that the function returns 0 for unrecognized MSRs, so
> {svm,vmx}_msr_write_intercept() should not convert this into success. We
> don't want to unconditionally fail the access though, as we can't be
> certain the list of handled MSRs is complete enough for the guest types
> we care about, so instead mirror what we do on the read paths and probe
> the MSR to decide whether to raise #GP.
>
> Signed-off-by: Jan Beulich <jbeul...@suse.com>I'm not a fan of this approach, but I accept that it might be the least bad option going. However, I'm struggling to understand how it resolves the issue you presented? In the example, Linux did a wrmsr_safe() then blew up on a rdmsr(). Was that in fact running on hardware lacking PSR/QoS support? Irrespective, I think that entire block of MSRs wants blacklisting in the short term, to make them inaccessible. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
