All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Lucina <martin@lucina.net>
To: "Roger Pau Monné" <roger.pau@citrix.com>
Cc: "Jürgen Groß" <jgross@suse.com>,
	anil@recoil.org, "Andrew Cooper" <andrew.cooper3@citrix.com>,
	mirageos-devel@lists.xenproject.org, dave@recoil.org,
	xen-devel@lists.xenproject.org
Subject: Re: Xen PVH domU start-of-day VCPU state
Date: Tue, 26 May 2020 12:12:03 +0200	[thread overview]
Message-ID: <20200526101203.GE5942@nodbug.lucina.net> (raw)
In-Reply-To: <20200526100337.GB38408@Air-de-Roger>

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.

-mato


  reply	other threads:[~2020-05-26 10:12 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-25 16:04 Xen PVH domU start-of-day VCPU state Martin Lucina
2020-05-25 16:42 ` Jürgen Groß
2020-05-25 16:59   ` Andrew Cooper
2020-05-26  8:52     ` Martin Lucina
2020-05-26  9:34       ` Roger Pau Monné
2020-05-26 10:03         ` Roger Pau Monné
2020-05-26 10:12           ` Martin Lucina [this message]
2020-05-26 10:32             ` Roger Pau Monné
2020-05-26 15:42             ` Martin Lucina
2020-05-26 16:30               ` Roger Pau Monné
2020-05-27  8:00                 ` Martin Lucina
2020-05-27 14:41                   ` Roger Pau Monné
2020-05-27 14:57                     ` Martin Lucina
2020-05-27 15:05                       ` Roger Pau Monné
2020-05-26 10:08         ` Martin Lucina
2020-05-26 10:58       ` Andrew Cooper
2020-05-26 11:54         ` Mail-Followup-To (was Re: Xen PVH domU start-of-day VCPU state) Martin Lucina
2020-05-26 11:58           ` Andrew Cooper
2020-05-26 12:41             ` Martin Lucina
2020-05-26 12:42               ` Andrew Cooper
2020-05-26 12:44                 ` Martin Lucina
2020-05-25 17:41 ` Xen PVH domU start-of-day VCPU state Andrew Cooper
2020-05-26  8:27   ` Martin Lucina

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200526101203.GE5942@nodbug.lucina.net \
    --to=martin@lucina.net \
    --cc=andrew.cooper3@citrix.com \
    --cc=anil@recoil.org \
    --cc=dave@recoil.org \
    --cc=jgross@suse.com \
    --cc=mirageos-devel@lists.xenproject.org \
    --cc=roger.pau@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.