From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH 3/4] xen: arm: rearrange guest physical address space to increase max RAM Date: Tue, 08 Apr 2014 17:01:17 +0100 Message-ID: <53441D4D.70602@linaro.org> References: <1396966739.22845.233.camel@kazak.uk.xensource.com> <1396966760-7752-3-git-send-email-ian.campbell@citrix.com> <534411CC.3050904@linaro.org> <1396970537.22845.253.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1396970537.22845.253.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: stefano.stabellini@eu.citrix.com, tim@xen.org, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org 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 >>> --- >>> 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