Re: [Qemu-devel] qemu FreeBSD/sparc64 host - a bit of debugging

[Blue Swirl]

On Mon, Jul 18, 2011 at 9:22 PM, Juergen Lock <address@hidden> wrote:
> Hi!
>
>  I'm the FreeBSD qemu port maintainer and don't have a sparc64 box
> myself, but Jashank Jeremy (Cc'd) now was so kind to test qemu 0.14.1
> on a FreeBSD/sparc64 box booting a FreeBSD 8/i386 install iso using
> i386-softmmu and we found two things:
>
> 1. The hang people have been reporting seems to be caused by this tb:
>
>        IN:
>        0x000e7a31:  in     $0xb3,%al
>        0x000e7a33:  test   %al,%al
>        0x000e7a35:  jne    0xe7a31
>
>   i.e. it (the qemu bios I suppose) is waiting for x86 ioport 0xb3
>   to become zero.  This port is #defined in hw/apm.c as:
>
>        qemu-0.14.1/hw/apm.c:#define APM_STS_IOPORT  0xb3
>
>   but the definition seems to be used nowhere in that source file.
>   Anyone have an idea why this port is never zero on sparc64 hosts
>   but seems to be on others?  (endian issue?  uninitialized variable?)

The port belongs to SMI, it's PORT_SMI_STATUS in Seabios.

There is a crash on OpenBSD/Sparc64 at this point. The problem is that
somewhere in do_smm_enter() or the functions that it calls, global
register for CPUState %g5 gets a different value that it should have.
Probably a system library uses it. I'll try if dropping -ffixed-g5
changes anything.

> 2. Booting the same guest with -no-acpi gets further, bios and
>   bootloader messages are printed until it hangs again, this
>   time while handling a guest irq 8 which seems to be rtc.

Yes, same here.

>  Maybe this is useful to some... :)
>
>  Thanx,
>        Juergen
>