RE: [Xen-devel] RFC: MCA/MCE concept

["Petersson, Mats" <Mats.Petersson@xxxxxxx>]

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Christoph Egger
> Sent: 21 June 2007 10:29
> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> Cc: Gavin Maltby; Jan Beulich
> Subject: Re: [Xen-devel] RFC: MCA/MCE concept
> 
> On Thursday 14 June 2007 13:59:12 Gavin Maltby wrote:
> > On 06/06/07 10:28, Christoph Egger wrote:
> > > On Monday 04 June 2007 18:16:56 Gavin Maltby wrote:
> > >> In terms of the form of the error event data, the 
> simplest but also
> > >> the dumbest would be a binary structure passed from hypervisor
> > >> to dom0:
> > >
> > > struct mca_error_data_ver1 {
> > >   uint8_t version;        /* structure version */
> > >   uint64_t mc_status;
> > >   uint64_t mc_addr;
> > >   uint64_t mc_misc;
> > >   uint16_t mc_chip;
> > >   uint16_t mc_core;
> > >   uint16_t mc_bank;
> > >         uint16_t domid;
> > >         uint16_t vcpu_id;
> > >   ...
> > > };
> >
> > Since there are multiple MCA detector banks, and more than
> > one may have logged a valid error, we need to think about
> > communicating all the bank error telemetry.  This should
> > also allow for there being varying numbers of MCA banks in
> > different proccessor types.  So something like
> >
> > struct {
> >     uint8_t version;
> >     uint8_t nbanks;
> >     uint16_t flags;
> >     uint16_t domid;
> >     uint16_t vcpud_id; /* if meaningful? */
> >     uint8_t chipid;
> >     uint8_t coreid;
> >     uint64_t mcg_status;
> >     struct {
> >             mc_status;
> >             mc_addr;
> >             mc_misc;
> >     } bank[1];
> > };
> >
> > The bank array is actually sized as per nbanks.
> >
> > I've added mcg_status and flags.  The latter I'd like to use
> > for indicators such as "this error data was artificially injected"
> > etc.
> 
> Here is my proposal for a real exensible event structure:
> 
> #define MCA_TYPE_COMMON  0
> #define MCA_TYPE_BANK         1
> #define MCA_TYPE_ALLBANKS 2
> ...
> 
> #define MCA_COMMON     \
>      size_t size;  /* size of this struct in bytes */
>      uint32_t type; /* structure type */
>      uint16_t domid;
>      uint8_t chipid;
>      uint8_t coreid;
>      uint64_t mcg_status; /* global status */

At this point, I'd love it if gcc supported unnamed structs! [Which it does 
only with -fms-extensions]. 

That would make this sort of thing so much neater. 

> 
> 
> The base structure:
> 
> struct mca_event {
>      MCA_COMMON;
> };
> 
> 
> The specific structs:
> 
> struct mca_event_bank {
>    MCA_COMMON;
> 
>    uint16_t vcpu_id;
>    uint16_t mc_bank;
>    uint64_t mc_status;
>    uint64_t mc_addr;
>    uint64_t mc_misc;
>    uint32_t flags;
> };
> 
> struct mca_event_allbanks {
>    MCA_COMMON;
> 
>    uint16_t vcpud_id;
>    uint8_t nbanks;
>    uint32_t flags;
>    struct {
>       uint64_t mc_status;
>       uint64_t mc_addr;
>       uint64_t mc_misc;
>    } bank[1];
> };
> 
> And you can have many more structs to support future features.
> 
> In the code you allocate the size of the struct you want to use:
> 
>      struct mca_event *mca = malloc(sizeof(struct mca_event_bank));
>      mca->size = sizeof(struct mca_event_bank);
>      mca->type = MCA_TYPE_BANK;
> 
> in this example you can cast from mca_event to mca_event_bank
> and back whenever you like.
> The generic code only needs to know struct mca_event.
> 
> Christoph
> 
> 
> -- 
> AMD Saxony, Dresden, Germany
> Operating System Research Center
> 
> Legal Information:
> AMD Saxony Limited Liability Company & Co. KG
> Sitz (Geschäftsanschrift):
>    Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
> Registergericht Dresden: HRA 4896
> vertretungsberechtigter Komplementär:
>    AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
> Geschäftsführer der AMD Saxony LLC:
>    Dr. Hans-R. Deppe, Thomas McCoy
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel