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.coop...@citrix.com>
Thank you for the cleanup!
Acked-by: Julien Grall <jul...@xen.org>
Cheers,
---
CC: Stefano Stabellini <sstabell...@kernel.org>
CC: Julien Grall <jul...@xen.org>
CC: Volodymyr Babchuk <volodymyr_babc...@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
