Hi Aaron, Yes, I am mapping the memory where coreboot.rom is loaded to upper 4GiB. I create a fixed shadow page table entry for reset vector.
Coreboot doesn't have a linked address of RIP that I shared. I think with the increase in size of coreboot (from the previous tag I was using) the load address (guest physical) has changed. I used to calculate the load address manually. I will check this and get back. Thanks. On Wed, Dec 14, 2016 at 8:17 PM, Aaron Durbin <[email protected]> wrote: > On Wed, Dec 14, 2016 at 3:11 AM, Chauhan, Himanshu > <[email protected]> wrote: > > Hi, > > > > I am working on a hypvervisor and am using coreboot + FILO as guest BIOS. > > While things were fine a while back, it has stopped working. I see that > my > > hypervisor can't handle address 0xFFFFFC while coreboot's RIP is at > > 0xfff81e41. > > > How are you loading up coreboot.rom in the VM? Are you just memory > mapping it at the top of 4GiB address space? If so, what does > 'cbfstool coreboot.rom print' show? > > > > > The exact register dump of guest is as follow: > > > > [guest0/uart0] (__handle_vm_exception:558) ERROR: No region mapped to > guest > > physical: 0xfffffc > > > > GUEST guest0/vcpu0 dump state: > > > > RAX: 0x9fe80 RBX: 0xfffff8 RCX: 0x1b RDX: 0x53a11439 > > R08: 0x0 R09: 0x0 R10: 0x0 R11: 0x0 > > R12: 0x0 R13: 0x0 R14: 0x0 R15: 0x0 > > RSP: 0x9fe54 RBP: 0xa0000 RDI: 0xfff801e4 RSI: 0x9fe80 > > RIP: 0xfff81e41 > > > > CR0: 0xe0000011 CR2: 0x0 CR3: 0xa23000 CR4: 0x0 > > CS : Sel: 0x00000008 Limit: 0xffffffff Base: 0x00000000 (G: 1 DB: 1 > L: > > 0 AVL: 0 P: 1 DPL: 0 S: 1 Type: 11) > > DS : Sel: 0x00000010 Limit: 0xffffffff Base: 0x00000000 (G: 1 DB: 1 > L: > > 0 AVL: 0 P: 1 DPL: 0 S: 1 Type: 3) > > ES : Sel: 0x00000010 Limit: 0xffffffff Base: 0x00000000 (G: 1 DB: 1 > L: > > 0 AVL: 0 P: 1 DPL: 0 S: 1 Type: 3) > > SS : Sel: 0x00000010 Limit: 0xffffffff Base: 0x00000000 (G: 1 DB: 1 > L: > > 0 AVL: 0 P: 1 DPL: 0 S: 1 Type: 3) > > FS : Sel: 0x00000010 Limit: 0xffffffff Base: 0x00000000 (G: 1 DB: 1 > L: > > 0 AVL: 0 P: 1 DPL: 0 S: 1 Type: 3) > > GS : Sel: 0x00000010 Limit: 0xffffffff Base: 0x00000000 (G: 1 DB: 1 > L: > > 0 AVL: 0 P: 1 DPL: 0 S: 1 Type: 3) > > GDT : Sel: 0x00000000 Limit: 0x0000001f Base: 0xfff80200 (G: 0 DB: 0 > L: > > 0 AVL: 0 P: 0 DPL: 0 S: 0 Type: 0) > > LDT : Sel: 0x00000000 Limit: 0x0000ffff Base: 0x00000000 (G: 0 DB: 0 > L: > > 0 AVL: 0 P: 0 DPL: 0 S: 0 Type: 0) > > IDT : Sel: 0x00000000 Limit: 0x00000000 Base: 0x00000000 (G: 0 DB: 0 > L: > > 0 AVL: 0 P: 0 DPL: 0 S: 0 Type: 0) > > TR : Sel: 0x00000000 Limit: 0x0000ffff Base: 0x00000000 (G: 1 DB: 0 > L: > > 1 AVL: 1 P: 0 DPL: 0 S: 0 Type: 0) > > RFLAGS: 0xa [ ] > > > > I want to know which binary file (.o) should I disassemble to look at the > > RIP? > > > > I was looking at > > objdump -D -mi386 -Maddr16,data16 generated/ramstage.o > > > > but this is prior to linking and thus only has offsets. > > > > -- > > > > Regards > > [Himanshu Chauhan] > > > > > > -- > > coreboot mailing list: [email protected] > > https://www.coreboot.org/mailman/listinfo/coreboot > -- Regards [Himanshu Chauhan]
-- coreboot mailing list: [email protected] https://www.coreboot.org/mailman/listinfo/coreboot
