Re: [PATCH v2 for-4.15] x86/msr: introduce an option for HVM relaxed rdmsr behavior

From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Ian Jackson <iwj@xenproject.org>
Cc: <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
	Anthony PERARD <anthony.perard@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Kevin Tian <kevin.tian@intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [PATCH v2 for-4.15] x86/msr: introduce an option for HVM relaxed rdmsr behavior
Date: Thu, 4 Mar 2021 18:43:35 +0100	[thread overview]
Message-ID: <YEEcR/Jb5TgI31rY@Air-de-Roger> (raw)
In-Reply-To: <24641.5419.379341.215528@mariner.uk.xensource.com>

On Thu, Mar 04, 2021 at 05:13:15PM +0000, Ian Jackson wrote:
> Roger Pau Monné writes ("Re: [PATCH v2 for-4.15] x86/msr: introduce an option for HVM relaxed rdmsr behavior"):
> > On Thu, Mar 04, 2021 at 03:20:34PM +0000, Ian Jackson wrote:
> > > The guest could be stopped with xl shutdown and then recrated with xl
> > > create, from the config file.  I don't think we want to break that use
> > > case here either.
> > 
> > So my original approach was to actually risk breaking creation from
> > config file and require the user to set the rdmsr_relaxed option, and
> > report the problem upstream. I think ideally we would like to get to a
> > point where we could drop the rdmsr_relaxed option, but maybe that's
> > too optimistic.
> 
> Isn't there some way we can move in this direction without the first
> thing that users experience being their guests not being able to be
> created ?
> 
> Maybe we could print a warning on the console or something ?

I (sadly) fear unless you get a guest crash no-one will ever look at
the logs and notice those messages.

> > We have done quite a lot of testing of this new policy, but obviously
> > it's not possible to test all possible guest OSes. Forcing the new
> > policy by default might be too risky, so indeed falling back to
> > enabling this by default could be the only solution.
> > 
> > The main downside of enabling by default is that then we have to
> > resign to always having this kind of quirky behavior for MSR
> > accesses as the default.
> 
> What would stop us changing the default later, when we had a better
> idea of the set of RDMSRs that need to be special-cased ?

We could. From the Citrix side I'm afraid there's not much more
testing that we can do however. We tested the new policy against all
possible guests known by XenRT, but obviously that's not every
possible OS.

One option we could go for is making this behavior depend on Kconfig:
enable strict MSR policy for debug builds and fallback to the
'relaxed' one for non-debug builds. That might get us some more data,
but again I fear most people out there will run non-debug builds
anyway.

Thanks, Roger.