[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: Thoughts on current Xen EDAC/MCE situation
On 22.01.2024 21:53, Elliott Mitchell wrote: > I've been mentioning this on a regular basis, but the state of MCE > handling with Xen seems poor. I certainly agree here. > I find the present handling of MCE in Xen an odd choice. Having Xen do > most of the handling of MCE events is a behavior matching a traditional > stand-alone hypervisor. Yet Xen was originally pushing any task not > requiring hypervisor action onto Domain 0. Not exactly. Xen in particular deals with all of CPU and all of memory. Dom0 may be unaware of the full amount of CPUs in the system, nor the full memory map (without resorting to interfaces specifically making that information available, but not to be used for Dom0 kernel's own acting as a kernel). > MCE seems a perfect match for sharing responsibility with Domain 0. > Domain 0 needs to know about any MCE event, this is where system > administrators will expect to find logs. In fact, if the event is a > Correctable Error, then *only* Domain 0 needs to know. For a CE, Xen > may need no action at all (an implementation could need help) and > the effected domain would need no action. It is strictly for > Uncorrectable Errors that action beside logging is needed. > > For a UE memory error, the best approach might be for Domain 0 to decode > the error. Once Domain 0 determines it is UE, invoke a hypercall to pass > the GPFN to Xen. What GPFN? Decoding can only possibly find machine addresses in what hardware supplies. > Xen would then forcibly unmap the page (similar to what > Linux does to userspace for corrupted pages). Xen would then identify > what the page was used for, alert the domain and return that to Domain 0. Some of this is already in place. How well it functions is a different question. > The key advantage of this approach is it makes MCE handling act very > similar to MCE handling without Xen. While that's true, you're completely omitting all implications towards what it means to hand off most handling to Dom0. While it is perhaps possible to make Linux'es chipset-specific EDAC drivers Xen PV aware, it might be yet harder to achieve the same in a PVH Dom0. > Documentation about how MCEs are > reported/decoded would apply equally to Xen. Another rather important > issue is it means less maintenance work to keep MCE handling working with > cutting-edge hardware. I've noticed one vendor being sluggish about > getting patches into Linux and I fear similar issues may apply more > severely to Xen. With all of your suggestions: Who do you think is going to do all of the work involved here (properly writing down a design, to take care of all known difficulties, and then actually implement everything)? We're already short on people, as you're very likely aware. Jan
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |