On 09/08/2016 10:04, Xulei (Stone) wrote:
Following your suggestion, i'm now sure it is caused by missing SMI. I have tried adding dprintf() like this:
--- a/roms/seabios/src/fw/smm.c +++ b/roms/seabios/src/fw/smm.c @@ -65,7 +65,8 @@ handle_smi(u16 cs) u8 cmd = inb(PORT_SMI_CMD); struct smm_layout *smm = MAKE_FLATPTR(cs, 0); u32 rev = smm->cpu.i32.smm_rev & SMM_REV_MASK;
- dprintf(DEBUG_HDL_smi, "handle_smi cmd=%x smbase=%p\n", cmd,
smm);
if(cmd == 0x00) {
dprintf(1, "handle_smi cmd=%x smbase=%p\n", cmd, smm);}
if (smm == (void*)BUILD_SMM_INIT_ADDR) { // relocate SMBASE to 0xa0000 @@ -147,14 +148,14 @@
smm_relocate_and_restore(void) { /* init APM status port */ outb(0x01, PORT_SMI_STATUS);
dprintf(1,"before SMI====\n");
/* raise an SMI interrupt */ outb(0x00, PORT_SMI_CMD);
dprintf(1,"after SMI=====\n");
/* wait until SMM code executed */ while (inb(PORT_SMI_STATUS) != 0x00) ;
dprintf(1,"smm code executes complete====\n");
And the failed case log output like this: 2016-08-03 16:23:15PCI: Using 00:02.0 for primary VGA 2016-08-03 16:23:15smm_device_setup start 2016-08-03 16:23:15init smm 2016-08-03 16:23:15before SMI==== 2016-08-03 16:23:15after SMI=====
So, it's obviously that after outb(0x01, PORT_SMI_STATUS), bios does not handle_smi, so PORT_SMI_STATUS is always 0x01. What's more, when this problem happens, rebooting vm cannot restore it any more. My vm is always stuck at the same place until i destroy it.
And I have already tried kernel commit c43203cab1e which still can not solve this problem. Any idea, Kevin and Paolo?
0xb2 is handled within QEMU, so it may be useful to make sure that QEMU is sending the KVM_SMI ioctl. From there the best tool is still KVM tracing and printk. I suggest replacing the dprintf with a simple outb like outb(0x21, 0x402) (before) and outb(0x23, 0x402) (after). They show as "!" and "#" in the trace, and they are easy to spot in the KVM trace.
Following your suggestion, I found this problem may be caused by the flag of HF_SMM_MASK. I'm now sure QEMU is sending the KVM_SMI ioctl, and kmod already handles this ioctl.
I add printk in inject_pending_event(), like this:
/* try to inject new event if pending */ + if(get_smi) + printk(KERN_INFO "is_smm:%d\n", is_smm(vcpu)); + if (vcpu->arch.smi_pending && !is_smm(vcpu)) { vcpu->arch.smi_pending = false; process_smi(vcpu); }
Then I found that the normal output is (is_smm is 0): 2016-08-11T09:44:45.090078+08:00|info|kernel[-]|[1269634.151054get smi ioctl from qemu 2016-08-11T09:44:45.090097+08:00|info|kernel[-]|[1269634.151056in process_smi_request 2016-08-11T09:44:45.090114+08:00|info|kernel[-]|[1269634.151057is_smm:0 2016-08-11T09:44:45.090131+08:00|info|kernel[-]|[1269634.151058process smi 2016-08-11T09:44:45.090914+08:00|info|kernel[-]|[1269634.151575get smi ioctl from qemu 2016-08-11T09:44:45.090947+08:00|info|kernel[-]|[1269634.151578in process_smi_request 2016-08-11T09:44:45.090972+08:00|info|kernel[-]|[1269634.151579is_smm:0
When problem occurs the output is (is_smm is 1): 2016-08-11T10:07:11.755982+08:00|info|kernel[-]|[1270981.916056get smi ioctl from qemu 2016-08-11T10:07:11.756035+08:00|info|kernel[-]|[1270981.916062in process_smi_request 2016-08-11T10:07:11.756078+08:00|info|kernel[-]|[1270981.916064is_smm:1 2016-08-11T10:07:13.896977+08:00|info|kernel[-]|[1270984.058117get smi ioctl from qemu 2016-08-11T10:07:13.897063+08:00|info|kernel[-]|[1270984.058121in process_smi_request 2016-08-11T10:07:13.897091+08:00|info|kernel[-]|[1270984.058123is_smm:1
So, it seems kvm cannot set HF_SMM_MASK flag correctly when we continuously reset VM. Any futher suggestion? Paolo :)
Paolo