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.


Xen-devel mailing list

Reply via email to