[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2] x86/HVM: don't give the wrong impression of WRMSR succeeding

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 <jbeulich@xxxxxxxx>

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.