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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 23.02.18 at 11:07, <andrew.cooper3@xxxxxxxxxx> wrote:
> 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?

Otherwise the RDMSR wouldn't have failed.

> Irrespective, I think that entire block of MSRs wants blacklisting in
> the short term, to make them inaccessible.

That would deal with this particular issue in Linux, but nor the
general pattern.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel