[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] RFC: MCA/MCE concept
> -----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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |