All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Martin Lucina <martin@lucina.net>
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 18:30:21 +0200	[thread overview]
Message-ID: <20200526163021.GE38408@Air-de-Roger> (raw)
In-Reply-To: <20200526154224.GC25283@nodbug.lucina.net>

On Tue, May 26, 2020 at 05:42:24PM +0200, Martin Lucina wrote:
> Oh! I think I've found a solution, even though I don't entirely understand the
> problem/root cause:
> 
> On Tuesday, 26.05.2020 at 12:12, Martin Lucina wrote:
> > > On Tue, May 26, 2020 at 11:34:21AM +0200, Roger Pau Monné wrote:
> > > 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
>                                                                                ^^^^^^^^
> 
> I should have picked up on the above, but thought it wasn't relevant.
> 
> >       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
> 
> And also the missing .note.solo5.xen above.
> 
> >        03     .note.solo5.not-openbsd
> >        04     .note.solo5.xen
> >        05     .note.solo5.abi
> >        06     .note.solo5.manifest
> 
> Turns out that the .note.solo5.xen section as defined in boot.S was not
> marked allocatable, and that was doing <something> that was confusing our
> linker script[1] (?).

Hm, I would have said there was no need to load notes into memory, and
hence using a MemSize of 0 would be fine.

Maybe libelf loader was somehow getting confused and not loading the
image properly?

Can you paste the output of `xl -vvv create ...` when using the broken
image?

> 
> If I make this simple change:
> 
> --- a/bindings/xen/boot.S
> +++ b/bindings/xen/boot.S
> @@ -32,7 +32,7 @@
>  #define ENTRY(x) .text; .globl x; .type x,%function; x:
>  #define END(x)   .size x, . - x
> 
> -.section .note.solo5.xen
> +.section .note.solo5.xen, "a", @note
> 
>         .align  4
>         .long   4
> 
> then I get the expected output from readelf -lW, and I can get as far as
> the C _start() with no issues!
> 
> FWIW, here's the diff of readelf -lW before/after:
> 
> --- before	2020-05-26 17:36:46.117885855 +0200
> +++ after	2020-05-26 17:38:07.090508322 +0200
> @@ -8,9 +8,9 @@
>    INTERP         0x001000 0x0000000000100000 0x0000000000100000 0x000018 0x000018 R   0x8
>        [Requesting program interpreter: /nonexistent/solo5/]
>    LOAD           0x001000 0x0000000000100000 0x0000000000100000 0x00615c 0x00615c R E 0x1000
> -  LOAD           0x008000 0x0000000000107000 0x0000000000107000 0x007120 0x00ed28 RW  0x1000
> +  LOAD           0x008000 0x0000000000107000 0x0000000000107000 0x006120 0x00dd28 RW  0x1000

This seems suspicious, there's a change of the size of the LOAD
section, but your change to the note type should not affect the LOAD
section?

Hm, maybe it does because the .note.solo5.xen was considered writable
by default?

Roger.


  reply	other threads:[~2020-05-26 16:30 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
2020-05-26 10:32             ` Roger Pau Monné
2020-05-26 15:42             ` Martin Lucina
2020-05-26 16:30               ` Roger Pau Monné [this message]
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=20200526163021.GE38408@Air-de-Roger \
    --to=roger.pau@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=anil@recoil.org \
    --cc=dave@recoil.org \
    --cc=jgross@suse.com \
    --cc=martin@lucina.net \
    --cc=mirageos-devel@lists.xenproject.org \
    --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.