On Mon, 2011-01-17 at 15:11 +0800, Jan Kiszka wrote: > On 2011-01-17 01:54, Huang Ying wrote: > > On Sat, 2011-01-15 at 17:00 +0800, Jan Kiszka wrote: > >> From: Jan Kiszka <jan.kiszka@xxxxxxxxxxx> > >> > >> This case is a pure user space error we do not need to record. Moreover, > >> it can be misused to flood the kernel log. Remove it. > > > > I don't think this is a pure user space error. This happens on real > > hardware too, if the Machine Check exception is raised during early boot > > stage or the second MC exception is raised before the first MC exception > > is processed/cleared. > > > > So I use printk here to help debugging these issues. > > > > To avoid flooding the kernel log, we can use ratelimit. > > With user space I meant qemu, and maybe "error" was the wrong term. This > code path is only triggered if qemu decides to. Not only decided by qemu, but also decided by guest OS. If guest OS does not clear the MSR or guest OS does not set the X86_CR4_MCE bit in the cr4, the triple fault will be triggered. > And there you may also > print this event (and you already do). Sorry, which print do you mean? I can not find similar print in user space. > Another reason to not rely on catching this case here: KVM_X86_SET_MCE > is obsolete on current kernels. Qemu will use a combination of > KVM_SET_MSRS and KVM_SET_VCPU_EVENTS in the future, only falling back to > this interface on pre-vcpu-events kernels. Then you need to debug this > in user space anyway as the triple fault will no longer make it to the > kernel. OK. Then, I think it will be helpful for debugging if we can print something like this in user space implementation. Best Regards, Huang Ying -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
