On Thu, 2013-01-03 at 18:43 -0700, Daniel Verkamp wrote: > On Thu, Jan 3, 2013 at 2:31 PM, Alex Williamson > <alex.william...@redhat.com> wrote: > > Hi, > > > > I was playing a bit with vfio-based PCI device assignment of VGA in qemu > > and I seem to be hitting a wall just trying to jump into the VGA BIOS. > > I'm booting qemu with -vga none and assigning a radeon hd5450 via > > vfio-pci with some extra code to handle passing legacy accesses through > > to the host. Legacy access hardly seems to matter though as the > > experiment quickly dies when the vcpu starts executing zero'd memory. > > gdb shows me something like this: > > > > 0x000f257c <__callrom+72>: 66 c7 44 24 16 ff ff movw > > $0xffff,0x16(%esp) > > 0x000f2583 <__callrom+79>: 66 c7 44 24 1a ff ff movw > > $0xffff,0x1a(%esp) > > 0x000f258a <__callrom+86>: 66 c7 44 24 08 00 f0 movw > > $0xf000,0x8(%esp) > > 0x000f2591 <__callrom+93>: b8 80 d1 0f 00 mov $0xfd180,%eax > > 0x000f2596 <__callrom+98>: 66 89 44 24 0a mov %ax,0xa(%esp) > > 0x000f259b <__callrom+103>: c1 e5 10 shl $0x10,%ebp > > 0x000f259e <__callrom+106>: 0f b7 d7 movzwl %di,%edx > > 0x000f25a1 <__callrom+109>: 09 ea or %ebp,%edx > > 0x000f25a3 <__callrom+111>: 89 54 24 26 mov %edx,0x26(%esp) > > 0x000f25a7 <__callrom+115>: 89 e0 mov %esp,%eax > > 0x000f25a9 <__callrom+117>: 3d 00 70 00 00 cmp $0x7000,%eax > > 0x000f25ae <__callrom+122>: 76 0a jbe 0xf25ba <__callrom+134> > > 0x000f25ba <__callrom+134>: 89 f0 mov %esi,%eax > > 0x000f25bc <__callrom+136>: bb 58 68 00 00 mov $0x6858,%ebx > > 0x000f25c1 <__callrom+141>: e8 31 98 00 00 call 0xfbdf7 > > 0x000fbdf7: ba 01 be 00 00 mov $0xbe01,%edx > > 0x000fbdfc: e9 0e ff ff ff jmp 0xfbd0f > > 0x000fbd0f: 89 c1 mov %eax,%ecx > > 0x000fbd11: b8 30 00 00 00 mov $0x30,%eax > > 0x000fbd16: 8e d8 mov %eax,%ds > > 0x000fbd18: 8e c0 mov %eax,%es > > 0x000fbd1a: 8e d0 mov %eax,%ss > > 0x000fbd1c: 8e e0 mov %eax,%fs > > 0x000fbd1e: 8e e8 mov %eax,%gs > > 0x000fbd20: 66 ea 26 bd 28 00 ljmpw $0x28,$0xbd26 > > 0x0000bd26: 00 00 add %al,(%eax) > > I think GDB is probably getting lost at the far jump (ljmpw). To my > knowledge, GDB does not understand the x86 segmented real-mode memory > model. > > The trace above is __callrom() -> farcall16big() -> call16big() -> > __call16big() -> transition16big in romlayout.S, which contains the > ljmpw in question. > > > Trying to follow the code into __callrom(), I'm really confused how the > > option rom init vector is actually used since callrom() passes the > > option rom header offset to the init vector rather than anything > > actually resembling the value of the init vector. I really don't know > > x86 though, so maybe I'm missing something. > > The far address of the ROM initialization vector (seg:offset) is being > loaded into br.code, which will get used later on in the farcall > helper functions noted above. The offset is set to > OPTION_ROM_INITVECTOR by callrom(), which is 3; this is relative to > the segment of the ROM header (hence the FLATPTR_TO_SEG in __callrom). > The ROM header should have a jump at that location to the real > initialization code. > > I don't have any real tips on how to make this work - hopefully > someone else will know the magic incantation to clue in GDB to the new > code segment. > > This blog post also looks relevant: > http://crustynation.net/wiki/doku.php?id=blog:gdb_real_mode
Awesome! That gdbinit is magic. Thanks for the pointer, Alex _______________________________________________ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios