Remaining MSR wrinkles

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

Hello,

There are a couple of remaining wrinkles related to MSR that I think we need to
solve before the release, or agree that it's fine to leave them as-is and
document in the release notes. I've tried to summarize the different views
below, sorry if I haven't done this properly or missed some arguments.

I'm sending to committers to see if we can find consensus on the path going
forward, or else to trigger a voting on the possible solutions, because
discussion on xen-devel seems to get stuck.

1. MSR behavior for PV guests without a #GP handler set: PV Linux versions <
   4.14 will use rdmsr_safe (and likely wrmsr_safe?) without having a #GP
   handler setup, which results in a crash. This bug was hidden in previous
   Xen releases by allowing unlimited read access to the MSR space.

   Jan has posted several proposals to address this:

   
https://lore.kernel.org/xen-devel/7e69db81-cee7-3c7b-be64-4f5ff50fbe9c@xxxxxxxx/
   
https://lore.kernel.org/xen-devel/d794bbee-a5e5-6632-3d1f-acd8164b7171@xxxxxxxx/

   Which all rely on the fact that for PV guests Xen knows whether there's a
   #GP handler setup and can hence prevent injection of a #GP fault if no
   handler is present.

   Andrew opinion is that we should instead try to figure out which MSRs the
   buggy Linux versions try to access and special case them. Andrew also raised
   the point that continue running with a 'fake' (ie: 0) MSR value might be
   worse than crashing.

   Part of the discussion has also happened here:

   
https://lore.kernel.org/xen-devel/4da62f0b-8a08-dd84-2040-fd55d74fd85a@xxxxxxxxxx/

   Look for the last quote.

   Another option is to document that PV Linux < 4.14 will require msr_relaxed=1
   in order to run. That as Jan pointed out will also imply PV Linux to run with
   a faked (0) MSR value instead of crashing.

2. RAPL_POWER_LIMIT: handle the MSR explicitly to make Solaris happy.
   Alternatively we can list in the release notes that Solaris guests require
   msr_relaxed=1. Andrew is working on a patch for this.

3. MSR_K8_HWCR: Linux will complain about a missing bit (TscFreqSel). Jan
   posted a patch to handle the MSR and unconditionally set the bit:

   
https://lore.kernel.org/xen-devel/c91b190a-aaa1-d3b8-10eb-d8da7ad1f834@xxxxxxxx/

   There are concerns from Andrew about missing bits in ACPI tables and Pstate
   MSRs if this bit is reported as set.

For 1. I do agree with Jan than this workaround is likely the best option we
have, sort of resorting to request enabling msr_relaxed for all Linux PV guests
< 4.14. Whether we want to limit this workaround to the read side only I'm not
fully convinced. There's something nice about having symmetry in the read and
write paths, but if all the calls we have identified are rdmsr only I prefer to
leave the write path unaltered and request users to use msr_relaxed if write
issues are found later.

For 3. I think I at least need more details about the relation with TscFreqSel
and ACPI or other MSRs, and I haven't been able to find it on the PPRs I
looked.

Thanks, Roger.