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 <adurbin@google.com> wrote:
On Wed, Dec 14, 2016 at 3:11 AM, Chauhan, Himanshu
<hschauhan@nulltrace.org> 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: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot



--

Regards
[Himanshu Chauhan]