Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1342057 > unrolled thread

Re: [Xen-devel] [PATCH] xen/x86: Zero out .bss for PV guests

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [Xen-devel] [PATCH] xen/x86: Zero out .bss for PV guests David Vrabel <david.vrabel@citrix.com> - 2016-02-24 15:20 +0100
    Re: [Xen-devel] [PATCH] xen/x86: Zero out .bss for PV guests Andrew Cooper <andrew.cooper3@citrix.com> - 2016-02-24 15:20 +0100
      Re: [Xen-devel] [PATCH] xen/x86: Zero out .bss for PV guests Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2016-02-24 16:00 +0100
        Re: [Xen-devel] [PATCH] xen/x86: Zero out .bss for PV guests David Vrabel <david.vrabel@citrix.com> - 2016-02-24 16:00 +0100
          Re: [Xen-devel] [PATCH] xen/x86: Zero out .bss for PV guests "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-02-24 17:30 +0100
            Re: [Xen-devel] [PATCH] xen/x86: Zero out .bss for PV guests Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2016-02-24 17:50 +0100

#1342057 — Re: [Xen-devel] [PATCH] xen/x86: Zero out .bss for PV guests

On 22/02/16 22:06, Boris Ostrovsky wrote:
> Baremetal kernels clear .bss early in the boot. Since Xen PV guests don't
> excecute that early code they should do it too.
> 
> (Since we introduce macros for specifying 32- and 64-bit registers we
> can get rid of ifdefs in startup_xen())

.bss must have been cleared for PV guests otherwise they would be
horribly broken.  What was the method and why is it no longer sufficient?

David

[toc] | [next] | [standalone]

#1342058

On 24/02/16 14:12, David Vrabel wrote:
> On 22/02/16 22:06, Boris Ostrovsky wrote:
>> Baremetal kernels clear .bss early in the boot. Since Xen PV guests don't
>> excecute that early code they should do it too.
>>
>> (Since we introduce macros for specifying 32- and 64-bit registers we
>> can get rid of ifdefs in startup_xen())
> .bss must have been cleared for PV guests otherwise they would be
> horribly broken.  What was the method and why is it no longer sufficient?

The domain builder hands out zeroed pages.  I don't believe we guarantee
that the guests RAM is clean, but it is in practice.

~Andrew

[toc] | [prev] | [next] | [standalone]

#1342091

On 02/24/2016 09:15 AM, Andrew Cooper wrote:
> On 24/02/16 14:12, David Vrabel wrote:
>> On 22/02/16 22:06, Boris Ostrovsky wrote:
>>> Baremetal kernels clear .bss early in the boot. Since Xen PV guests don't
>>> excecute that early code they should do it too.
>>>
>>> (Since we introduce macros for specifying 32- and 64-bit registers we
>>> can get rid of ifdefs in startup_xen())
>> .bss must have been cleared for PV guests otherwise they would be
>> horribly broken.  What was the method and why is it no longer sufficient?

I couldn't find this being done anywhere, hence this patch.

> The domain builder hands out zeroed pages.  I don't believe we guarantee
> that the guests RAM is clean, but it is in practice.

OK, that's what I suspected but didn't actually look.

I, in fact, wonder whether this should go to stable trees as well.

-boris

[toc] | [prev] | [next] | [standalone]

#1342096

On 24/02/16 14:52, Boris Ostrovsky wrote:
> On 02/24/2016 09:15 AM, Andrew Cooper wrote:
>> On 24/02/16 14:12, David Vrabel wrote:
>>> On 22/02/16 22:06, Boris Ostrovsky wrote:
>>>> Baremetal kernels clear .bss early in the boot. Since Xen PV guests
>>>> don't
>>>> excecute that early code they should do it too.
>>>>
>>>> (Since we introduce macros for specifying 32- and 64-bit registers we
>>>> can get rid of ifdefs in startup_xen())
>>> .bss must have been cleared for PV guests otherwise they would be
>>> horribly broken.  What was the method and why is it no longer
>>> sufficient?
> 
> I couldn't find this being done anywhere, hence this patch.
> 
>> The domain builder hands out zeroed pages.  I don't believe we guarantee
>> that the guests RAM is clean, but it is in practice.
> 
> OK, that's what I suspected but didn't actually look.
> 
> I, in fact, wonder whether this should go to stable trees as well.

Yes.  Can you respin with a commit message explaining?  (Or just provide
the message here and I'll fix it up).

David

[toc] | [prev] | [next] | [standalone]

#1342174

On Wed, Feb 24, 2016 at 6:58 AM, David Vrabel <david.vrabel@citrix.com> wrote:
> Yes.  Can you respin with a commit message explaining?  (Or just provide
> the message here and I'll fix it up).

Is there no way to re-use somehow the clear_bss() from bare metal?
This uses a section range:

/* Don't add a printk in there. printk relies on the PDA which is not
initialized
   yet. */
static void __init clear_bss(void)
{
        memset(__bss_start, 0,
               (unsigned long) __bss_stop - (unsigned long) __bss_start);
}

Perhaps the section range might be different for PV guests? Or can
this simply not work even if one added a guest bss section size, or
would it be too late for PV guests, ie we need to do it in asm on PV
guests as you did? If so why.

 Luis

[toc] | [prev] | [next] | [standalone]

#1342206

On 02/24/2016 11:22 AM, Luis R. Rodriguez wrote:
> On Wed, Feb 24, 2016 at 6:58 AM, David Vrabel <david.vrabel@citrix.com> wrote:
>> Yes.  Can you respin with a commit message explaining?  (Or just provide
>> the message here and I'll fix it up).
> Is there no way to re-use somehow the clear_bss() from bare metal?

xen_start_info lives in .bss and it is initialized in startup assembly code.

We could move it to .data but I'd still want to do this first thing in 
startup_xen(). We may add more code there later that touches something 
in .bss and with delayed section clearing we may blow away that data.

-boris

> This uses a section range:
>
> /* Don't add a printk in there. printk relies on the PDA which is not
> initialized
>     yet. */
> static void __init clear_bss(void)
> {
>          memset(__bss_start, 0,
>                 (unsigned long) __bss_stop - (unsigned long) __bss_start);
> }
>
> Perhaps the section range might be different for PV guests? Or can
> this simply not work even if one added a guest bss section size, or
> would it be too late for PV guests, ie we need to do it in asm on PV
> guests as you did? If so why.
>
>   Luis

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web