Re: Ping: [PATCH] x86: ignore guest microcode loading attempts

[Sergey Dyasli <sergey.dyasli@citrix.com>]

On Thu, 2018-03-15 at 02:37 -0600, Jan Beulich wrote:
> > > > On 13.03.18 at 12:51, <JBeulich@suse.com> wrote:
> > > > > On 13.03.18 at 11:36, <andrew.cooper3@citrix.com> wrote:
> > > 
> > > On 13/03/2018 10:13, Jan Beulich wrote:
> > > > The respective MSRs are write-only, and hence attempts by guests to
> > > > write to these are - as of 1f1d183d49 ("x86/HVM: don't give the wrong
> > > > impression of WRMSR succeeding") no longer ignored. Restore original
> > > > behavior for the two affected MSRs.
> > > > 
> > > > Signed-off-by: Jan Beulich <jbeulich@suse.com>
> > > > ---
> > > > While what is being logged for the current osstest failure on the 4.7
> > > > branch (I have to admit that I don't understand why it's only that
> > > > branch which shows a regression)
> > > 
> > > Differences in advertised viridian?
> > > 
> > > >  doesn't fully prove this to be the
> > > > problem, RCX holding 0x79 and there being a recorded hypervisor level
> > > > #GP recovery immediately before the guest triple fault is sufficient
> > > > indication imo.
> > > > What I'm unsure about is whether we want to ignore such writes also for
> > > > PV guests. If not, at least the WRMSR change would need to move into
> > > > hvm/hvm.c.
> > > 
> > > Hmm - I'd very much like not to make this change, because it sets a bad
> > > precedent for making the MSR handling sane.  We shouldn't be silently
> > > dropping MSR writes, as that will cause more problems for the guests,
> > > rather than less.
> > > 
> > > Given that it is appears to be just 4.7 which is affected, I think it is
> > > worth trying to work out what is causing 4.8 and later to be fine, and
> > > whether that is a better solution to backport.
> > 
> > The latest flight on 4.9 shows the same issue.
> 
> I realize it's generally too early for a ping, but with at least two of
> the stable trees now blocked on this (and specifically the ones we
> want to cut a release from soon), I'd really like to either see this
> patch acked or viable alternative proposals be made. FTR, I don't
> think reverting the change that caused the issue to surface is an
> option: We had specifically agreed to deal with fallout on a case by
> case basis.
> 
> From the pattern of the failures it's only a matter of time for other
> branches to also become blocked on this.

SDM states that this MSR is architectural and hence should always be
available to a guest. I couldn't find any information about how a #GP
fault may be raised during wrmsr or what happens if microcode update
fails. Looks like the guest should just check the resulting value in
MSR_IA32_UCODE_REV (which can be emulated by Xen).

Overall, the patch looks sensible to me. The only thing I would like to
see is some code comments about why this wrmsr is silently dropped.

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