On 10/16/17 18:59, James Morse wrote: > Hi gengdongjiu, Igor, > > On 16/10/17 15:33, gengdongjiu wrote: >>> On Mon, 16 Oct 2017 14:10:05 +0800 >>> gengdongjiu <gengdong...@huawei.com> wrote: >>>> Now we use Qemu to create APEI table and record CPER for guest, After >>>> QEMU recorded a asynchronous CPER error, we needs to notify guest using >>>> interrupt or Polled notification. >>>> For the asynchronous error. I think using GPIO-signaled notification may >>>> be better in the Qemu, and also which is suggested by APEI spec. >>>> James worried that old guest OS may not support GPIO or GSIV notification >>>> for GHES, because GPIO or GSIV notification is supported in OS >>> since about kernel version 4.10. >>> >>> How APEI support is fairly new on ARM (kernel), isn't it still in state of >>> development? > > The NMI-like notifications, (SEA, SEI, SDEI) are still being worked on, but > the > less exotic Polled and many-flavours-of-interrupt should have exactly the same > meaning/behaviour as on x86. (it should be possible to emulate/configure these > with common user-space code too) > > >>> Do we really care about old guests in this case? > > I think the scenario here is the host kernel has some RAS support, Qemu has > RAS > support and has advertised its CPER regions via the HEST, but the guest > doesn't > doesn't support RAS. (booted via DT, wasn't configured for APEI, the kernel > pre-dates the support etc). > > What should Qemu do in response to 'action optional' memory errors? > > My suggestion is whatever action Qemu takes, it shouldn't kill a guest that > doesn't support RAS. Using NOTIFY_SEI for an action-optional memory error will > do this. A guest that doesn't know about NOTIFY_SEI will take this as a fatal > SError.
As far as I understand, this QEMU feature is not enabled by default; it takes at least one specific -device option (maybe some other options too). If that's the case, then adding the option, and then seeing a guest (without supporting the feature) hang itself, is okay. It is no different from the guest OS lacking drivers for other important -- such as boot -- devices, such as virtio drivers in general, or virtio-1.0 drivers for modern-only virtio devices. Such knowledge (= what OS has built-in drivers or other kind of support for what devices) is maintained in libosinfo. > I think you shouldn't expect host kernel, guest kernel and Qemu version to all > pair up nicely. If I understand correctly, the things that are expected to match up are: - guest kernel (more generally, guest OS image), - and QEMU command line (more generally, virtual hardware configuration). Just my two cents anyway; I haven't been following this discussion closely. Thanks Laszlo
