[SeaBIOS] Re: Handling SMI problem

[lowa-88]

I continue ma research and now have proofs of that QEMU/Seabios behavior.
I've connected gdb to QEMU and got memory dump of first MB. Then I've 
disassembled it, found address of handle_resume function and set a hardware 
breakpoint on it. Then I have generated some SMI's and stopped on the 
breakpoint.
How it can be? Could some one help me?
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org

[SeaBIOS] Handling SMI problem

[lowa-88]

Hello, recently I've found the-sea-watcher project and now I'm trying to repeat 
it. 
https://scumjr.github.io/2016/01/10/from-smm-to-userland-in-a-few-bytes/
But I have a strange problem when I trigger a SMI my VM instantly reboot. I use 
that function to send SMI:

#define PORT_SMI_CMD 0x00b2
int main(void)
{
if (ioperm(PORT_SMI_CMD, 1, 1) != 0)
err(EXIT_FAILURE, "ioperm");
outb(0x61, PORT_SMI_CMD);
printf("done\n");
return EXIT_SUCCESS;
}

I have rebuild SeaBios with CONFIG_DEBUG_LEVEL=8 and found out that SMI's 
reboot VM with a rather big chance. This is a part of SeaBios log:

VBE current mode=3
stub vbe_104fXX:406:
   a=4f09  b=0001  c=0100  d= ds=0040 es= ss=0100
  si= di=2000 bp= sp=1000 cs= ip=0600  f=3200
VBE mode set: c18f
set VGA mode 18f//at this point Ubuntu is loaded
handle_smi cmd=61 smbase=0x000a //I send first
handle_smi cmd=61 smbase=0x000a  //and second SMI
In resume (status=0) //have reboot on third
In 32bit resume
Attempting a hard reboot
enabling shadow ram
SeaBIOS (version 
rel-1.13.0-15-gde88a96-dirty-20200406_111431-test-Lenovo-ideapad-320S-13IKB)
BUILD: gcc: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 binutils: (GNU Binutils for 
Ubuntu) 2.30

I've started to explore the source code, but I don't found anything that could 
help me.
Can you give me an advice or a direction for my research?

Best regards.
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org