[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <4FE4B16C020000780008B7A6@nat28.tlf.novell.com>
Date: Fri, 22 Jun 2012 16:54:52 +0100
From: "Jan Beulich" <JBeulich@...e.com>
To: "Jinsong Liu" <jinsong.liu@...el.com>,
"Tony Luck" <tony.luck@...el.com>
Cc: "Ashok Raj" <ashok.raj@...el.com>,
"Donald D Dugger" <donald.d.dugger@...el.com>,
"Haitao Shan" <haitao.shan@...el.com>,
"Jun Nakajima" <jun.nakajima@...el.com>,
"Susie Li" <susie.li@...el.com>, "Will Auld" <will.auld@...el.com>,
"Xiantao Zhang" <xiantao.zhang@...el.com>,
"Yunhong Jiang" <yunhong.jiang@...el.com>,
"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Keir Fraser" <keir@....org>
Subject: RE: [vMCE design RFC] Xen vMCE design
>>> On 22.06.12 at 17:29, "Luck, Tony" <tony.luck@...el.com> wrote:
>> 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.
>
> Don't you control what CPUID is shown to the guest? Under what circumstances
> would you tell the guest that it is running on an AMD-K7 or an Intel family
> 6 with model < 0x1A? Surely for migration reasons you need to present the
> same virtualized family/model all the time ... so just don't use ones that
> cause problems.
I don't think family/model/stepping are frequently faked, it's
normally just the various feature flags that get normalized to
the smallest common set.
> If that isn't an option - then say there are 2 banks and have Xen ignore bank
> 0 (make MC0_STATUS always appear to contain 0) and put all the errors into
> bank1. If you tell the guest there are 32 banks it will read all of them.
> Which means a lot of pointless exits to the hypervisor.
Indeed, emulating too many banks can have its own downsides.
Yet I don't think we're really concerned about performance when
handling machine checks. But having more than one usable bank
must have advantages, else hardware wouldn't implement things
that way.
Jan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists