[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [RFC PATCH V1 04/12] xen/arm: Introduce arch specific bits for IOREQ/DM features
On Tue, 4 Aug 2020, Julien Grall wrote: > On 04/08/2020 08:49, Paul Durrant wrote: > > > diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c > > > index 931404c..b5fc066 100644 > > > --- a/tools/libxc/xc_dom_arm.c > > > +++ b/tools/libxc/xc_dom_arm.c > > > @@ -26,11 +26,19 @@ > > > #include "xg_private.h" > > > #include "xc_dom.h" > > > > > > -#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 IOREQ_SERVER_PFN_OFFSET 4 > > > + > > > +#define NR_IOREQ_SERVER_PAGES 8 > > > +#define NR_MAGIC_PAGES (4 + NR_IOREQ_SERVER_PAGES) > > > + > > > +#define GUEST_MAGIC_BASE_PFN (GUEST_MAGIC_BASE >> XC_PAGE_SHIFT) > > > + > > > +#define special_pfn(x) (GUEST_MAGIC_BASE_PFN + (x)) > > > > Why introduce 'magic pages' for Arm? It's quite a horrible hack that we have > > begun to do away with by adding resource mapping. > > This would require us to mandate at least Linux 4.17 in a domain that will run > an IOREQ server. If we don't mandate this, the minimum version would be 4.10 > where DM OP was introduced. > > Because of XSA-300, we could technically not safely run an IOREQ server with > existing Linux. So it is probably OK to enforce the use of the acquire > interface. +1
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |