query: per-opcode filters/logging?

[hanetzer]

Hello. My current project is porting coreboot to 'normal' desktop ryzen machines.
I've made good progress so far, x86 code boots and gets so far as to do serial output.
However, after what appears to be an identical timeframe, the machine reboots before
it can do anything particularly useful.

I'm intending on using avatar2 to emulate the 'bootblock' of the vendor bios,
which in UEFI terms is the 'Volume Top File'. However, it does a fair amount of
'post codes' which comprise 'out' opcodes to ports 0x80 thru 0x83. As qemu
does not appear to have particular support for this, and its not a 'normal' mmio
mapped peripheral, it would be reasonable to filter for that opcode and log it,
assuming its pushing data to the right location.

End goal is to hopefully find some magick bit twiddle which will prevent these
reboots, enough to get serialice working at the very least.

[rawsample]

Hi,

If I understand correctly, you would like to do some hardware-in-the-loop to debug the reboot issue on hardware, but you have troubles booting the firmware in QEMU up to the same point as with the hardware?

In this case, I think you could start the execution on the hardware, breakpoint somewhere after the point where QEMU has difficulties to emulate (POST codes), migrate the state of the firmware in QEMU and continue from there?

[hanetzer]

No, the post codes are not really that big of an issue, but it would be nice to have.

The real issue is that on vendor firmware, something happens on the x86 side
(there's also arm code execution on ryzen chips) that prevents the boot loop from
happening, so maybe by emulating the vendor bios and watching 'what it does'
will reveal the secret I need.

Suppose this is theoretically doable. Question now would be, how? Serial target? GDB target? Jtag is off the table 100%, and as far as I know there's no x86 gdbstub in 'bios' out there.