Hi Peter,

On 08/09/17 16:03, Peter Maydell wrote:

On 8 September 2017 at 15:34, gengdongjiu [off-list ref] wrote:

quoted

Hi Peter/ shenglong,
   What is your idea about it? We may need to consult with you about it.

I agree with what I take to be James' general point that we
should be careful to distinguish "KVM supports API A to
do a particular operation on the guest" and "KVM supports API
B to tell QEMU about certain events" and so on, and not just
lump these all together under "host CPU supports RAS and
so we turn all these on together and expose RAS to the guest
regardless". I don't know enough about the details of RAS
to be more specific than that general point of view.

I think the question is 'when should qemu/kvmtool generate a HEST'.

The answer certainly doesn't depend on the CPU RAS extensions, with firmware
first these are just one mechanism to kicking RAS-errors up into firmware.
Firmware may have other ways of doing this, and other non-CPU components that
can generate errors.

User-space can generate a HEST for the guest whenever it thinks it might have to
describe an error to a guest, either totally emulated, or because it can handle
memory-failure notification.


The real question is 'which APEI GHES notification methods you can support for
this guest'. So far x86's NMI, and arm64's SEI or SDEI mechanisms require help
from KVM. But without any of these the Polled and (numerous) IRQ notifications
will still work.


Thanks,

James