| Message ID | 1396966760-7752-3-git-send-email-ian.campbell@citrix.com |
|---|---|
| State | New |
| Headers | show |
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@citrix.com> > --- > 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...? 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)? 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. Regards,
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@citrix.com> > > --- > > 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... > 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. 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. Ian.
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@citrix.com> >>> --- >>> 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.
On Tue, 2014-04-08 at 17:01 +0100, Julien Grall wrote: > >> 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. Feel free to send a patch. > > 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. The tools could query this and use it to size the region, or we could just make the region be more than large enough. Patches welcome. Ian.
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 -#define GUEST_MAGIC_BASE 0xc0000000ULL +#define GUEST_MAGIC_BASE 0x39000000ULL + +#define GUEST_RAM_BASE 0x40000000ULL /* 3GB of RAM @ 1GB */ +#define GUEST_RAM_END 0xffffffffULL /* Interrupts */ #define GUEST_TIMER_VIRT_PPI 27
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@citrix.com> --- xen/include/public/arch-arm.h | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-)