Re: [PATCH v3 for-4.15] x86/msr: introduce an option for compatible MSR behavior selection

[Ian Jackson <iwj@xxxxxxxxxxxxxx>]

Roger Pau Monne writes ("[PATCH v3 for-4.15] x86/msr: introduce an option for 
compatible MSR behavior selection"):
> Introduce an option to allow selecting a behavior similar to the pre
> Xen 4.15 one for accesses to MSRs not explicitly handled. Since commit
> 84e848fd7a162f669 and 322ec7c89f6640e accesses to MSRs not explicitly
> handled by Xen result in the injection of a #GP to the guest. This
> is a behavior change since previously a #GP was only injected if
> accessing the MSR on the real hardware would also trigger a #GP, or if
> the attempted to be set bits wouldn't match the hardware values (for
> PV). The reasons for not leaking hardware MSR values and injecting a
> #GP are fully valid, so the solution proposed here should be
> considered a temporary workaround until all the required MSRs are
> properly handled.
> 
> This seems to be problematic for some guests, so introduce an option
> to fallback to this kind of legacy behavior without leaking the
> underlying MSR values to the guest.
> 
> When the option is set, for both PV and HVM don't inject a #GP to the
> guest on MSR read if reading the underlying MSR doesn't result in a
> #GP, do the same for writes and simply discard the value to be written
> on that case.
> 
> Note that for guests restored or migrated from previous Xen versions
> the option is enabled by default, in order to keep a compatible
> MSR behavior. Such compatibility is done at the libxl layer, to avoid
> higher-level toolstacks from having to know the details about this flag.
> 
> Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> Acked-by: Christian Lindig <christian.lindig@xxxxxxxxxx>
> Reviewed-by: Ian Jackson <iwj@xxxxxxxxxxxxxx>
> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
...
> >From a release PoV there are risks of taking this patch, as it touches
> several different areas. So it could break MSR handling or domain
> creation. I think however we would be able to spot such breakages in
> osstest.
> 
> Not taking the patch would put us in an awkward position if people
> migrating from < 4.15 find their guests no longer boot (or crash on
> migration) on newer Xen versions, hence I think we need to accept the
> risk.

Thanks.  Yes.  I agree.

Release-Acked-by: Ian Jackson <iwj@xxxxxxxxxxxxxx>