[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 3/4] xen: arm: rearrange guest physical address space to increase max RAM
On 04/08/2014 04:22 PM, Ian Campbell wrote: > On Tue, 2014-04-08 at 16:12 +0100, Julien Grall wrote: >> Hi Ian, >> >> On 04/08/2014 03:19 PM, Ian Campbell wrote: >>> By switching things around we can manage to expose up to 3GB of RAM to >>> guests. >>> >>> I deliberately didn't place the RAM at address 0 to avoid coming to rely on >>> this, so the various peripherals, MMIO and magic pages etc all live in the >>> lower 1GB leaving the upper 3GB available for RAM. >>> >>> It would likely have been possible to reduce the space used by the >>> peripherals >>> etc and allow for 3.5 or 3.75GB but I decided to keep things simple and will >>> handle >3GB memory in a subsequent patch. >>> >>> Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx> >>> --- >>> xen/include/public/arch-arm.h | 18 +++++++++--------- >>> 1 file changed, 9 insertions(+), 9 deletions(-) >>> >>> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h >>> index b860da5..5840453 100644 >>> --- a/xen/include/public/arch-arm.h >>> +++ b/xen/include/public/arch-arm.h >>> @@ -364,18 +364,18 @@ typedef uint64_t xen_callback_t; >>> */ >>> >>> /* Physical Address Space */ >>> -#define GUEST_GICD_BASE 0x2c001000ULL >>> -#define GUEST_GICD_SIZE 0x1000ULL >>> -#define GUEST_GICC_BASE 0x2c002000ULL >>> -#define GUEST_GICC_SIZE 0x100ULL >>> +#define GUEST_GICD_BASE 0x03001000ULL >>> +#define GUEST_GICD_SIZE 0x00001000ULL >>> +#define GUEST_GICC_BASE 0x03002000ULL >>> +#define GUEST_GICC_SIZE 0x00000100ULL >>> >>> -#define GUEST_RAM_BASE 0x80000000ULL /* 768M at 2GB*/ >>> -#define GUEST_RAM_END 0xafffffffULL >>> - >>> -#define GUEST_GNTTAB_BASE 0xb0000000ULL >>> +#define GUEST_GNTTAB_BASE 0x38000000ULL >>> #define GUEST_GNTTAB_SIZE 0x00020000ULL >> >> Not related to this patch... while you are re-working the guest layout. >> Can you comment where does come from the GNTTAB_SIZE...? > > Stefano added that one, I assume he made it up... I didn't find any documentation in the code about it. >> Also, can you make sure that the GNTTAB_SIZE is greater or equal to the >> maximum number of frames (maybe by overriding max_nr_grant_frames)? > > It turns out that the current size corresponds to > DEFAULT_MAX_NR_GRANT_FRAMES, which explains where it came from. I know it... a comment in the code here would be great to avoid loosing 20mins every time we hit this define. > If you want to change this to reserve say 1MB of address space (which is > enough for 256 grant pages) or even more then please send a patch. > >> The current implementation on Linux only care about the number of frames >> given by Xen, the size of the table in the DT is not used. So the range >> may overlap to something else. > > That would be a guest bug, but nothing to do with this series. It's not really a guest bug ... we have an hypercall which provides the GNTTAB size (see gnttab_query_size). It returns max_nr_grant_frames which can be modified by the Xen command line. -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |