Re: [SeaBIOS] [QUESTION]stuck in SeaBIOS and vm can not be reset any more

[Kevin O'Connor]

On Fri, Jul 29, 2016 at 04:04:59AM +0000, Xulei (Stone) wrote:
> Hi, all:
> Recently when i try to reset a vm, I find it may be stuck in SeaBIOS.
> I use a shell script to continuously reset a vm to see what may happen.
>
> #!/bin/bash
> while((1))
> do
> virsh reset VMNAME
> sleep 1
> done
>
> After one day, the vm is stuck. Looking from the following seabios log,
> it seems seabios stops at "PCI: Using 00:02.0 for primary VGA", and can
> not execute handle_smp() any more.
> What may be the reason?

More debugging info would be necessary to find this problem.  You
could try reproducing and attaching gdb (
http://www.seabios.org/Debugging#Debugging_with_gdb_on_QEMU ).
Alternatively, a kvm trace log may help.

-Kevin

[QUESTION]stuck in SeaBIOS and vm can not be reset any more

[Xulei (Stone)]

> On Fri, Jul 29, 2016 at 04:04:59AM +0000, Xulei (Stone) wrote:
> > Hi, all:
> > Recently when i try to reset a vm, I find it may be stuck in SeaBIOS.
> > I use a shell script to continuously reset a vm to see what may happen.
> >
> > #!/bin/bash
> > while((1))
> > do
> > virsh reset VMNAME
> > sleep 1
> > done
> >
> > After one day, the vm is stuck. Looking from the following seabios log,
> > it seems seabios stops at "PCI: Using 00:02.0 for primary VGA", and can
> > not execute handle_smp() any more.
> > What may be the reason?
>
> More debugging info would be necessary to find this problem.  You
> could try reproducing and attaching gdb (
> http://www.seabios.org/Debugging#Debugging_with_gdb_on_QEMU ).
> Alternatively, a kvm trace log may help.

kvm trace (seems useful) indicates that cpu 0 keeps always to access 0x00b3 ioport.
0x00b3 is PORT_SMI_STATUS, so i guess my bios is stuck in the function
smm_relocate_and_restore
{ 
	...
	/* wait until SMM code executed */
    while (inb(PORT_SMI_STATUS) != 0x00)
	...
}
And top tells me cpu 0 indeed has 100% CPU utilization.
So, there maybe a bug in smm setup or handle_smi if i keep continuously reset VM.
======================KVM trace log============================
CPU 0/KVM-13843 [020] d... 1025056.813494: kvm_entry: vcpu 0
CPU 0/KVM-13843 [020] .... 1025056.813495: kvm_exit: reason IO_INSTRUCTION rip 0xef10e info b30048 0
CPU 0/KVM-13843 [020] .... 1025056.813495: kvm_emulate_insn: 0:ef10e:e4 b3 (prot32)
CPU 0/KVM-13843 [020] .... 1025056.813496: kvm_userspace_exit: reason KVM_EXIT_IO (2)
CPU 0/KVM-13843 [020] .... 1025056.813496: kvm_fpu: unload
CPU 0/KVM-13843 [020] .... 1025056.813497: kvm_pio: pio_read at 0xb3 size 1 count 1 val 0x1
CPU 0/KVM-13843 [020] .... 1025056.813497: kvm_fpu: load
CPU 0/KVM-13843 [020] d... 1025056.813497: kvm_entry: vcpu 0
CPU 0/KVM-13843 [020] .... 1025056.813498: kvm_exit: reason IO_INSTRUCTION rip 0xef10e info b30048 0
CPU 0/KVM-13843 [020] .... 1025056.813498: kvm_emulate_insn: 0:ef10e:e4 b3 (prot32)
CPU 0/KVM-13843 [020] .... 1025056.813499: kvm_userspace_exit: reason KVM_EXIT_IO (2)
CPU 0/KVM-13843 [020] .... 1025056.813499: kvm_fpu: unload
CPU 0/KVM-13843 [020] .... 1025056.813500: kvm_pio: pio_read at 0xb3 size 1 count 1 val 0x1
CPU 0/KVM-13843 [020] .... 1025056.813500: kvm_fpu: load

Thanks Kevin, looking forward to your reply!
> -Kevin