[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [vMCE design RFC] Xen vMCE design
- To: "Jinsong Liu" <jinsong.liu@xxxxxxxxx>
- From: "Jan Beulich" <JBeulich@xxxxxxxx>
- Date: Fri, 22 Jun 2012 12:40:14 +0100
- Cc: Tony Luck <tony.luck@xxxxxxxxx>, Keir Fraser <keir@xxxxxxx>, Ashok Raj <ashok.raj@xxxxxxxxx>, Yunhong Jiang <yunhong.jiang@xxxxxxxxx>, Susie Li <susie.li@xxxxxxxxx>, Haitao Shan <haitao.shan@xxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, Donald D Dugger <donald.d.dugger@xxxxxxxxx>, Will Auld <will.auld@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Jun Nakajima <jun.nakajima@xxxxxxxxx>, Xiantao Zhang <xiantao.zhang@xxxxxxxxx>
- Delivery-date: Fri, 22 Jun 2012 11:39:44 +0000
- List-id: Xen developer discussion <xen-devel.lists.xen.org>
>>> 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
>> 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
> 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
> 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.
>> 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
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?
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?
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
Xen-devel mailing list