On 13.05.2024 15:40, Elias El Yandouzi wrote: > From: Hongyan Xia <hongy...@amazon.com> > > When there is not an always-mapped direct map, xenheap allocations need > to be mapped and unmapped on-demand. > > Signed-off-by: Hongyan Xia <hongy...@amazon.com> > Signed-off-by: Julien Grall <jgr...@amazon.com> > Signed-off-by: Elias El Yandouzi <elias...@amazon.com> > > ---- > > I have left the call to map_pages_to_xen() and destroy_xen_mappings() > in the split heap for now. I am not entirely convinced this is necessary > because in that setup only the xenheap would be always mapped and > this doesn't contain any guest memory (aside the grant-table). > So map/unmapping for every allocation seems unnecessary.
Kind of depends on whether you expect guest data to potentially be copied into memory that cam from the Xen heap, even if just transiently. > @@ -2317,6 +2350,12 @@ void free_xenheap_pages(void *v, unsigned int order) > for ( i = 0; i < (1u << order); i++ ) > pg[i].count_info &= ~PGC_xen_heap; > > + if ( !has_directmap() && > + destroy_xen_mappings(va, va + (1UL << (order + PAGE_SHIFT))) ) PAGE_SIZE << order ? Also, on x86 at least, to limit the impact of this, I think there wants to be a prereq change to modify_xen_mappings() limiting the final flush_area() there to just the one page altered, when it is just a single page that is being fiddled with. Jan
