xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
* [Xen-devel] [PATCH] ARM/boot: Don't poison 'current' during early boot
@ 2020-01-15 18:43 Andrew Cooper
  2020-01-15 18:45 ` Julien Grall
  0 siblings, 1 reply; 2+ messages in thread
From: Andrew Cooper @ 2020-01-15 18:43 UTC (permalink / raw)
  To: Xen-devel
  Cc: Andrew Cooper, Stefano Stabellini, Julien Grall, Volodymyr Babchuk

This logic was inherited from x86 (which was updated several times since).
Unlike x86 (at the time) however, while NULL isn't mapped in ARM, 0xfffff000
is, making this actively dangerous.

Drop the logic entirely, and leave 'current' as NULL during early boot.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Julien Grall <julien@xen.org>
CC: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
---
 xen/arch/arm/setup.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 3c899cd4a0..9dd3738d44 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -798,9 +798,6 @@ void __init start_xen(unsigned long boot_phys_offset,
     percpu_init_areas();
     set_processor_id(0); /* needed early, for smp_processor_id() */
 
-    set_current((struct vcpu *)0xfffff000); /* debug sanity */
-    idle_vcpu[0] = current;
-
     setup_virtual_regions(NULL, NULL);
     /* Initialize traps early allow us to get backtrace when an error occurred */
     init_traps();
-- 
2.11.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [Xen-devel] [PATCH] ARM/boot: Don't poison 'current' during early boot
  2020-01-15 18:43 [Xen-devel] [PATCH] ARM/boot: Don't poison 'current' during early boot Andrew Cooper
@ 2020-01-15 18:45 ` Julien Grall
  0 siblings, 0 replies; 2+ messages in thread
From: Julien Grall @ 2020-01-15 18:45 UTC (permalink / raw)
  To: Andrew Cooper, Xen-devel; +Cc: Stefano Stabellini, Volodymyr Babchuk

Hi,

On 15/01/2020 18:43, Andrew Cooper wrote:
> This logic was inherited from x86 (which was updated several times since).
> Unlike x86 (at the time) however, while NULL isn't mapped in ARM, 0xfffff000
> is, making this actively dangerous.
> 
> Drop the logic entirely, and leave 'current' as NULL during early boot.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Thank you for the cleanup!

Acked-by: Julien Grall <julien@xen.org>

Cheers,

> ---
> CC: Stefano Stabellini <sstabellini@kernel.org>
> CC: Julien Grall <julien@xen.org>
> CC: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
> ---
>   xen/arch/arm/setup.c | 3 ---
>   1 file changed, 3 deletions(-)
> 
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 3c899cd4a0..9dd3738d44 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -798,9 +798,6 @@ void __init start_xen(unsigned long boot_phys_offset,
>       percpu_init_areas();
>       set_processor_id(0); /* needed early, for smp_processor_id() */
>   
> -    set_current((struct vcpu *)0xfffff000); /* debug sanity */
> -    idle_vcpu[0] = current;
> -
>       setup_virtual_regions(NULL, NULL);
>       /* Initialize traps early allow us to get backtrace when an error occurred */
>       init_traps();
> 

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2020-01-15 18:46 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-15 18:43 [Xen-devel] [PATCH] ARM/boot: Don't poison 'current' during early boot Andrew Cooper
2020-01-15 18:45 ` Julien Grall

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).