Re: Xen PVH domU start-of-day VCPU state

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

BTW, not sure why but my MUA (Mutt 11.0.3) seems to add everyone on Cc
to the To: field on reply, and drops your email address from the list.
I don't see a 'Reply-to:' on the headers, so I'm not sure why it does
that, but you might want to check your config.

I have to manually fix the headers to properly set the To: field to
your address and the Cc to everyone else.

On Tue, May 26, 2020 at 12:12:03PM +0200, Martin Lucina wrote:
> On Tuesday, 26.05.2020 at 12:03, Roger Pau Monné wrote:
> > On Tue, May 26, 2020 at 11:34:21AM +0200, Roger Pau Monné wrote:
> > > On Tue, May 26, 2020 at 10:52:21AM +0200, Martin Lucina wrote:
> > > > On Monday, 25.05.2020 at 17:59, Andrew Cooper wrote:
> > > > > On 25/05/2020 17:42, Jürgen Groß wrote:
> > > > > > You need to setup virtual addressing and enable 64 bit mode before 
> > > > > > using
> > > > > > 64-bit GDT.
> > > > > >
> > > > > > See Mini-OS source arch/x86/x86_hvm.S
> > > > > 
> > > > > Or
> > > > > https://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen-test-framework.git;a=blob;f=arch/x86/hvm/head.S;h=f7dc72b58ab9ec68538f0087969ab6f72d181d80;hb=HEAD
> > > > > 
> > > > > But yes - Juergen is correct.  Until you have enabled long mode, lgdt
> > > > > will only load the bottom 32 bits of GDTR.base.
> > > > 
> > > > Ah, I missed Jurgen's and your reply here.
> > > > 
> > > > LGDT loading only the bottom 32 bits of GDTR.base shouldn't matter.
> > > > Examining gdt_ptr some more:
> > > > 
> > > >     (gdb) set architecture i386
> > > >     The target architecture is assumed to be i386
> > > >     (gdb) x /xh 0x108040
> > > >     0x108040:   0x002f
> > > >     (gdb) x /xw 0x108042
> > > >     0x108042:   0x00108000
> > > >     (gdb) x /6xb 0x108040
> > > >     0x108040:   0x2f    0x00    0x00    0x80    0x10    0x00
> > > >     (gdb) x /8xb 0x108040
> > > >     0x108040:   0x2f    0x00    0x00    0x80    0x10    0x00    0x00    
> > > > 0x00
> > > 
> > > Could you also print the GDT entry at 0x10 (ie: 0x108000 + 0x10), just
> > > to make sure it contains the right descriptor?
> > 
> > Forgot to ask, but can you also add the output of readelf -lW
> > <kernel>?
> 
>     Elf file type is EXEC (Executable file)
>     Entry point 0x1001e0
>     There are 7 program headers, starting at offset 64
> 
>     Program Headers:
>       Type           Offset   VirtAddr           PhysAddr           FileSiz  
> MemSiz   Flg Align
>       INTERP         0x001000 0x0000000000100000 0x0000000000100000 0x000018 
> 0x000018 R   0x8
>           [Requesting program interpreter: /nonexistent/solo5/]
>       LOAD           0x001000 0x0000000000100000 0x0000000000100000 0x00626c 
> 0x00626c R E 0x1000
>       LOAD           0x008000 0x0000000000107000 0x0000000000107000 0x007120 
> 0x00ed48 RW  0x1000
>       NOTE           0x0080ac 0x00000000001070ac 0x00000000001070ac 0x000018 
> 0x000018 R   0x4
>       NOTE           0x00f120 0x00000000001070c4 0x00000000001070c4 0x000014 
> 0x000000 R   0x4
>       NOTE           0x008088 0x0000000000107088 0x0000000000107088 0x000024 
> 0x000024 R   0x4
>       NOTE           0x008000 0x0000000000107000 0x0000000000107000 0x000088 
> 0x000088 R   0x4
> 
>      Section to Segment mapping:
>       Segment Sections...
>        00     .interp
>        01     .interp .text .rodata .eh_frame
>        02     .note.solo5.manifest .note.solo5.abi .note.solo5.not-openbsd 
> .data .bss
>        03     .note.solo5.not-openbsd
>        04     .note.solo5.xen
>        05     .note.solo5.abi
>        06     .note.solo5.manifest
> 
> The PT_INTERP and multiple PT_NOTE headers are that way due to specifics of
> how Solo5 ABIs work, but I've verified that the domain builder is
> interpreting XEN_ELFNOTE_PHYS32_ENTRY correctly.

Right, just wanted to double check that virtaddr == physaddr since you
didn't use any offset to get the physical address of symbols, but I
guess that if this wasn't correct you won't be even able to execute
the first instruction anyway.

Thanks, Roger.