On 02/03/2010 09:49 AM, Kleen, Andi wrote:
Yeah, but if we put a feature in qemu, we need to be able to
support it
for anyone who wants to use it.
It's useful for anyone who wants to use it for testing purposes.
And it's useful to make sure the qemu/kernel/kvm machine check
injection code works.
Adding something for a very particular test suite that won't work in
normal circumstances is just asking for trouble IMHO.
RAS features generally need associated testing/injection hooks,
otherwise they don't get tested regularly enough and bitrot.
I still don't really understand all the pieces that are
involved here.
Why do we need a guest physical address? Are we testing
reflecting MCEs
>from the host into a guest? Since that functionality isn't in qemu
aren't we putting the cart before the horse here?
qemu has support for triggering MCEs on the monitor.
Also the KVM code base has support for forwarding the MCEs automatically.
KVM has all of the information you need (guest physical -> host physical
mapping). It can also pin the mapping making it much safer to interface
at that level. You should probably add an ioctl interface to KVM to get
a host physical from a given guest physical and then use that to do the
MCE injection. You would need to write a little helper tool and you
would need a way to get an fd for an existing guest.
Regards,
Anthony Liguori
But then it's not a user visible interface.
-Andi