RE: [vMCE design RFC] Xen vMCE design

[Liu, Jinsong]

Jan Beulich wrote:
>>>> On 22.06.12 at 12:40, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx> wrote:
>> Jan Beulich wrote:
>>>>>> On 20.06.12 at 18:13, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx>
>>>>>> wrote: 
>>>> Recently we design xen vMCE as attached.
>>>> Please kindly help me to review it, any comments/suggestions are
>>>> appreciated.
>>> 
>>> The concept looks quite okay, provided no OS has a problem with
>>> the limitations imposed (most notably the restriction to a single
>>> reporting bank, particularly in the context of e.g. Linux partly
>>> ignoring the first bank under some conditions iirc).
>> 
>> 'bank0 skipping' quirks is only for older model cpus, I think we
>> have 2 options: 1). still use 1 bank and simply ignore this issue. I
>> mean, even if guest runs at bank0 quirks platform, when hypervisor
>> inject vMCE# to guest, guest skip bank0, then guest MCE logic would
>> think it detect a spurious mce, then kill itself. Considering bank0
>> quirks is only for old cpus, this is acceptable; 2). use 32 banks
>> 
>> In fact, a third option is, use 1 bank, but hypervisor kill guest
>> when it detect bank0 quirks. This would be same effect as option 1,
>> so I prefer let guest kill itself.
> 
> Out of these, I'd actually favor using 32 banks. Using 2 banks
> instead of 1 might be another option.

Yes, 2 or 32 are both OK. Let's use 32.
(or, 2 is better for some other reasons, let me confirm inside Intel first).

> 
>>> As to not needing any migration specific adjustments - what if
>>> a migration is in progress when an event needs to be delivered?
>> 
>> If a migration is in progress while an event delivered, we abort the
>> migration.
> 
> Is there a way the hypervisor can tell the tools to abort a
> migration? Or are you meaning to say such functionality would
> need to be added?

I didn't check migration code, but I think it could be done by
1). set a flag indecating the case 'migration is in progress while event delivered'.
2). at the last shakehand stage of migration (i.e. A to B), checking the flag and if yes, abort migration.
So guest will continue run at A, and quit at B after timeout.

> 
> One other concern that occurred to me after long having sent
> the original response: Your proposal aims at a fixed,
> unmodifiable vMCE interface. How is that going to be forward
> compatible? I.e. consider you had made that proposal before
> the SRAO/SRAR changes went in - would the same interface (with
> the same set of capability bits set/clear) still be suitable?

Yes, since it's pure s/w emulated interface. At the case when SRAO or SRAR not supported by h/w platform, it's still OK, since under such case hypervisor don't need deliver SRAO or SRAR to guest at all. The emulated vMCE interface just tell the guest that it runs at a virtual platform with those well-defined capabilities.

> 
> I think that we minimally need to retain the MCG_CAP register
> as being of potentially variable content (and hence needing
> saving/restoring on migration). To support this in a forward
> compatible manner, we may have to have a way to tell the
> hypervisor e.g. via command line option which extra MSRs
> have to be treated read-as-zero/writes-ignored upon guest
> accesses.
> 
> Jan

Seems unnecessary, reason as above.

Thanks,
Jinsong


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/