linux-kernel - RE: [vMCE design RFC] Xen vMCE design

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 22 Jun 2012 16:21:17 +0000
From:	"Luck, Tony" <tony.luck@...el.com>
To:	Jan Beulich <JBeulich@...e.com>,
	"Liu, Jinsong" <jinsong.liu@...el.com>
CC:	"Raj, Ashok" <ashok.raj@...el.com>,
	"Dugger, Donald D" <donald.d.dugger@...el.com>,
	"Shan, Haitao" <haitao.shan@...el.com>,
	"Nakajima, Jun" <jun.nakajima@...el.com>,
	"Li, Susie" <susie.li@...el.com>,
	"Auld, Will" <will.auld@...el.com>,
	"Zhang, Xiantao" <xiantao.zhang@...el.com>,
	"Jiang, Yunhong" <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

> 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.

Primary reason for multiple banks is h/w design ... the silicon implementing the bank
is generally included in the component that generates the error. E.g. there may be
multiple memory controllers on a die, each with its own bank. H/W designers hate
running long "wires" across the die as it messes up their layout options.

There may be some secondary side benefit that independent errors might be
reported to different banks, and so avoid some overwrite problems.  But I don't
think that Xen has a big worry with overwrite, does it? In general the errors that
you will show to the guest are ones that you expect the guest to handle immediately
(e.g. SRAO and SRAR signaled with a machine check). You do not log any corrected
errors to the guest (they can't do anything useful with them). You certainly don't
log any errors that are not signaled. So you should never have any errors hanging
around in banks for long periods that would get overwritten.

-Tony
--
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/