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

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

On Thu, Mar 04, 2021 at 03:20:34PM +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 02:59:38PM +0000, Ian Jackson wrote:
> > > I think it's almost as bad to have guests which can be migrated in,
> > > but which then cannot reboot.
> > 
> > Ups, yes, right.
> > 
> > > Historically we have taken the view that new Xen must support old
> > > guests, even if that means being bug-compatible.  So I am strongly in
> > > favour of avoiding such a usability regression.
> > 
> > I'm not a xl/libxl expert, but couldn't we set the option in a
> > persistent way for migrated-in guests?
> > 
> > IIRC at domain creation libxl knows whether it's a restore or a fresh
> > domain, and hence we could set the option there?
> > 
> > The part I'm not sure is about how to make it persistent.
> 
> 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.

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.

Thanks, Roger.