This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Re: [RFC] RAS(Part II)--MCA enalbing in XEN

To: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Subject: Re: [Xen-devel] Re: [RFC] RAS(Part II)--MCA enalbing in XEN
From: Frank van der Linden <Frank.Vanderlinden@xxxxxxx>
Date: Mon, 16 Mar 2009 10:27:06 -0600
Cc: Christoph Egger <Christoph.Egger@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Ke, Liping" <liping.ke@xxxxxxxxx>, Gavin Maltby <Gavin.Maltby@xxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, "Kleen, Andi" <andi.kleen@xxxxxxxxx>
Delivery-date: Mon, 16 Mar 2009 09:27:38 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <E2263E4A5B2284449EEBD0AAB751098401C7DCA95C@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C5BF30B3.2C2B%keir.fraser@xxxxxxxxxxxxx> <200903051828.33638.Christoph.Egger@xxxxxxx> <E2263E4A5B2284449EEBD0AAB751098401C7D2AB2F@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <200903102008.03034.Christoph.Egger@xxxxxxx> <E2263E4A5B2284449EEBD0AAB751098401C7DCA95C@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20081023)
Jiang, Yunhong wrote:
> Christoph Egger wrote:
I think, we should mark the 'struct mcinfo_global' as a kind of header for each error. All following information describe the error (including the follow-up errors) and all recover actions. This gives us the flexibility
to get as many information as possible and allows to do
as many recover actions as necessary instead of just one.

I think your original proposal can also meet such purpose, i.e. include the 
mc_recover_info and we still need pass all mc_bacnk infor to dom0 for 
telemetry. If you prefer this one, can you please define the interface? 
Gavin/Frank, do you have any idea for this changes?

Sorry about the slow reply.

Our changes to the MCE code (to combine the AMD and Intel code as much as possible, and use a transactional approach to the telemetry) already pretty much uses mc_global as a header. With our code, dom0 retrieves one mcinfo structure, with one global structure (which always comes first, but that's not required).

In other words, using mc_global as kind of a header to the mcinfo data is fine, since we're already doing that.

And, since we're talking about transactions with one mcinfo structure at a time (with one mc_global structure), the recover_info structures can be separate from the bank structures.

- Frank

Xen-devel mailing list