xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	ian.jackson@eu.citrix.com, Julien Grall <julien.grall@arm.com>,
	stefano.stabellini@citrix.com, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 2/5] arm/config: Declare ELFSIZE_[32|64] respectively.
Date: Wed, 16 Mar 2016 21:16:36 -0400	[thread overview]
Message-ID: <20160317011635.GE5173@localhost.localdomain> (raw)
In-Reply-To: <20160316192151.GA10835@char.us.oracle.com>

On Wed, Mar 16, 2016 at 03:21:51PM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Mar 16, 2016 at 06:08:06PM +0000, Julien Grall wrote:
> > Hi Konrad
> > 
> > On 16/03/2016 17:52, Konrad Rzeszutek Wilk wrote:
> > >On Wed, Mar 16, 2016 at 05:32:09PM +0000, Julien Grall wrote:
> > >>Sorry for the late answer on this patch. I noticed the problem while I was
> > >>reviewing your xSplice patch series.
> > >>
> > >>On 12/02/2016 15:56, Konrad Rzeszutek Wilk wrote:
> > >>> From 32a062c119091f2f3f6a4c540a8098e97c273dd2 Mon Sep 17 00:00:00 2001
> > >>>From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > >>>Date: Fri, 5 Feb 2016 10:44:45 -0500
> > >>>Subject: [PATCH] arm/config: Declare ELFSIZE_64.
> > >>>
> > >>>Otherwise any code that tries to use Elf_* macros would
> > >>>require us to use Elf64_* types instead of the more
> > >>>friendly Elf_ one.
> > >>>
> > >>>This is OK to do since 32-bit ARM uses LPAE mode.
> > >>
> > >>That's not true. Some of structures have a different layout based on the
> > >>file class (i.e ELFSIZE in Xen).
> > >>
> > >>For 32-bit ARM, ELFCLASS32 (i.e 32-bit data types) will always be used. So
> > >>we need to set ELFSIZE to 32.
> > >
> > >OK. Let me send out a patch to fix that. Thanks for the heads up!
> > 
> > With this change, do you need to revise the answer to the question Jan
> > raised in the design document about ARM32 and the ELF payload declaring the
> > ELF only 64-bit syntax?
> 
> Yes I will. Thank you for raising that as I completly forgot it!
> 
> I think we can still keep the same structure and size. But instead of
> using ELF types in the design (and in the code) I will swap them to
> proper uintXX_t types.

And here is the patch. The change for uintXX_t type worked out - same
size and offset as on 64-bit. Thought I am tempted to add some
more BUILD_BUG checks.

From 7007f1a3fa3a77a725f529420c7aea0e8ebdc9fa Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 16 Mar 2016 16:08:25 -0400
Subject: [PATCH v4 01/35] arm/config: Declare ELFSIZE_[32|64]

The commit bcfaea685d38c08e5eb90797512ab80f0bc69d0c
"arm/config: Declare ELFSIZE_64" was not correct.

For 32-bit ARM, ELFCLASS32 (i.e. 32-bit data types) will always
be used so we need to set ELFSIZE to 32.

Reported-by: Julien Grall <julien.grall@arm.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

---
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>
Cc: Julien Grall <julien.grall@arm.com>
--
---
 xen/include/asm-arm/config.h | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index 7ceb5c5..2d11b62 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -9,8 +9,10 @@
 
 #if defined(CONFIG_ARM_64)
 # define LONG_BYTEORDER 3
+# define ELFSIZE 64
 #else
 # define LONG_BYTEORDER 2
+# define ELFSIZE 32
 #endif
 
 #define BYTES_PER_LONG (1 << LONG_BYTEORDER)
@@ -20,9 +22,6 @@
 /* xen_ulong_t is always 64 bits */
 #define BITS_PER_XEN_ULONG 64
 
-/* And ELF files are also 64-bit. */
-#define ELFSIZE 64
-
 #define CONFIG_PAGING_ASSISTANCE 1
 
 #define CONFIG_PAGING_LEVELS 3
-- 
2.5.0

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2016-03-17  1:16 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-12  3:08 [PATCH v3] Requisite paches for xSplice v3 (not yet posted) Konrad Rzeszutek Wilk
2016-02-12  3:08 ` [PATCH v3 1/5] hypervisor/arm/keyhandler: Declare struct cpu_user_regs; Konrad Rzeszutek Wilk
2016-02-12  8:51   ` Jan Beulich
2016-02-12 14:06     ` Konrad Rzeszutek Wilk
2016-02-12 14:54       ` Jan Beulich
2016-02-12 11:37   ` Stefano Stabellini
2016-02-12 12:20     ` Jan Beulich
2016-02-12 12:46       ` Stefano Stabellini
2016-02-12 14:53         ` Jan Beulich
2016-02-12  3:08 ` [PATCH v3 2/5] arm/config: Declare ELFSIZE_[32|64] respectively Konrad Rzeszutek Wilk
2016-02-12 11:26   ` Stefano Stabellini
2016-02-12 14:17     ` Konrad Rzeszutek Wilk
2016-02-12 15:04       ` Jan Beulich
2016-02-12 15:26         ` Stefano Stabellini
2016-02-12 15:56           ` Konrad Rzeszutek Wilk
2016-02-12 15:57             ` Stefano Stabellini
2016-02-12 17:50               ` Konrad Rzeszutek Wilk
2016-03-16 17:32             ` Julien Grall
2016-03-16 17:52               ` Konrad Rzeszutek Wilk
2016-03-16 18:08                 ` Julien Grall
2016-03-16 19:21                   ` Konrad Rzeszutek Wilk
2016-03-17  1:16                     ` Konrad Rzeszutek Wilk [this message]
2016-03-17 11:04                       ` Julien Grall
2016-03-17 18:52                         ` Konrad Rzeszutek Wilk
2016-02-12  3:08 ` [PATCH v3 3/5] build: remove .config from /boot when uninstalling Konrad Rzeszutek Wilk
2016-02-12 14:11   ` Doug Goldstein
2016-02-12  3:08 ` [PATCH v3 4/5] mkelf32: Remove the 32-bit hypervisor support Konrad Rzeszutek Wilk
2016-02-12  3:08 ` [PATCH v3 5/5] mkelf32: Close those file descriptors in the error paths Konrad Rzeszutek Wilk
2016-02-18 16:29   ` Jan Beulich
2016-02-18 16:39     ` Ian Jackson
2016-02-18 16:45       ` Jan Beulich
2016-02-18 21:12         ` Konrad Rzeszutek Wilk
2016-02-19 11:39           ` Jan Beulich
2016-02-19 11:42           ` Ian Jackson

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=20160317011635.GE5173@localhost.localdomain \
    --to=konrad@kernel.org \
    --cc=JBeulich@suse.com \
    --cc=ian.campbell@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=julien.grall@arm.com \
    --cc=konrad.wilk@oracle.com \
    --cc=stefano.stabellini@citrix.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=wei.liu2@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).