Re: [Qemu-devel] 答复: using which notification for guest about GHES error

[Laszlo Ersek <lersek@redhat.com>]

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 <gengdongjiu@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