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

[Martin Lucina <martin@xxxxxxxxxx>]

On Tuesday, 26.05.2020 at 11:34, 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?

I triple-checked that on Friday, but here you go:

    (gdb) x /xg 0x108010
    0x108010:   0x00cf9b000000ffff
    (gdb) x /tg 0x108010
    0x108010:   0000000011001111100110110000000000000000000000001111111111111111

Translates to:

base_31_24 = { 0 }
g = 1 (4 kB)
b = 1 (32-bit)
l = 0 (32-bit)
avl = 0
limit_19_16 = { 1 }
p = 1
dpl = 0
s = 1
type = 1011 (code, exec/read, accessed)
base23_16 = { 0 }
base15_0 = { 0 }
limit_15_0 = { 1 }

type should technically not include accessed, but that shouldn't matter.
In any case, changing it to 1010 does not help.

Looks like I'll have to build a patched Xen as per Andrew's suggestion, and
dump the VMCS on the triple fault.

-mato