[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 28/36] xen/arm: introduce xen_map_text_rw
Hi, On 07/03/2022 07:39, Jan Beulich wrote: On 04.03.2022 18:46, Marco Solieri wrote:From: Luca Miccio <lucmiccio@xxxxxxxxx> Introduce two new arm specific functions to temporarily map/unmap the Xen text read-write (the Xen text is mapped read-only by default by setup_pagetables): xen_map_text_rw and xen_unmap_text_rw. There is only one caller in the alternative framework. The non-colored implementation simply uses __vmap to do the mapping. In other words, there are no changes to the non-colored case. The colored implementation calculates Xen text physical addresses appropriately, according to the coloring configuration. Export vm_alloc because it is needed by the colored implementation of xen_map_text_rw.I'm afraid I view vm_alloc() as strictly an internal function to vmap.c. Even livepatching infrastructure has got away without making it non-static. I think we can get away from using vmap() here. We were using it because Xen text mappings are RX and this is enforced by the processor via SCTLR_EL1.WXN. The bit is cached in the TLB. Back then it wasn't very clear what would happen if we clear the bit. Looking at the latest Arm Arm (ARM DDI 0487H.a D5.10), there is now a section "TLB invalidation and System register control fields" providing more details. Reading the section, it should be safe to temporary disable WXN on every CPUs and make Xen text writable. @Marco, would you be able to have a look? Cheers, -- Julien Grall
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |