Hi Peter, On 08/09/17 16:03, Peter Maydell wrote: > On 8 September 2017 at 15:34, gengdongjiu <gengdongjiu@xxxxxxxxxx> wrote: >> 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 _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
