Skip to contentSkip to conversation

KVM: x86: Remove user space triggerable MCE error message

PATCH Applied Jan Kiszka 3 participants 6 messages Jan 15, 2011 – Jan 20, 2011

Subsystems (3)
x86 KVM KVM x86
lore
Share & tools
lore

Jan Kiszka

author
#0 lore raw

PATCH 1/1 KVM: x86: Remove user space triggerable MCE error message

From: Jan Kiszka <[email protected]>

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.

Signed-off-by Jan Kiszka <[email protected]>
---
 arch/x86/kvm/x86.c |    3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)
arch/x86/kvm/x86.c +0 -3
index 9dda70d..7f7e4a5 100644
@@ -2575,9 +2575,6 @@ static int kvm_vcpu_ioctl_x86_set_mce(struct kvm_vcpu *vcpu,
 	if (mce->status & MCI_STATUS_UC) {
 		if ((vcpu->arch.mcg_status & MCG_STATUS_MCIP) ||
 		    !kvm_read_cr4_bits(vcpu, X86_CR4_MCE)) {
-			printk(KERN_DEBUG "kvm: set_mce: "
-			       "injects mce exception while "
-			       "previous one is in progress!\n");
 			kvm_make_request(KVM_REQ_TRIPLE_FAULT, vcpu);
 			return 0;
 		}
Signature · 1 line
1.7.1
#1 lore raw
Quoted 4 lines · Jan Kiszka

From: Jan Kiszka <[email protected]>

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.

Best Regards,
Huang Ying

Quoted 19 lines
Signed-off-by Jan Kiszka <[email protected]>
---
 arch/x86/kvm/x86.c |    3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)
arch/x86/kvm/x86.c +0 -3
index 9dda70d..7f7e4a5 100644
@@ -2575,9 +2575,6 @@ static int kvm_vcpu_ioctl_x86_set_mce(struct kvm_vcpu *vcpu,
 	if (mce->status & MCI_STATUS_UC) {
 		if ((vcpu->arch.mcg_status & MCG_STATUS_MCIP) ||
 		    !kvm_read_cr4_bits(vcpu, X86_CR4_MCE)) {
-			printk(KERN_DEBUG "kvm: set_mce: "
-			       "injects mce exception while "
-			       "previous one is in progress!\n");
 			kvm_make_request(KVM_REQ_TRIPLE_FAULT, vcpu);
 			return 0;
 		}
author
#2 lore raw
Quoted 6 lines · Huang Ying
Quoted 4 lines · Jan Kiszka

From: Jan Kiszka <[email protected]>

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.

Quoted 8 lines

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. And there you may also print this event (and you already do).

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.

Jan

Quoted 25 lines

Best Regards,
Huang Ying

Quoted 19 lines
Signed-off-by Jan Kiszka <[email protected]>
---
 arch/x86/kvm/x86.c |    3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)
arch/x86/kvm/x86.c +0 -3
index 9dda70d..7f7e4a5 100644
@@ -2575,9 +2575,6 @@ static int kvm_vcpu_ioctl_x86_set_mce(struct kvm_vcpu *vcpu,
 	if (mce->status & MCI_STATUS_UC) {
 		if ((vcpu->arch.mcg_status & MCG_STATUS_MCIP) ||
 		    !kvm_read_cr4_bits(vcpu, X86_CR4_MCE)) {
-			printk(KERN_DEBUG "kvm: set_mce: "
-			       "injects mce exception while "
-			       "previous one is in progress!\n");
 			kvm_make_request(KVM_REQ_TRIPLE_FAULT, vcpu);
 			return 0;
 		}
#3 lore raw
Quoted 12 lines · Jan Kiszka
Quoted 11 lines · Huang Ying
Quoted 4 lines · Jan Kiszka

From: Jan Kiszka <[email protected]>

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.

Quoted 6 lines
Quoted 3 lines

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.

Quoted 2 lines

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.

Quoted 6 lines

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

author
#4 lore raw
Quoted 15 lines · Huang Ying
Quoted 14 lines · Jan Kiszka
Quoted 13 lines · Huang Ying
Quoted 4 lines · Jan Kiszka

From: Jan Kiszka <[email protected]>

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.

Quoted 8 lines
Quoted 4 lines
Quoted 1 line

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.

Right, but qemu has full access to the state and can detect this.

Quoted 6 lines
Quoted 3 lines

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.

Err, it's not yet there for the kvm case, I was starring at the tcg code path.

Quoted 10 lines
Quoted 7 lines

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.

qemu_log_mask(CPU_LOG_RESET, "Triple fault\n");

(and there will be a message on the monitor if raised manually)

Jan