[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH] xen/common: Do not allocate magic pages 1:1 for direct mapped domains
On 26.02.2024 02:19, Henry Wang wrote: > --- a/xen/arch/arm/include/asm/mm.h > +++ b/xen/arch/arm/include/asm/mm.h > @@ -428,6 +428,19 @@ static inline void page_set_xenheap_gfn(struct page_info > *p, gfn_t gfn) > } while ( (y = cmpxchg(&p->u.inuse.type_info, x, nx)) != x ); > } > > +#define MAGIC_PAGE_N_GPFN(n) ((GUEST_MAGIC_BASE >> PAGE_SHIFT) + n) > +static inline bool is_magic_gpfn(xen_pfn_t gpfn) > +{ > + unsigned int i; > + for ( i = 0; i < NR_MAGIC_PAGES; i++ ) Nit: Blank line please between declaration(s) and statement(s). > --- a/xen/arch/ppc/include/asm/mm.h > +++ b/xen/arch/ppc/include/asm/mm.h > @@ -256,4 +256,9 @@ static inline bool arch_mfns_in_directmap(unsigned long > mfn, unsigned long nr) > return true; > } > > +static inline bool is_magic_gpfn(xen_pfn_t gpfn) > +{ > + return false; > +} > + > #endif /* _ASM_PPC_MM_H */ > --- a/xen/arch/riscv/include/asm/mm.h > +++ b/xen/arch/riscv/include/asm/mm.h > @@ -3,6 +3,7 @@ > #ifndef _ASM_RISCV_MM_H > #define _ASM_RISCV_MM_H > > +#include <public/xen.h> > #include <asm/page-bits.h> > > #define pfn_to_paddr(pfn) ((paddr_t)(pfn) << PAGE_SHIFT) > @@ -20,4 +21,9 @@ unsigned long calc_phys_offset(void); > > void turn_on_mmu(unsigned long ra); > > +static inline bool is_magic_gpfn(xen_pfn_t gpfn) > +{ > + return false; > +} > + > #endif /* _ASM_RISCV_MM_H */ > --- a/xen/arch/x86/include/asm/mm.h > +++ b/xen/arch/x86/include/asm/mm.h > @@ -628,4 +628,9 @@ static inline bool arch_mfns_in_directmap(unsigned long > mfn, unsigned long nr) > return (mfn + nr) <= (virt_to_mfn(eva - 1) + 1); > } > > +static inline bool is_magic_gpfn(xen_pfn_t gpfn) > +{ > + return false; > +} I don't think every arch should need to gain such a dummy function. Plus the function name doesn't clarify at all what kind of "magic" this is about. Plus I think the (being phased out) term "gpfn" would better not be used in new functions anymore. Instead type-safe gfn_t would likely better be used as parameter type. > --- a/xen/common/memory.c > +++ b/xen/common/memory.c > @@ -219,7 +219,7 @@ static void populate_physmap(struct memop_args *a) > } > else > { > - if ( is_domain_direct_mapped(d) ) > + if ( is_domain_direct_mapped(d) && !is_magic_gpfn(gpfn) ) > { > mfn = _mfn(gpfn); > I wonder whether is_domain_direct_mapped() shouldn't either be cloned into e.g. is_gfn_direct_mapped(d, gfn), or be adjusted in-place to gain such a (then optional) 2nd parameter. (Of course there again shouldn't be a need for every domain to define a stub is_domain_direct_mapped() - if not defined by an arch header, the stub can be supplied in a single central place.) > --- a/xen/include/public/arch-arm.h > +++ b/xen/include/public/arch-arm.h > @@ -476,6 +476,12 @@ typedef uint64_t xen_callback_t; > #define GUEST_MAGIC_BASE xen_mk_ullong(0x39000000) > #define GUEST_MAGIC_SIZE xen_mk_ullong(0x01000000) > > +#define NR_MAGIC_PAGES 4 > +#define CONSOLE_PFN_OFFSET 0 > +#define XENSTORE_PFN_OFFSET 1 > +#define MEMACCESS_PFN_OFFSET 2 > +#define VUART_PFN_OFFSET 3 > + > #define GUEST_RAM_BANKS 2 Of these only NR_MAGIC_PAGES is really used in Xen, afaics. Also while this is added to a tools-only section, I'm also concerned of the ongoing additions here without suitable XEN_ prefixes. Any number of kinds of magic pages may exist for other reasons in a platform; which ones are meant would therefore better be sufficiently clear from the identifier used. Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |