All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC] xen/arm: domain_build: introduce dom0_lowmem bootargs
@ 2016-09-13 12:55 Peng Fan
  2016-09-13 12:59 ` Julien Grall
  0 siblings, 1 reply; 6+ messages in thread
From: Peng Fan @ 2016-09-13 12:55 UTC (permalink / raw)
  To: sstabellini, julien.grall; +Cc: Peng Fan, xen-devel

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.

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.

 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);
-- 
2.6.6


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

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [RFC] xen/arm: domain_build: introduce dom0_lowmem bootargs
  2016-09-13 12:55 [RFC] xen/arm: domain_build: introduce dom0_lowmem bootargs Peng Fan
@ 2016-09-13 12:59 ` Julien Grall
  2016-09-13 13:12   ` Peng Fan
  0 siblings, 1 reply; 6+ messages in thread
From: Julien Grall @ 2016-09-13 12:59 UTC (permalink / raw)
  To: Peng Fan, sstabellini; +Cc: Peng Fan, xen-devel

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.

>
> 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.

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [RFC] xen/arm: domain_build: introduce dom0_lowmem bootargs
  2016-09-13 12:59 ` Julien Grall
@ 2016-09-13 13:12   ` Peng Fan
  2016-09-13 13:24     ` Julien Grall
  0 siblings, 1 reply; 6+ messages in thread
From: Peng Fan @ 2016-09-13 13:12 UTC (permalink / raw)
  To: Julien Grall; +Cc: Peng Fan, sstabellini, xen-devel

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [RFC] xen/arm: domain_build: introduce dom0_lowmem bootargs
  2016-09-13 13:12   ` Peng Fan
@ 2016-09-13 13:24     ` Julien Grall
  2016-09-14  1:31       ` Peng Fan
  0 siblings, 1 reply; 6+ messages in thread
From: Julien Grall @ 2016-09-13 13:24 UTC (permalink / raw)
  To: Peng Fan; +Cc: Peng Fan, sstabellini, xen-devel



On 13/09/16 14:12, Peng Fan wrote:
> 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.

How do you make sure that DomU will program the device with the correct 
address? A malicious DomU could decide to use a physical address 
belonging to another DomU or even Xen and would be able to read/write on it.

So if a device needs to access the physical memory it either needs to be 
protected by an SMMU or Xen/DOM0 is programming the device on behalf of 
the guest. All other solutions are IHMO unsafe.

Regards,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [RFC] xen/arm: domain_build: introduce dom0_lowmem bootargs
  2016-09-13 13:24     ` Julien Grall
@ 2016-09-14  1:31       ` Peng Fan
  2016-09-14  7:16         ` Julien Grall
  0 siblings, 1 reply; 6+ messages in thread
From: Peng Fan @ 2016-09-14  1:31 UTC (permalink / raw)
  To: Julien Grall; +Cc: Peng Fan, sstabellini, xen-devel

On Tue, Sep 13, 2016 at 02:24:31PM +0100, Julien Grall wrote:
>
>
>On 13/09/16 14:12, Peng Fan wrote:
>>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.
>
>How do you make sure that DomU will program the device with the correct
>address? A malicious DomU could decide to use a physical address belonging to
>another DomU or even Xen and would be able to read/write on it.

When I debug DomU, I use a uart port as an early console for DomU.
I just marked the uart with xen,passthrough and status disabled in Dom0 dts,
then in DomU dts, I create a uart node, and in xl cfg, I mapped the address
space. I did not use SMMU here. Just mapped the uart physical address
to DomU uart guest physical address. And DomU can access the uart for my
debug usage.

>
>So if a device needs to access the physical memory it either needs to be
>protected by an SMMU or Xen/DOM0 is programming the device on behalf of the
>guest. All other solutions are IHMO unsafe.

My understanding about reserve lowmem for DomU maybe not that correct.
I'll test this patch based on 4.8 and send out V2 later.

Thanks,
Peng.

>
>Regards,
>
>-- 
>Julien Grall

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [RFC] xen/arm: domain_build: introduce dom0_lowmem bootargs
  2016-09-14  1:31       ` Peng Fan
@ 2016-09-14  7:16         ` Julien Grall
  0 siblings, 0 replies; 6+ messages in thread
From: Julien Grall @ 2016-09-14  7:16 UTC (permalink / raw)
  To: Peng Fan; +Cc: Peng Fan, sstabellini, xen-devel

Hello Peng,

On 14/09/2016 02:31, Peng Fan wrote:
> On Tue, Sep 13, 2016 at 02:24:31PM +0100, Julien Grall wrote:
>>
>>
>> On 13/09/16 14:12, Peng Fan wrote:
>>> 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.
>>
>> How do you make sure that DomU will program the device with the correct
>> address? A malicious DomU could decide to use a physical address belonging to
>> another DomU or even Xen and would be able to read/write on it.
>
> When I debug DomU, I use a uart port as an early console for DomU.
> I just marked the uart with xen,passthrough and status disabled in Dom0 dts,
> then in DomU dts, I create a uart node, and in xl cfg, I mapped the address
> space. I did not use SMMU here. Just mapped the uart physical address
> to DomU uart guest physical address. And DomU can access the uart for my
> debug usage.

That's a different use case which does not involve UART reading directly 
the memory. Hence, there is no obligation to allocate lowmem for DomU.

Regards,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2016-09-14  7:16 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-09-13 12:55 [RFC] xen/arm: domain_build: introduce dom0_lowmem bootargs Peng Fan
2016-09-13 12:59 ` Julien Grall
2016-09-13 13:12   ` Peng Fan
2016-09-13 13:24     ` Julien Grall
2016-09-14  1:31       ` Peng Fan
2016-09-14  7:16         ` Julien Grall

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.