Re: [RFC] xen/arm: domain_build: introduce dom0_lowmem bootargs

[Peng Fan <van.freenix@gmail.com>]

Hi Julien,
On Tue, Sep 13, 2016 at 01:59:01PM +0100, Julien Grall wrote:
>Hello Peng,
>
>On 13/09/16 13:55, Peng Fan wrote:
>>On AArch64 SoCs, some IPs may only have the capability to access
>>32bits address space. The physical memory assigned for Dom0 maybe
>>not in 4GB address space, then the IPs will not work properly.
>>
>>Introduce dom0_lowmem bootargs, user could pass "dom0_lowmem=xx"
>>to xen. It means how much memory user would like to be allocated
>>in lower 4GB memory space. If there is not enough memory for
>>dom0_lowmem, higher memory will be allocated.
>>
>>Thinking such a memory layout on an AArch64 SoC:
>>Region 0: 2GB(0x80000000 - 0xffffffff)
>>Region 1: 4GB(0x880000000 - 0x97fffffff)
>>If user would like to assign 2GB for Dom0 and 1GB of the 2GB memory
>>in Region 0, user could pass "dom0=2048M dom0_lowmem=1024M" to xen.
>>
>>Signed-off-by: Peng Fan <peng.fan@nxp.com>
>>Cc: Stefano Stabellini <sstabellini@kernel.org>
>>Cc: Julien Grall <julien.grall@arm.com>
>>---
>>
>>This patch is to resolve the issue mentioned in
>>https://lists.xen.org/archives/html/xen-devel/2016-09/msg00235.html
>>This patch not tested on latest 4.8-unstable, I only tested similar
>>patch on xen 4.7 on AArch64 platform.
>
>Please test any patch send upstream on 4.8-unstable. The code may have
>changed.

I have rebase this patch based on 4.8-unstable.
latest commit:
"
commit a3fe74e4345e66ddb7aa514395260a5e5f8b0cdc
Author: Tamas K Lengyel <tamas.lengyel@zentific.com>
Date:   Mon Aug 1 11:59:14 2016 -0600

    arm/vm_event: get/set registers
"

Since I have not rebased my platform patches to 4.8-unstable, so have not tested.

Please kindly comments whether introudcing "dom0_lowmem" is acceptable or not
to resolve the issue I met in https://lists.xen.org/archives/html/xen-devel/2016-09/msg00235.html.

I'll rebase my platform patches and do some test.

>
>>
>>The idea of patch is that user could specify the lowmem that user would
>>like to use. I rethought the ideas in https://lists.xen.org/archives/html/xen-devel/2016-09/msg00487.html,
>>but that is not good. lowmem is precise, it maybe used for some IPs that maybe
>>passthrough to DomU, so we only allocate the needed memory for Dom0.
>
>Why? IPs passthrough to DomU will have to be protected by an SMMU so it does
>not matter whether Dom0 is using all the lowmem or not.

I just think there maybe some cases that some physical memory need to be
reserved for DomU usage.
SMMU is not a must when we passthrough a non DMA capable device to DomU.
So I think an DRAM area can be encoded in dts, and passthrough to DomU.

Thanks,
Peng.
>
>Regards,
>
>>
>> xen/arch/arm/domain_build.c | 30 +++++++++++++++++++++++++++++-
>> 1 file changed, 29 insertions(+), 1 deletion(-)
>>
>>diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>>index 35ab08d..0f53bba 100644
>>--- a/xen/arch/arm/domain_build.c
>>+++ b/xen/arch/arm/domain_build.c
>>@@ -33,6 +33,8 @@ int dom0_11_mapping = 1;
>>
>> #define DOM0_MEM_DEFAULT 0x8000000 /* 128 MiB */
>> static u64 __initdata dom0_mem = DOM0_MEM_DEFAULT;
>>+/* Only for AArch64 */
>>+static u64 __initdata dom0_lowmem;
>>
>> static void __init parse_dom0_mem(const char *s)
>> {
>>@@ -42,6 +44,12 @@ static void __init parse_dom0_mem(const char *s)
>> }
>> custom_param("dom0_mem", parse_dom0_mem);
>>
>>+static void __init parse_dom0_lowmem(const char *s)
>>+{
>>+    dom0_lowmem = parse_size_and_unit(s, &s);
>>+}
>>+custom_param("dom0_lowmem", parse_dom0_lowmem);
>>+
>> //#define DEBUG_11_ALLOCATION
>> #ifdef DEBUG_11_ALLOCATION
>> # define D11PRINT(fmt, args...) printk(XENLOG_DEBUG fmt, ##args)
>>@@ -244,7 +252,7 @@ static void allocate_memory(struct domain *d, struct kernel_info *kinfo)
>>     unsigned int order = get_11_allocation_size(kinfo->unassigned_mem);
>>     int i;
>>
>>-    bool_t lowmem = is_32bit_domain(d);
>>+    bool_t lowmem = is_32bit_domain(d) || !!dom0_lowmem;
>>     unsigned int bits;
>>
>>     /*
>>@@ -263,6 +271,9 @@ static void allocate_memory(struct domain *d, struct kernel_info *kinfo)
>>      * First try and allocate the largest thing we can as low as
>>      * possible to be bank 0.
>>      */
>>+    if ( dom0_lowmem )
>>+        order = get_order_from_bytes(dom0_lowmem);
>>+
>>     while ( order >= min_low_order )
>>     {
>>         for ( bits = order ; bits <= (lowmem ? 32 : PADDR_BITS); bits++ )
>>@@ -278,6 +289,11 @@ static void allocate_memory(struct domain *d, struct kernel_info *kinfo)
>>
>>  got_bank0:
>>
>>+    if ( dom0_lowmem ) {
>>+        dom0_lowmem -= pfn_to_paddr((1 << order));
>>+        lowmem = is_32bit_domain(d) || !!dom0_lowmem;
>>+    }
>>+
>>     if ( !insert_11_bank(d, kinfo, pg, order) )
>>         BUG(); /* Cannot fail for first bank */
>>
>>@@ -325,6 +341,16 @@ static void allocate_memory(struct domain *d, struct kernel_info *kinfo)
>>             }
>>         }
>>
>>+        if ( dom0_lowmem && lowmem )
>>+        {
>>+            dom0_lowmem -= pfn_to_paddr((1 << order));
>>+            lowmem = is_32bit_domain(d) || !!dom0_lowmem;
>>+        }
>>+	else
>>+        {
>>+            lowmem = false;
>>+        }
>>+
>>         /*
>>          * Success, next time around try again to get the largest order
>>          * allocation possible.
>>@@ -2098,6 +2124,8 @@ int construct_dom0(struct domain *d)
>>
>>     d->max_pages = ~0U;
>>
>>+    BUG_ON(dom0_mem < dom0_lowmem);
>>+
>>     kinfo.unassigned_mem = dom0_mem;
>>
>>     rc = kernel_probe(&kinfo);
>>
>
>-- 
>Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel