[Xen-devel] Ping: [PATCH] x86: ignore guest microcode loading attempts

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 13.03.18 at 12:51, <JBeulich@xxxxxxxx> wrote:
>>>> On 13.03.18 at 11:36, <andrew.cooper3@xxxxxxxxxx> 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@xxxxxxxx>
>>> ---
>>> 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.

Jan


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