Re: [Qemu-devel] [QUESTION]stuck in SeaBIOS and vm cannot be reset any more

* Re: [Qemu-devel] [QUESTION]stuck in SeaBIOS and vm cannot be reset any more
@ 2016-08-11  2:13 Xulei (Stone)
  2016-08-11 13:37 ` Paolo Bonzini
  0 siblings, 1 reply; 5+ messages in thread
From: Xulei (Stone) @ 2016-08-11  2:13 UTC (permalink / raw)
  To: Paolo Bonzini, Kevin O'Connor, Paolo Bonzini; +Cc: seabios, qemu-devel

> 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

^ permalink raw reply	[flat|nested] 5+ messages in thread