> On 13 Jan 2023, at 10:11, Julien Grall <jul...@xen.org> wrote: > > From: Julien Grall <jgr...@amazon.com> > > At the moment, bootloaders can load Xen anywhere in memory but the > region 2MB - 4MB. While I am not aware of any issue, we have no way > to tell the bootloader to avoid that region. > > In addition to that, in the future, Xen may grow over 2MB if we > enable feature like UBSAN or GCOV. To avoid widening the restriction > on the load address, it would be better to get rid of it. > > When the identity mapping is clashing with the Xen runtime mapping, > we need an extra indirection to be able to replace the identity > mapping with the Xen runtime mapping. > > Reserve a new memory region that will be used to temporarily map Xen. > For convenience, the new area is re-using the same first slot as the > domheap which is used for per-cpu temporary mapping after a CPU has > booted. > > Furthermore, directly map boot_second (which cover Xen and more) > to the temporary area. This will avoid to allocate an extra page-table > for the second-level and will helpful for follow-up patches (we will > want to use the fixmap whilst in the temporary mapping). > > Lastly, some part of the code now needs to know whether the temporary > mapping was created. So reserve r12 to store this information. > > Signed-off-by: Julien Grall <jgr...@amazon.com> > ---- >
Hi Julien, > > +/* > + * Remove the temporary mapping of Xen starting at TEMPORARY_XEN_VIRT_START. > + * > + * Clobbers r0 - r1 NIT: r0 - r3? > + */ > +remove_temporary_mapping: > + /* r2:r3 := invalid page-table entry */ > + mov r2, #0 > + mov r3, #0 > + > + adr_l r0, boot_pgtable > + mov_w r1, TEMPORARY_XEN_VIRT_START > + get_table_slot r1, r1, 1 /* r1 := first slot */ > + lsl r1, r1, #3 /* r1 := first slot offset */ > + strd r2, r3, [r0, r1] > + > + flush_xen_tlb_local r0 > + > + mov pc, lr > +ENDPROC(remove_temporary_mapping) > + The rest looks good to me, I’ve also built for arm64/32 and test this patch on fvp aarch32 mode, booting Dom0 and creating/running/destroying some guests. Reviewed-by: Luca Fancellu <luca.fance...@arm.com> Tested-by: Luca Fancellu <luca.fance...@arm.com> Cheers, Luca
