* [PATCH v3 0/2] Clear .bss for VP guests
@ 2016-02-25 15:16 Boris Ostrovsky
2016-02-25 15:16 ` [PATCH v3 1/2] xen/x86: Zero out .bss for PV guests Boris Ostrovsky
` (5 more replies)
0 siblings, 6 replies; 26+ messages in thread
From: Boris Ostrovsky @ 2016-02-25 15:16 UTC (permalink / raw)
To: konrad.wilk, david.vrabel
Cc: xen-devel, linux-kernel, mcgrof, brgerst, andrew.cooper3,
Boris Ostrovsky
PV guests need to have their .bss zeroed out since it is not guaranteed
to be cleared by Xen's domain builder
v3:
* Use existing macros for selecting mode-appropriate instructions/registers
* Use 32-bit registers in XOR
* Split removal of mode-selecting ifdefs into a separate patch
Boris Ostrovsky (2):
xen/x86: Zero out .bss for PV guests
xen/x86: Drop mode-selecting ifdefs in startup_xen()
arch/x86/xen/xen-head.S | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
--
2.1.0
^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH v3 1/2] xen/x86: Zero out .bss for PV guests
2016-02-25 15:16 [PATCH v3 0/2] Clear .bss for VP guests Boris Ostrovsky
@ 2016-02-25 15:16 ` Boris Ostrovsky
2016-02-25 16:12 ` Brian Gerst
2016-02-25 16:12 ` Brian Gerst
2016-02-25 15:16 ` Boris Ostrovsky
` (4 subsequent siblings)
5 siblings, 2 replies; 26+ messages in thread
From: Boris Ostrovsky @ 2016-02-25 15:16 UTC (permalink / raw)
To: konrad.wilk, david.vrabel
Cc: xen-devel, linux-kernel, mcgrof, brgerst, andrew.cooper3,
Boris Ostrovsky, stable
Baremetal kernels clear .bss early in the boot but Xen PV guests don't
execute that code. They have been able to run without problems because
Xen domain builder happens to give out zeroed pages. However, since this
is not really guaranteed, .bss should be explicitly cleared.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: stable@vger.kernel.org
---
arch/x86/xen/xen-head.S | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
index b65f59a..11dbe49 100644
--- a/arch/x86/xen/xen-head.S
+++ b/arch/x86/xen/xen-head.S
@@ -38,6 +38,20 @@
__INIT
ENTRY(startup_xen)
cld
+
+#ifdef CONFIG_X86_32
+#define WSIZE_SHIFT 2
+#else
+#define WSIZE_SHIFT 3
+#endif
+ /* Clear .bss */
+ xor %eax,%eax
+ mov $__bss_start, %__ASM_REG(di)
+ mov $__bss_stop, %__ASM_REG(cx)
+ sub %__ASM_REG(di), %__ASM_REG(cx)
+ shr $WSIZE_SHIFT, %__ASM_REG(cx)
+ rep __ASM_SIZE(stos)
+
#ifdef CONFIG_X86_32
mov %esi,xen_start_info
mov $init_thread_union+THREAD_SIZE,%esp
--
2.1.0
^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH v3 1/2] xen/x86: Zero out .bss for PV guests
2016-02-25 15:16 [PATCH v3 0/2] Clear .bss for VP guests Boris Ostrovsky
2016-02-25 15:16 ` [PATCH v3 1/2] xen/x86: Zero out .bss for PV guests Boris Ostrovsky
@ 2016-02-25 15:16 ` Boris Ostrovsky
2016-02-25 15:16 ` [PATCH v3 2/2] xen/x86: Drop mode-selecting ifdefs in startup_xen() Boris Ostrovsky
` (3 subsequent siblings)
5 siblings, 0 replies; 26+ messages in thread
From: Boris Ostrovsky @ 2016-02-25 15:16 UTC (permalink / raw)
To: konrad.wilk, david.vrabel
Cc: andrew.cooper3, linux-kernel, stable, mcgrof, brgerst, xen-devel,
Boris Ostrovsky
Baremetal kernels clear .bss early in the boot but Xen PV guests don't
execute that code. They have been able to run without problems because
Xen domain builder happens to give out zeroed pages. However, since this
is not really guaranteed, .bss should be explicitly cleared.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: stable@vger.kernel.org
---
arch/x86/xen/xen-head.S | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
index b65f59a..11dbe49 100644
--- a/arch/x86/xen/xen-head.S
+++ b/arch/x86/xen/xen-head.S
@@ -38,6 +38,20 @@
__INIT
ENTRY(startup_xen)
cld
+
+#ifdef CONFIG_X86_32
+#define WSIZE_SHIFT 2
+#else
+#define WSIZE_SHIFT 3
+#endif
+ /* Clear .bss */
+ xor %eax,%eax
+ mov $__bss_start, %__ASM_REG(di)
+ mov $__bss_stop, %__ASM_REG(cx)
+ sub %__ASM_REG(di), %__ASM_REG(cx)
+ shr $WSIZE_SHIFT, %__ASM_REG(cx)
+ rep __ASM_SIZE(stos)
+
#ifdef CONFIG_X86_32
mov %esi,xen_start_info
mov $init_thread_union+THREAD_SIZE,%esp
--
2.1.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH v3 2/2] xen/x86: Drop mode-selecting ifdefs in startup_xen()
2016-02-25 15:16 [PATCH v3 0/2] Clear .bss for VP guests Boris Ostrovsky
` (2 preceding siblings ...)
2016-02-25 15:16 ` [PATCH v3 2/2] xen/x86: Drop mode-selecting ifdefs in startup_xen() Boris Ostrovsky
@ 2016-02-25 15:16 ` Boris Ostrovsky
2016-02-26 10:53 ` [PATCH v3 0/2] Clear .bss for VP guests Roger Pau Monné
2016-02-26 10:53 ` [Xen-devel] " Roger Pau Monné
5 siblings, 0 replies; 26+ messages in thread
From: Boris Ostrovsky @ 2016-02-25 15:16 UTC (permalink / raw)
To: konrad.wilk, david.vrabel
Cc: xen-devel, linux-kernel, mcgrof, brgerst, andrew.cooper3,
Boris Ostrovsky
Use asm/asm.h macros instead.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
arch/x86/xen/xen-head.S | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
index 11dbe49..2366895 100644
--- a/arch/x86/xen/xen-head.S
+++ b/arch/x86/xen/xen-head.S
@@ -52,13 +52,9 @@ ENTRY(startup_xen)
shr $WSIZE_SHIFT, %__ASM_REG(cx)
rep __ASM_SIZE(stos)
-#ifdef CONFIG_X86_32
- mov %esi,xen_start_info
- mov $init_thread_union+THREAD_SIZE,%esp
-#else
- mov %rsi,xen_start_info
- mov $init_thread_union+THREAD_SIZE,%rsp
-#endif
+ mov %__ASM_REG(si), xen_start_info
+ mov $init_thread_union+THREAD_SIZE, %__ASM_REG(sp)
+
jmp xen_start_kernel
__FINIT
--
2.1.0
^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH v3 2/2] xen/x86: Drop mode-selecting ifdefs in startup_xen()
2016-02-25 15:16 [PATCH v3 0/2] Clear .bss for VP guests Boris Ostrovsky
2016-02-25 15:16 ` [PATCH v3 1/2] xen/x86: Zero out .bss for PV guests Boris Ostrovsky
2016-02-25 15:16 ` Boris Ostrovsky
@ 2016-02-25 15:16 ` Boris Ostrovsky
2016-02-25 15:16 ` Boris Ostrovsky
` (2 subsequent siblings)
5 siblings, 0 replies; 26+ messages in thread
From: Boris Ostrovsky @ 2016-02-25 15:16 UTC (permalink / raw)
To: konrad.wilk, david.vrabel
Cc: andrew.cooper3, linux-kernel, mcgrof, brgerst, xen-devel,
Boris Ostrovsky
Use asm/asm.h macros instead.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
arch/x86/xen/xen-head.S | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
index 11dbe49..2366895 100644
--- a/arch/x86/xen/xen-head.S
+++ b/arch/x86/xen/xen-head.S
@@ -52,13 +52,9 @@ ENTRY(startup_xen)
shr $WSIZE_SHIFT, %__ASM_REG(cx)
rep __ASM_SIZE(stos)
-#ifdef CONFIG_X86_32
- mov %esi,xen_start_info
- mov $init_thread_union+THREAD_SIZE,%esp
-#else
- mov %rsi,xen_start_info
- mov $init_thread_union+THREAD_SIZE,%rsp
-#endif
+ mov %__ASM_REG(si), xen_start_info
+ mov $init_thread_union+THREAD_SIZE, %__ASM_REG(sp)
+
jmp xen_start_kernel
__FINIT
--
2.1.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 26+ messages in thread
* Re: [PATCH v3 1/2] xen/x86: Zero out .bss for PV guests
2016-02-25 15:16 ` [PATCH v3 1/2] xen/x86: Zero out .bss for PV guests Boris Ostrovsky
@ 2016-02-25 16:12 ` Brian Gerst
2016-02-25 16:12 ` Brian Gerst
1 sibling, 0 replies; 26+ messages in thread
From: Brian Gerst @ 2016-02-25 16:12 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: Konrad Rzeszutek Wilk, David Vrabel, xen-devel,
Linux Kernel Mailing List, mcgrof, andrew.cooper3, stable
On Thu, Feb 25, 2016 at 10:16 AM, Boris Ostrovsky
<boris.ostrovsky@oracle.com> wrote:
> Baremetal kernels clear .bss early in the boot but Xen PV guests don't
> execute that code. They have been able to run without problems because
> Xen domain builder happens to give out zeroed pages. However, since this
> is not really guaranteed, .bss should be explicitly cleared.
>
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Cc: stable@vger.kernel.org
> ---
> arch/x86/xen/xen-head.S | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
> index b65f59a..11dbe49 100644
> --- a/arch/x86/xen/xen-head.S
> +++ b/arch/x86/xen/xen-head.S
> @@ -38,6 +38,20 @@
> __INIT
> ENTRY(startup_xen)
> cld
> +
> +#ifdef CONFIG_X86_32
> +#define WSIZE_SHIFT 2
> +#else
> +#define WSIZE_SHIFT 3
> +#endif
> + /* Clear .bss */
> + xor %eax,%eax
> + mov $__bss_start, %__ASM_REG(di)
> + mov $__bss_stop, %__ASM_REG(cx)
> + sub %__ASM_REG(di), %__ASM_REG(cx)
> + shr $WSIZE_SHIFT, %__ASM_REG(cx)
> + rep __ASM_SIZE(stos)
> +
> #ifdef CONFIG_X86_32
> mov %esi,xen_start_info
> mov $init_thread_union+THREAD_SIZE,%esp
Better, but can still be improved. Replace WSIZE_SHIFT with
__ASM_SEL(2, 3), and use the macros for the registers (ie. __ASM_DI).
--
Brian Gerst
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v3 1/2] xen/x86: Zero out .bss for PV guests
2016-02-25 15:16 ` [PATCH v3 1/2] xen/x86: Zero out .bss for PV guests Boris Ostrovsky
2016-02-25 16:12 ` Brian Gerst
@ 2016-02-25 16:12 ` Brian Gerst
1 sibling, 0 replies; 26+ messages in thread
From: Brian Gerst @ 2016-02-25 16:12 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: andrew.cooper3, Linux Kernel Mailing List, stable, mcgrof,
David Vrabel, xen-devel
On Thu, Feb 25, 2016 at 10:16 AM, Boris Ostrovsky
<boris.ostrovsky@oracle.com> wrote:
> Baremetal kernels clear .bss early in the boot but Xen PV guests don't
> execute that code. They have been able to run without problems because
> Xen domain builder happens to give out zeroed pages. However, since this
> is not really guaranteed, .bss should be explicitly cleared.
>
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Cc: stable@vger.kernel.org
> ---
> arch/x86/xen/xen-head.S | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
> index b65f59a..11dbe49 100644
> --- a/arch/x86/xen/xen-head.S
> +++ b/arch/x86/xen/xen-head.S
> @@ -38,6 +38,20 @@
> __INIT
> ENTRY(startup_xen)
> cld
> +
> +#ifdef CONFIG_X86_32
> +#define WSIZE_SHIFT 2
> +#else
> +#define WSIZE_SHIFT 3
> +#endif
> + /* Clear .bss */
> + xor %eax,%eax
> + mov $__bss_start, %__ASM_REG(di)
> + mov $__bss_stop, %__ASM_REG(cx)
> + sub %__ASM_REG(di), %__ASM_REG(cx)
> + shr $WSIZE_SHIFT, %__ASM_REG(cx)
> + rep __ASM_SIZE(stos)
> +
> #ifdef CONFIG_X86_32
> mov %esi,xen_start_info
> mov $init_thread_union+THREAD_SIZE,%esp
Better, but can still be improved. Replace WSIZE_SHIFT with
__ASM_SEL(2, 3), and use the macros for the registers (ie. __ASM_DI).
--
Brian Gerst
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Xen-devel] [PATCH v3 0/2] Clear .bss for VP guests
2016-02-25 15:16 [PATCH v3 0/2] Clear .bss for VP guests Boris Ostrovsky
` (4 preceding siblings ...)
2016-02-26 10:53 ` [PATCH v3 0/2] Clear .bss for VP guests Roger Pau Monné
@ 2016-02-26 10:53 ` Roger Pau Monné
2016-02-26 13:51 ` Boris Ostrovsky
2016-02-26 13:51 ` Boris Ostrovsky
5 siblings, 2 replies; 26+ messages in thread
From: Roger Pau Monné @ 2016-02-26 10:53 UTC (permalink / raw)
To: Boris Ostrovsky, konrad.wilk, david.vrabel
Cc: andrew.cooper3, linux-kernel, mcgrof, brgerst, xen-devel
El 25/2/16 a les 16:16, Boris Ostrovsky ha escrit:
> PV guests need to have their .bss zeroed out since it is not guaranteed
> to be cleared by Xen's domain builder
I guess I'm missing something, but elf_load_image (in libelf-loader.c)
seems to be able to clear segments (it will zero the memory between
p_paddr + p_filesz and p_paddr + p_memsz) while loading the ELF into
memory, so if the program headers are correctly setup the .bss should be
zeroed out AFAICT.
Roger.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v3 0/2] Clear .bss for VP guests
2016-02-25 15:16 [PATCH v3 0/2] Clear .bss for VP guests Boris Ostrovsky
` (3 preceding siblings ...)
2016-02-25 15:16 ` Boris Ostrovsky
@ 2016-02-26 10:53 ` Roger Pau Monné
2016-02-26 10:53 ` [Xen-devel] " Roger Pau Monné
5 siblings, 0 replies; 26+ messages in thread
From: Roger Pau Monné @ 2016-02-26 10:53 UTC (permalink / raw)
To: Boris Ostrovsky, konrad.wilk, david.vrabel
Cc: andrew.cooper3, mcgrof, xen-devel, linux-kernel, brgerst
El 25/2/16 a les 16:16, Boris Ostrovsky ha escrit:
> PV guests need to have their .bss zeroed out since it is not guaranteed
> to be cleared by Xen's domain builder
I guess I'm missing something, but elf_load_image (in libelf-loader.c)
seems to be able to clear segments (it will zero the memory between
p_paddr + p_filesz and p_paddr + p_memsz) while loading the ELF into
memory, so if the program headers are correctly setup the .bss should be
zeroed out AFAICT.
Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Xen-devel] [PATCH v3 0/2] Clear .bss for VP guests
2016-02-26 10:53 ` [Xen-devel] " Roger Pau Monné
@ 2016-02-26 13:51 ` Boris Ostrovsky
2016-02-26 14:42 ` Brian Gerst
2016-02-26 14:42 ` [Xen-devel] " Brian Gerst
2016-02-26 13:51 ` Boris Ostrovsky
1 sibling, 2 replies; 26+ messages in thread
From: Boris Ostrovsky @ 2016-02-26 13:51 UTC (permalink / raw)
To: Roger Pau Monné, konrad.wilk, david.vrabel
Cc: andrew.cooper3, linux-kernel, mcgrof, brgerst, xen-devel
On 02/26/2016 05:53 AM, Roger Pau Monné wrote:
> El 25/2/16 a les 16:16, Boris Ostrovsky ha escrit:
>> PV guests need to have their .bss zeroed out since it is not guaranteed
>> to be cleared by Xen's domain builder
> I guess I'm missing something, but elf_load_image (in libelf-loader.c)
> seems to be able to clear segments (it will zero the memory between
> p_paddr + p_filesz and p_paddr + p_memsz) while loading the ELF into
> memory, so if the program headers are correctly setup the .bss should be
> zeroed out AFAICT.
Right, but I don't think this is guaranteed. It's uninitialized data so
in principle it can be anything.
The ELF spec says "the system initializes the data with zero when the
program begins to run" which I read as it's up to runtime and not the
loader to do so.
And since kernel does it explicitly on baremetal path I think it's a
good idea for PV to do the same.
-boris
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v3 0/2] Clear .bss for VP guests
2016-02-26 10:53 ` [Xen-devel] " Roger Pau Monné
2016-02-26 13:51 ` Boris Ostrovsky
@ 2016-02-26 13:51 ` Boris Ostrovsky
1 sibling, 0 replies; 26+ messages in thread
From: Boris Ostrovsky @ 2016-02-26 13:51 UTC (permalink / raw)
To: Roger Pau Monné, konrad.wilk, david.vrabel
Cc: andrew.cooper3, mcgrof, xen-devel, linux-kernel, brgerst
On 02/26/2016 05:53 AM, Roger Pau Monné wrote:
> El 25/2/16 a les 16:16, Boris Ostrovsky ha escrit:
>> PV guests need to have their .bss zeroed out since it is not guaranteed
>> to be cleared by Xen's domain builder
> I guess I'm missing something, but elf_load_image (in libelf-loader.c)
> seems to be able to clear segments (it will zero the memory between
> p_paddr + p_filesz and p_paddr + p_memsz) while loading the ELF into
> memory, so if the program headers are correctly setup the .bss should be
> zeroed out AFAICT.
Right, but I don't think this is guaranteed. It's uninitialized data so
in principle it can be anything.
The ELF spec says "the system initializes the data with zero when the
program begins to run" which I read as it's up to runtime and not the
loader to do so.
And since kernel does it explicitly on baremetal path I think it's a
good idea for PV to do the same.
-boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Xen-devel] [PATCH v3 0/2] Clear .bss for VP guests
2016-02-26 13:51 ` Boris Ostrovsky
2016-02-26 14:42 ` Brian Gerst
@ 2016-02-26 14:42 ` Brian Gerst
2016-02-26 15:10 ` Boris Ostrovsky
2016-02-26 15:10 ` [Xen-devel] " Boris Ostrovsky
1 sibling, 2 replies; 26+ messages in thread
From: Brian Gerst @ 2016-02-26 14:42 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: Roger Pau Monné,
Konrad Rzeszutek Wilk, David Vrabel, andrew.cooper3,
Linux Kernel Mailing List, mcgrof, xen-devel
On Fri, Feb 26, 2016 at 8:51 AM, Boris Ostrovsky
<boris.ostrovsky@oracle.com> wrote:
> On 02/26/2016 05:53 AM, Roger Pau Monné wrote:
>>
>> El 25/2/16 a les 16:16, Boris Ostrovsky ha escrit:
>>>
>>> PV guests need to have their .bss zeroed out since it is not guaranteed
>>> to be cleared by Xen's domain builder
>>
>> I guess I'm missing something, but elf_load_image (in libelf-loader.c)
>> seems to be able to clear segments (it will zero the memory between
>> p_paddr + p_filesz and p_paddr + p_memsz) while loading the ELF into
>> memory, so if the program headers are correctly setup the .bss should be
>> zeroed out AFAICT.
>
>
> Right, but I don't think this is guaranteed. It's uninitialized data so in
> principle it can be anything.
>
> The ELF spec says "the system initializes the data with zero when the
> program begins to run" which I read as it's up to runtime and not the loader
> to do so.
>
> And since kernel does it explicitly on baremetal path I think it's a good
> idea for PV to do the same.
It does it on bare metal because bzImage is a raw binary image, not ELF.
--
Brian Gerst
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v3 0/2] Clear .bss for VP guests
2016-02-26 13:51 ` Boris Ostrovsky
@ 2016-02-26 14:42 ` Brian Gerst
2016-02-26 14:42 ` [Xen-devel] " Brian Gerst
1 sibling, 0 replies; 26+ messages in thread
From: Brian Gerst @ 2016-02-26 14:42 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: andrew.cooper3, Linux Kernel Mailing List, mcgrof, David Vrabel,
xen-devel, Roger Pau Monné
On Fri, Feb 26, 2016 at 8:51 AM, Boris Ostrovsky
<boris.ostrovsky@oracle.com> wrote:
> On 02/26/2016 05:53 AM, Roger Pau Monné wrote:
>>
>> El 25/2/16 a les 16:16, Boris Ostrovsky ha escrit:
>>>
>>> PV guests need to have their .bss zeroed out since it is not guaranteed
>>> to be cleared by Xen's domain builder
>>
>> I guess I'm missing something, but elf_load_image (in libelf-loader.c)
>> seems to be able to clear segments (it will zero the memory between
>> p_paddr + p_filesz and p_paddr + p_memsz) while loading the ELF into
>> memory, so if the program headers are correctly setup the .bss should be
>> zeroed out AFAICT.
>
>
> Right, but I don't think this is guaranteed. It's uninitialized data so in
> principle it can be anything.
>
> The ELF spec says "the system initializes the data with zero when the
> program begins to run" which I read as it's up to runtime and not the loader
> to do so.
>
> And since kernel does it explicitly on baremetal path I think it's a good
> idea for PV to do the same.
It does it on bare metal because bzImage is a raw binary image, not ELF.
--
Brian Gerst
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Xen-devel] [PATCH v3 0/2] Clear .bss for VP guests
2016-02-26 14:42 ` [Xen-devel] " Brian Gerst
2016-02-26 15:10 ` Boris Ostrovsky
@ 2016-02-26 15:10 ` Boris Ostrovsky
2016-02-26 15:12 ` David Vrabel
` (3 more replies)
1 sibling, 4 replies; 26+ messages in thread
From: Boris Ostrovsky @ 2016-02-26 15:10 UTC (permalink / raw)
To: Brian Gerst
Cc: Roger Pau Monné,
Konrad Rzeszutek Wilk, David Vrabel, andrew.cooper3,
Linux Kernel Mailing List, mcgrof, xen-devel
On 02/26/2016 09:42 AM, Brian Gerst wrote:
> On Fri, Feb 26, 2016 at 8:51 AM, Boris Ostrovsky
> <boris.ostrovsky@oracle.com> wrote:
>> On 02/26/2016 05:53 AM, Roger Pau Monné wrote:
>>> El 25/2/16 a les 16:16, Boris Ostrovsky ha escrit:
>>>> PV guests need to have their .bss zeroed out since it is not guaranteed
>>>> to be cleared by Xen's domain builder
>>> I guess I'm missing something, but elf_load_image (in libelf-loader.c)
>>> seems to be able to clear segments (it will zero the memory between
>>> p_paddr + p_filesz and p_paddr + p_memsz) while loading the ELF into
>>> memory, so if the program headers are correctly setup the .bss should be
>>> zeroed out AFAICT.
>>
>> Right, but I don't think this is guaranteed. It's uninitialized data so in
>> principle it can be anything.
>>
>> The ELF spec says "the system initializes the data with zero when the
>> program begins to run" which I read as it's up to runtime and not the loader
>> to do so.
>>
>> And since kernel does it explicitly on baremetal path I think it's a good
>> idea for PV to do the same.
> It does it on bare metal because bzImage is a raw binary image, not ELF.
OK, I didn't think about this.
But nevertheless, is it guaranteed that .bss is cleared by the loader?
My reading of the spec is that it's not.
-boris
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v3 0/2] Clear .bss for VP guests
2016-02-26 14:42 ` [Xen-devel] " Brian Gerst
@ 2016-02-26 15:10 ` Boris Ostrovsky
2016-02-26 15:10 ` [Xen-devel] " Boris Ostrovsky
1 sibling, 0 replies; 26+ messages in thread
From: Boris Ostrovsky @ 2016-02-26 15:10 UTC (permalink / raw)
To: Brian Gerst
Cc: andrew.cooper3, Linux Kernel Mailing List, mcgrof, David Vrabel,
xen-devel, Roger Pau Monné
On 02/26/2016 09:42 AM, Brian Gerst wrote:
> On Fri, Feb 26, 2016 at 8:51 AM, Boris Ostrovsky
> <boris.ostrovsky@oracle.com> wrote:
>> On 02/26/2016 05:53 AM, Roger Pau Monné wrote:
>>> El 25/2/16 a les 16:16, Boris Ostrovsky ha escrit:
>>>> PV guests need to have their .bss zeroed out since it is not guaranteed
>>>> to be cleared by Xen's domain builder
>>> I guess I'm missing something, but elf_load_image (in libelf-loader.c)
>>> seems to be able to clear segments (it will zero the memory between
>>> p_paddr + p_filesz and p_paddr + p_memsz) while loading the ELF into
>>> memory, so if the program headers are correctly setup the .bss should be
>>> zeroed out AFAICT.
>>
>> Right, but I don't think this is guaranteed. It's uninitialized data so in
>> principle it can be anything.
>>
>> The ELF spec says "the system initializes the data with zero when the
>> program begins to run" which I read as it's up to runtime and not the loader
>> to do so.
>>
>> And since kernel does it explicitly on baremetal path I think it's a good
>> idea for PV to do the same.
> It does it on bare metal because bzImage is a raw binary image, not ELF.
OK, I didn't think about this.
But nevertheless, is it guaranteed that .bss is cleared by the loader?
My reading of the spec is that it's not.
-boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Xen-devel] [PATCH v3 0/2] Clear .bss for VP guests
2016-02-26 15:10 ` [Xen-devel] " Boris Ostrovsky
2016-02-26 15:12 ` David Vrabel
@ 2016-02-26 15:12 ` David Vrabel
2016-02-26 15:22 ` Roger Pau Monné
2016-02-26 15:22 ` [Xen-devel] " Roger Pau Monné
3 siblings, 0 replies; 26+ messages in thread
From: David Vrabel @ 2016-02-26 15:12 UTC (permalink / raw)
To: Boris Ostrovsky, Brian Gerst
Cc: Roger Pau Monné,
Konrad Rzeszutek Wilk, andrew.cooper3, Linux Kernel Mailing List,
mcgrof, xen-devel
On 26/02/16 15:10, Boris Ostrovsky wrote:
> On 02/26/2016 09:42 AM, Brian Gerst wrote:
>> On Fri, Feb 26, 2016 at 8:51 AM, Boris Ostrovsky
>> <boris.ostrovsky@oracle.com> wrote:
>>> On 02/26/2016 05:53 AM, Roger Pau Monné wrote:
>>>> El 25/2/16 a les 16:16, Boris Ostrovsky ha escrit:
>>>>> PV guests need to have their .bss zeroed out since it is not
>>>>> guaranteed
>>>>> to be cleared by Xen's domain builder
>>>> I guess I'm missing something, but elf_load_image (in libelf-loader.c)
>>>> seems to be able to clear segments (it will zero the memory between
>>>> p_paddr + p_filesz and p_paddr + p_memsz) while loading the ELF into
>>>> memory, so if the program headers are correctly setup the .bss
>>>> should be
>>>> zeroed out AFAICT.
>>>
>>> Right, but I don't think this is guaranteed. It's uninitialized data
>>> so in
>>> principle it can be anything.
>>>
>>> The ELF spec says "the system initializes the data with zero when the
>>> program begins to run" which I read as it's up to runtime and not the
>>> loader
>>> to do so.
>>>
>>> And since kernel does it explicitly on baremetal path I think it's a
>>> good
>>> idea for PV to do the same.
>> It does it on bare metal because bzImage is a raw binary image, not ELF.
>
> OK, I didn't think about this.
>
> But nevertheless, is it guaranteed that .bss is cleared by the loader?
> My reading of the spec is that it's not.
I'm going to apply it once you post a final version with the last
suggestion from Brian.
I'll drop the tag for stable though.
David
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v3 0/2] Clear .bss for VP guests
2016-02-26 15:10 ` [Xen-devel] " Boris Ostrovsky
@ 2016-02-26 15:12 ` David Vrabel
2016-02-26 15:12 ` [Xen-devel] " David Vrabel
` (2 subsequent siblings)
3 siblings, 0 replies; 26+ messages in thread
From: David Vrabel @ 2016-02-26 15:12 UTC (permalink / raw)
To: Boris Ostrovsky, Brian Gerst
Cc: andrew.cooper3, Linux Kernel Mailing List, mcgrof, xen-devel,
Roger Pau Monné
On 26/02/16 15:10, Boris Ostrovsky wrote:
> On 02/26/2016 09:42 AM, Brian Gerst wrote:
>> On Fri, Feb 26, 2016 at 8:51 AM, Boris Ostrovsky
>> <boris.ostrovsky@oracle.com> wrote:
>>> On 02/26/2016 05:53 AM, Roger Pau Monné wrote:
>>>> El 25/2/16 a les 16:16, Boris Ostrovsky ha escrit:
>>>>> PV guests need to have their .bss zeroed out since it is not
>>>>> guaranteed
>>>>> to be cleared by Xen's domain builder
>>>> I guess I'm missing something, but elf_load_image (in libelf-loader.c)
>>>> seems to be able to clear segments (it will zero the memory between
>>>> p_paddr + p_filesz and p_paddr + p_memsz) while loading the ELF into
>>>> memory, so if the program headers are correctly setup the .bss
>>>> should be
>>>> zeroed out AFAICT.
>>>
>>> Right, but I don't think this is guaranteed. It's uninitialized data
>>> so in
>>> principle it can be anything.
>>>
>>> The ELF spec says "the system initializes the data with zero when the
>>> program begins to run" which I read as it's up to runtime and not the
>>> loader
>>> to do so.
>>>
>>> And since kernel does it explicitly on baremetal path I think it's a
>>> good
>>> idea for PV to do the same.
>> It does it on bare metal because bzImage is a raw binary image, not ELF.
>
> OK, I didn't think about this.
>
> But nevertheless, is it guaranteed that .bss is cleared by the loader?
> My reading of the spec is that it's not.
I'm going to apply it once you post a final version with the last
suggestion from Brian.
I'll drop the tag for stable though.
David
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Xen-devel] [PATCH v3 0/2] Clear .bss for VP guests
2016-02-26 15:10 ` [Xen-devel] " Boris Ostrovsky
` (2 preceding siblings ...)
2016-02-26 15:22 ` Roger Pau Monné
@ 2016-02-26 15:22 ` Roger Pau Monné
2016-02-26 15:26 ` David Vrabel
` (3 more replies)
3 siblings, 4 replies; 26+ messages in thread
From: Roger Pau Monné @ 2016-02-26 15:22 UTC (permalink / raw)
To: Boris Ostrovsky, Brian Gerst
Cc: Konrad Rzeszutek Wilk, David Vrabel, andrew.cooper3,
Linux Kernel Mailing List, mcgrof, xen-devel
El 26/2/16 a les 16:10, Boris Ostrovsky ha escrit:
> On 02/26/2016 09:42 AM, Brian Gerst wrote:
>> On Fri, Feb 26, 2016 at 8:51 AM, Boris Ostrovsky
>> <boris.ostrovsky@oracle.com> wrote:
>>> On 02/26/2016 05:53 AM, Roger Pau Monné wrote:
>>>> El 25/2/16 a les 16:16, Boris Ostrovsky ha escrit:
>>>>> PV guests need to have their .bss zeroed out since it is not
>>>>> guaranteed
>>>>> to be cleared by Xen's domain builder
>>>> I guess I'm missing something, but elf_load_image (in libelf-loader.c)
>>>> seems to be able to clear segments (it will zero the memory between
>>>> p_paddr + p_filesz and p_paddr + p_memsz) while loading the ELF into
>>>> memory, so if the program headers are correctly setup the .bss
>>>> should be
>>>> zeroed out AFAICT.
>>>
>>> Right, but I don't think this is guaranteed. It's uninitialized data
>>> so in
>>> principle it can be anything.
>>>
>>> The ELF spec says "the system initializes the data with zero when the
>>> program begins to run" which I read as it's up to runtime and not the
>>> loader
>>> to do so.
>>>
>>> And since kernel does it explicitly on baremetal path I think it's a
>>> good
>>> idea for PV to do the same.
>> It does it on bare metal because bzImage is a raw binary image, not ELF.
>
> OK, I didn't think about this.
>
> But nevertheless, is it guaranteed that .bss is cleared by the loader?
> My reading of the spec is that it's not.
I think this is very blur in general. The copy of the spec I have says:
"the system initializes the data with zeros when the program begins to run"
What is "the system" here, Xen or the guest kernel?
Just to be clear, I'm not opposing to this change in any way, but the
message in patch 1/2 needs to be fixed:
"They have been able to run without problems because Xen domain builder
happens to give out zeroed pages."
This is wrong IMHO, .bss is not cleared because we are using zeroed
pages, but because elf_load_image explicitly zeroes the space between
p_filesz and p_memsz in ELF program headers (which is were .bss resides
on properly arranged ELF binaries) when loading them.
I'm quite sure NetBSD also relies on this, so I would say it's
intrinsically part of the Xen boot ABI now, and this change just adds
seatbelts to Linux.
Roger.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v3 0/2] Clear .bss for VP guests
2016-02-26 15:10 ` [Xen-devel] " Boris Ostrovsky
2016-02-26 15:12 ` David Vrabel
2016-02-26 15:12 ` [Xen-devel] " David Vrabel
@ 2016-02-26 15:22 ` Roger Pau Monné
2016-02-26 15:22 ` [Xen-devel] " Roger Pau Monné
3 siblings, 0 replies; 26+ messages in thread
From: Roger Pau Monné @ 2016-02-26 15:22 UTC (permalink / raw)
To: Boris Ostrovsky, Brian Gerst
Cc: andrew.cooper3, Linux Kernel Mailing List, mcgrof, David Vrabel,
xen-devel
El 26/2/16 a les 16:10, Boris Ostrovsky ha escrit:
> On 02/26/2016 09:42 AM, Brian Gerst wrote:
>> On Fri, Feb 26, 2016 at 8:51 AM, Boris Ostrovsky
>> <boris.ostrovsky@oracle.com> wrote:
>>> On 02/26/2016 05:53 AM, Roger Pau Monné wrote:
>>>> El 25/2/16 a les 16:16, Boris Ostrovsky ha escrit:
>>>>> PV guests need to have their .bss zeroed out since it is not
>>>>> guaranteed
>>>>> to be cleared by Xen's domain builder
>>>> I guess I'm missing something, but elf_load_image (in libelf-loader.c)
>>>> seems to be able to clear segments (it will zero the memory between
>>>> p_paddr + p_filesz and p_paddr + p_memsz) while loading the ELF into
>>>> memory, so if the program headers are correctly setup the .bss
>>>> should be
>>>> zeroed out AFAICT.
>>>
>>> Right, but I don't think this is guaranteed. It's uninitialized data
>>> so in
>>> principle it can be anything.
>>>
>>> The ELF spec says "the system initializes the data with zero when the
>>> program begins to run" which I read as it's up to runtime and not the
>>> loader
>>> to do so.
>>>
>>> And since kernel does it explicitly on baremetal path I think it's a
>>> good
>>> idea for PV to do the same.
>> It does it on bare metal because bzImage is a raw binary image, not ELF.
>
> OK, I didn't think about this.
>
> But nevertheless, is it guaranteed that .bss is cleared by the loader?
> My reading of the spec is that it's not.
I think this is very blur in general. The copy of the spec I have says:
"the system initializes the data with zeros when the program begins to run"
What is "the system" here, Xen or the guest kernel?
Just to be clear, I'm not opposing to this change in any way, but the
message in patch 1/2 needs to be fixed:
"They have been able to run without problems because Xen domain builder
happens to give out zeroed pages."
This is wrong IMHO, .bss is not cleared because we are using zeroed
pages, but because elf_load_image explicitly zeroes the space between
p_filesz and p_memsz in ELF program headers (which is were .bss resides
on properly arranged ELF binaries) when loading them.
I'm quite sure NetBSD also relies on this, so I would say it's
intrinsically part of the Xen boot ABI now, and this change just adds
seatbelts to Linux.
Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Xen-devel] [PATCH v3 0/2] Clear .bss for VP guests
2016-02-26 15:22 ` [Xen-devel] " Roger Pau Monné
@ 2016-02-26 15:26 ` David Vrabel
2016-02-26 15:38 ` Boris Ostrovsky
2016-02-26 15:38 ` [Xen-devel] " Boris Ostrovsky
2016-02-26 15:26 ` David Vrabel
` (2 subsequent siblings)
3 siblings, 2 replies; 26+ messages in thread
From: David Vrabel @ 2016-02-26 15:26 UTC (permalink / raw)
To: Roger Pau Monné, Boris Ostrovsky, Brian Gerst
Cc: Konrad Rzeszutek Wilk, andrew.cooper3, Linux Kernel Mailing List,
mcgrof, xen-devel
On 26/02/16 15:22, Roger Pau Monné wrote:
> El 26/2/16 a les 16:10, Boris Ostrovsky ha escrit:
>> On 02/26/2016 09:42 AM, Brian Gerst wrote:
>>> On Fri, Feb 26, 2016 at 8:51 AM, Boris Ostrovsky
>>> <boris.ostrovsky@oracle.com> wrote:
>>>> On 02/26/2016 05:53 AM, Roger Pau Monné wrote:
>>>>> El 25/2/16 a les 16:16, Boris Ostrovsky ha escrit:
>>>>>> PV guests need to have their .bss zeroed out since it is not
>>>>>> guaranteed
>>>>>> to be cleared by Xen's domain builder
>>>>> I guess I'm missing something, but elf_load_image (in libelf-loader.c)
>>>>> seems to be able to clear segments (it will zero the memory between
>>>>> p_paddr + p_filesz and p_paddr + p_memsz) while loading the ELF into
>>>>> memory, so if the program headers are correctly setup the .bss
>>>>> should be
>>>>> zeroed out AFAICT.
>>>>
>>>> Right, but I don't think this is guaranteed. It's uninitialized data
>>>> so in
>>>> principle it can be anything.
>>>>
>>>> The ELF spec says "the system initializes the data with zero when the
>>>> program begins to run" which I read as it's up to runtime and not the
>>>> loader
>>>> to do so.
>>>>
>>>> And since kernel does it explicitly on baremetal path I think it's a
>>>> good
>>>> idea for PV to do the same.
>>> It does it on bare metal because bzImage is a raw binary image, not ELF.
>>
>> OK, I didn't think about this.
>>
>> But nevertheless, is it guaranteed that .bss is cleared by the loader?
>> My reading of the spec is that it's not.
>
> I think this is very blur in general. The copy of the spec I have says:
>
> "the system initializes the data with zeros when the program begins to run"
>
> What is "the system" here, Xen or the guest kernel?
>
> Just to be clear, I'm not opposing to this change in any way, but the
> message in patch 1/2 needs to be fixed:
>
> "They have been able to run without problems because Xen domain builder
> happens to give out zeroed pages."
>
> This is wrong IMHO, .bss is not cleared because we are using zeroed
> pages, but because elf_load_image explicitly zeroes the space between
> p_filesz and p_memsz in ELF program headers (which is were .bss resides
> on properly arranged ELF binaries) when loading them.
>
> I'm quite sure NetBSD also relies on this, so I would say it's
> intrinsically part of the Xen boot ABI now, and this change just adds
> seatbelts to Linux.
The tools support loading bzImages, not just ELF images.
David
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v3 0/2] Clear .bss for VP guests
2016-02-26 15:22 ` [Xen-devel] " Roger Pau Monné
2016-02-26 15:26 ` David Vrabel
@ 2016-02-26 15:26 ` David Vrabel
2016-02-26 15:30 ` Boris Ostrovsky
2016-02-26 15:30 ` [Xen-devel] " Boris Ostrovsky
3 siblings, 0 replies; 26+ messages in thread
From: David Vrabel @ 2016-02-26 15:26 UTC (permalink / raw)
To: Roger Pau Monné, Boris Ostrovsky, Brian Gerst
Cc: andrew.cooper3, mcgrof, xen-devel, Linux Kernel Mailing List
On 26/02/16 15:22, Roger Pau Monné wrote:
> El 26/2/16 a les 16:10, Boris Ostrovsky ha escrit:
>> On 02/26/2016 09:42 AM, Brian Gerst wrote:
>>> On Fri, Feb 26, 2016 at 8:51 AM, Boris Ostrovsky
>>> <boris.ostrovsky@oracle.com> wrote:
>>>> On 02/26/2016 05:53 AM, Roger Pau Monné wrote:
>>>>> El 25/2/16 a les 16:16, Boris Ostrovsky ha escrit:
>>>>>> PV guests need to have their .bss zeroed out since it is not
>>>>>> guaranteed
>>>>>> to be cleared by Xen's domain builder
>>>>> I guess I'm missing something, but elf_load_image (in libelf-loader.c)
>>>>> seems to be able to clear segments (it will zero the memory between
>>>>> p_paddr + p_filesz and p_paddr + p_memsz) while loading the ELF into
>>>>> memory, so if the program headers are correctly setup the .bss
>>>>> should be
>>>>> zeroed out AFAICT.
>>>>
>>>> Right, but I don't think this is guaranteed. It's uninitialized data
>>>> so in
>>>> principle it can be anything.
>>>>
>>>> The ELF spec says "the system initializes the data with zero when the
>>>> program begins to run" which I read as it's up to runtime and not the
>>>> loader
>>>> to do so.
>>>>
>>>> And since kernel does it explicitly on baremetal path I think it's a
>>>> good
>>>> idea for PV to do the same.
>>> It does it on bare metal because bzImage is a raw binary image, not ELF.
>>
>> OK, I didn't think about this.
>>
>> But nevertheless, is it guaranteed that .bss is cleared by the loader?
>> My reading of the spec is that it's not.
>
> I think this is very blur in general. The copy of the spec I have says:
>
> "the system initializes the data with zeros when the program begins to run"
>
> What is "the system" here, Xen or the guest kernel?
>
> Just to be clear, I'm not opposing to this change in any way, but the
> message in patch 1/2 needs to be fixed:
>
> "They have been able to run without problems because Xen domain builder
> happens to give out zeroed pages."
>
> This is wrong IMHO, .bss is not cleared because we are using zeroed
> pages, but because elf_load_image explicitly zeroes the space between
> p_filesz and p_memsz in ELF program headers (which is were .bss resides
> on properly arranged ELF binaries) when loading them.
>
> I'm quite sure NetBSD also relies on this, so I would say it's
> intrinsically part of the Xen boot ABI now, and this change just adds
> seatbelts to Linux.
The tools support loading bzImages, not just ELF images.
David
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Xen-devel] [PATCH v3 0/2] Clear .bss for VP guests
2016-02-26 15:22 ` [Xen-devel] " Roger Pau Monné
` (2 preceding siblings ...)
2016-02-26 15:30 ` Boris Ostrovsky
@ 2016-02-26 15:30 ` Boris Ostrovsky
3 siblings, 0 replies; 26+ messages in thread
From: Boris Ostrovsky @ 2016-02-26 15:30 UTC (permalink / raw)
To: Roger Pau Monné, Brian Gerst
Cc: Konrad Rzeszutek Wilk, David Vrabel, andrew.cooper3,
Linux Kernel Mailing List, mcgrof, xen-devel
On 02/26/2016 10:22 AM, Roger Pau Monné wrote:
> El 26/2/16 a les 16:10, Boris Ostrovsky ha escrit:
>> On 02/26/2016 09:42 AM, Brian Gerst wrote:
>>> On Fri, Feb 26, 2016 at 8:51 AM, Boris Ostrovsky
>>> <boris.ostrovsky@oracle.com> wrote:
>>>> On 02/26/2016 05:53 AM, Roger Pau Monné wrote:
>>>>> El 25/2/16 a les 16:16, Boris Ostrovsky ha escrit:
>>>>>> PV guests need to have their .bss zeroed out since it is not
>>>>>> guaranteed
>>>>>> to be cleared by Xen's domain builder
>>>>> I guess I'm missing something, but elf_load_image (in libelf-loader.c)
>>>>> seems to be able to clear segments (it will zero the memory between
>>>>> p_paddr + p_filesz and p_paddr + p_memsz) while loading the ELF into
>>>>> memory, so if the program headers are correctly setup the .bss
>>>>> should be
>>>>> zeroed out AFAICT.
>>>> Right, but I don't think this is guaranteed. It's uninitialized data
>>>> so in
>>>> principle it can be anything.
>>>>
>>>> The ELF spec says "the system initializes the data with zero when the
>>>> program begins to run" which I read as it's up to runtime and not the
>>>> loader
>>>> to do so.
>>>>
>>>> And since kernel does it explicitly on baremetal path I think it's a
>>>> good
>>>> idea for PV to do the same.
>>> It does it on bare metal because bzImage is a raw binary image, not ELF.
>> OK, I didn't think about this.
>>
>> But nevertheless, is it guaranteed that .bss is cleared by the loader?
>> My reading of the spec is that it's not.
> I think this is very blur in general. The copy of the spec I have says:
>
> "the system initializes the data with zeros when the program begins to run"
>
> What is "the system" here, Xen or the guest kernel?
>
> Just to be clear, I'm not opposing to this change in any way, but the
> message in patch 1/2 needs to be fixed:
>
> "They have been able to run without problems because Xen domain builder
> happens to give out zeroed pages."
>
> This is wrong IMHO, .bss is not cleared because we are using zeroed
> pages, but because elf_load_image explicitly zeroes the space between
> p_filesz and p_memsz in ELF program headers (which is were .bss resides
> on properly arranged ELF binaries) when loading them.
That's what I meant --- that the builder/loader gives out zeroed pages,
not that Xen's allocator clears them in general. I'll update the commit
message.
>
> I'm quite sure NetBSD also relies on this, so I would say it's
> intrinsically part of the Xen boot ABI now, and this change just adds
> seatbelts to Linux.
Maybe NetBSD should drive carefully then ;-)
-boris
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v3 0/2] Clear .bss for VP guests
2016-02-26 15:22 ` [Xen-devel] " Roger Pau Monné
2016-02-26 15:26 ` David Vrabel
2016-02-26 15:26 ` David Vrabel
@ 2016-02-26 15:30 ` Boris Ostrovsky
2016-02-26 15:30 ` [Xen-devel] " Boris Ostrovsky
3 siblings, 0 replies; 26+ messages in thread
From: Boris Ostrovsky @ 2016-02-26 15:30 UTC (permalink / raw)
To: Roger Pau Monné, Brian Gerst
Cc: andrew.cooper3, Linux Kernel Mailing List, mcgrof, David Vrabel,
xen-devel
On 02/26/2016 10:22 AM, Roger Pau Monné wrote:
> El 26/2/16 a les 16:10, Boris Ostrovsky ha escrit:
>> On 02/26/2016 09:42 AM, Brian Gerst wrote:
>>> On Fri, Feb 26, 2016 at 8:51 AM, Boris Ostrovsky
>>> <boris.ostrovsky@oracle.com> wrote:
>>>> On 02/26/2016 05:53 AM, Roger Pau Monné wrote:
>>>>> El 25/2/16 a les 16:16, Boris Ostrovsky ha escrit:
>>>>>> PV guests need to have their .bss zeroed out since it is not
>>>>>> guaranteed
>>>>>> to be cleared by Xen's domain builder
>>>>> I guess I'm missing something, but elf_load_image (in libelf-loader.c)
>>>>> seems to be able to clear segments (it will zero the memory between
>>>>> p_paddr + p_filesz and p_paddr + p_memsz) while loading the ELF into
>>>>> memory, so if the program headers are correctly setup the .bss
>>>>> should be
>>>>> zeroed out AFAICT.
>>>> Right, but I don't think this is guaranteed. It's uninitialized data
>>>> so in
>>>> principle it can be anything.
>>>>
>>>> The ELF spec says "the system initializes the data with zero when the
>>>> program begins to run" which I read as it's up to runtime and not the
>>>> loader
>>>> to do so.
>>>>
>>>> And since kernel does it explicitly on baremetal path I think it's a
>>>> good
>>>> idea for PV to do the same.
>>> It does it on bare metal because bzImage is a raw binary image, not ELF.
>> OK, I didn't think about this.
>>
>> But nevertheless, is it guaranteed that .bss is cleared by the loader?
>> My reading of the spec is that it's not.
> I think this is very blur in general. The copy of the spec I have says:
>
> "the system initializes the data with zeros when the program begins to run"
>
> What is "the system" here, Xen or the guest kernel?
>
> Just to be clear, I'm not opposing to this change in any way, but the
> message in patch 1/2 needs to be fixed:
>
> "They have been able to run without problems because Xen domain builder
> happens to give out zeroed pages."
>
> This is wrong IMHO, .bss is not cleared because we are using zeroed
> pages, but because elf_load_image explicitly zeroes the space between
> p_filesz and p_memsz in ELF program headers (which is were .bss resides
> on properly arranged ELF binaries) when loading them.
That's what I meant --- that the builder/loader gives out zeroed pages,
not that Xen's allocator clears them in general. I'll update the commit
message.
>
> I'm quite sure NetBSD also relies on this, so I would say it's
> intrinsically part of the Xen boot ABI now, and this change just adds
> seatbelts to Linux.
Maybe NetBSD should drive carefully then ;-)
-boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Xen-devel] [PATCH v3 0/2] Clear .bss for VP guests
2016-02-26 15:26 ` David Vrabel
2016-02-26 15:38 ` Boris Ostrovsky
@ 2016-02-26 15:38 ` Boris Ostrovsky
1 sibling, 0 replies; 26+ messages in thread
From: Boris Ostrovsky @ 2016-02-26 15:38 UTC (permalink / raw)
To: David Vrabel, Roger Pau Monné, Brian Gerst
Cc: Konrad Rzeszutek Wilk, andrew.cooper3, Linux Kernel Mailing List,
mcgrof, xen-devel
On 02/26/2016 10:26 AM, David Vrabel wrote:
>
> The tools support loading bzImages, not just ELF images.
We load them as ELF images though, I believe, after uncompressing. E.g.:
static int xc_dom_load_bzimage_kernel(struct xc_dom_image *dom)
{
return elf_loader.loader(dom);
}
-boris
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v3 0/2] Clear .bss for VP guests
2016-02-26 15:26 ` David Vrabel
@ 2016-02-26 15:38 ` Boris Ostrovsky
2016-02-26 15:38 ` [Xen-devel] " Boris Ostrovsky
1 sibling, 0 replies; 26+ messages in thread
From: Boris Ostrovsky @ 2016-02-26 15:38 UTC (permalink / raw)
To: David Vrabel, Roger Pau Monné, Brian Gerst
Cc: andrew.cooper3, mcgrof, xen-devel, Linux Kernel Mailing List
On 02/26/2016 10:26 AM, David Vrabel wrote:
>
> The tools support loading bzImages, not just ELF images.
We load them as ELF images though, I believe, after uncompressing. E.g.:
static int xc_dom_load_bzimage_kernel(struct xc_dom_image *dom)
{
return elf_loader.loader(dom);
}
-boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH v3 0/2] Clear .bss for VP guests
@ 2016-02-25 15:16 Boris Ostrovsky
0 siblings, 0 replies; 26+ messages in thread
From: Boris Ostrovsky @ 2016-02-25 15:16 UTC (permalink / raw)
To: konrad.wilk, david.vrabel
Cc: andrew.cooper3, linux-kernel, mcgrof, brgerst, xen-devel,
Boris Ostrovsky
PV guests need to have their .bss zeroed out since it is not guaranteed
to be cleared by Xen's domain builder
v3:
* Use existing macros for selecting mode-appropriate instructions/registers
* Use 32-bit registers in XOR
* Split removal of mode-selecting ifdefs into a separate patch
Boris Ostrovsky (2):
xen/x86: Zero out .bss for PV guests
xen/x86: Drop mode-selecting ifdefs in startup_xen()
arch/x86/xen/xen-head.S | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
--
2.1.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2016-02-26 15:38 UTC | newest]
Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-02-25 15:16 [PATCH v3 0/2] Clear .bss for VP guests Boris Ostrovsky
2016-02-25 15:16 ` [PATCH v3 1/2] xen/x86: Zero out .bss for PV guests Boris Ostrovsky
2016-02-25 16:12 ` Brian Gerst
2016-02-25 16:12 ` Brian Gerst
2016-02-25 15:16 ` Boris Ostrovsky
2016-02-25 15:16 ` [PATCH v3 2/2] xen/x86: Drop mode-selecting ifdefs in startup_xen() Boris Ostrovsky
2016-02-25 15:16 ` Boris Ostrovsky
2016-02-26 10:53 ` [PATCH v3 0/2] Clear .bss for VP guests Roger Pau Monné
2016-02-26 10:53 ` [Xen-devel] " Roger Pau Monné
2016-02-26 13:51 ` Boris Ostrovsky
2016-02-26 14:42 ` Brian Gerst
2016-02-26 14:42 ` [Xen-devel] " Brian Gerst
2016-02-26 15:10 ` Boris Ostrovsky
2016-02-26 15:10 ` [Xen-devel] " Boris Ostrovsky
2016-02-26 15:12 ` David Vrabel
2016-02-26 15:12 ` [Xen-devel] " David Vrabel
2016-02-26 15:22 ` Roger Pau Monné
2016-02-26 15:22 ` [Xen-devel] " Roger Pau Monné
2016-02-26 15:26 ` David Vrabel
2016-02-26 15:38 ` Boris Ostrovsky
2016-02-26 15:38 ` [Xen-devel] " Boris Ostrovsky
2016-02-26 15:26 ` David Vrabel
2016-02-26 15:30 ` Boris Ostrovsky
2016-02-26 15:30 ` [Xen-devel] " Boris Ostrovsky
2016-02-26 13:51 ` Boris Ostrovsky
-- strict thread matches above, loose matches on Subject: below --
2016-02-25 15:16 Boris Ostrovsky
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.