[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.