On Thu, Aug 28, 2025 at 10:48:49AM +0200, Jan Beulich wrote: > On 28.08.2025 03:22, Jason Andryuk wrote: > > The MCA hypercall, do_mca(), is only available for PV. That is, it's > > only added to the hypercall table for PV. Is there a particular reason > > it was omitted from PVH, or did PVH dom0 just not exist? > > PVH Dom0 didn't exist back at the time, yes, but it's more than this. The > hypercall, in some places, deals with MFNs, which aren't "visible" to PVH > Dom0. IOW enabling it (perhaps just partly) would need to be done with > extra care.
I think there's also a question of whether we want to use a PV interface here, or try for Xen to mediate between the hardware domain and the native interface, possibly exposing some kind of partially emulated view that matches the native interface, and thus avoids having to use a PV driver in the hardware domain. I've opened a GitLab ticket long ago about MCE: https://gitlab.com/xen-project/xen/-/issues/101 But didn't look into it. I think we need some prior investigation to figure out whether it would be feasible to expose a native MCA interface to the hardware domain, as that would be the preference for PVH (rather than re-using the classic PV interfaces). The main barrier here is the disassociation between the hardware domain physical memory map versus the host one, as the MCE/MCA drivers will need to operate based on the host memory map, not the one used by the hardware domain. I think (some?) of the MSRs also contain CPU specific status/errors, and hence using a native interface would require the hardware domain vCPU count to be equal to the host pCPU count. Nit: I've just taken a quick look at do_mca() but it looked like the sharing of the data would be better done using acquire_resource if possible, as to avoid repeated hypercalls. Thanks, Roger.
