[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XEN v1 3/9] xen/arm: Always use 'u64' instead of 'paddr_t' for address and size in DT


  • To: Julien Grall <julien@xxxxxxx>, Ayan Kumar Halder <ayan.kumar.halder@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • From: Ayan Kumar Halder <ayankuma@xxxxxxx>
  • Date: Fri, 16 Dec 2022 10:49:42 +0000
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=s8CHa+UHSPef6p9ZK91LClSezTyxzVEQ7UDVSErmdKg=; b=Ccpa8KEDtFiWXPZ78cfnREIGPpIIXicEuckKw7jFT5imjFKS2+pAPP59IKjLtZwO+VvaLWvOc3p9Hy+EorULY8A5s0d2SyszBIN71QpFuwjfhC85Mau0i0k4/MQ4ZWZJYCFqurtczV3g1n4HbiB9RStlMl93OuCak+xe0y2h4flC8WQaA5xuhnf6Zcllcc8Vpnc8CNMFl91LctY6FZQyAbqmTCHwwPiumm3dAB8LhFBQBe3BrEoLDAmYJIW/y2vCBBMMgrJgz8yVkqQFfpCjnhfZPaqRmtoWFLOKl5DvhJ6DnL47uP8Ph5rY2uHBdK6KRgw9NonRIln+xiwQwjgh0g==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TPN5gsqZ234Tb/xd+5xhfrkoH9tkxOPNrWBPi7JetoGpXDxJMD6pjhC7H4sNl/ijDCx4/MJvwaGzkraKr1uT1gCIS0aQEGrwlmZCbEdL0sQZ6gzFHPbkPAs5v6QAvw1DEu8V+VckFNWgOinSydOLg39wjKZydmW8TN5K+mg4EjdUZraMPioNMWChodA3dzoaXGESYYO8znch1gP0GSDXAPhCJp1b402mA/F2xTE6isgiCeNKzT93u8N6zXN3mNdHu5R3gRwCAM3ICxh9MOWicc+VXFNdD5FSQLhnzmybdU7lY/xT0a9IFVFXPVm3Lj08cxgMnBcq/E9g1G4RJ3rsUg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com;
  • Cc: sstabellini@xxxxxxxxxx, stefano.stabellini@xxxxxxx, Volodymyr_Babchuk@xxxxxxxx, bertrand.marquis@xxxxxxx
  • Delivery-date: Fri, 16 Dec 2022 10:49:56 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>


On 16/12/2022 09:57, Julien Grall wrote:
Hi,
Hi Julien,

This patch is actually a good example to demonstrate the extra amount of boiler plate required to use your new boiler.

On 15/12/2022 19:32, Ayan Kumar Halder wrote:
device_tree_get_reg(), dt_next_cell() uses u64 for address and size.
Thus, the caller needs to be fixed to pass u64 values and then invoke
translate_dt_address_size() to do the translation between u64 and paddr_t.

Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@xxxxxxx>
---
  xen/arch/arm/bootfdt.c | 22 ++++++++++++++--------
  1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 0085c28d74..835bb5feb9 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -14,6 +14,7 @@
  #include <xen/libfdt/libfdt.h>
  #include <xen/sort.h>
  #include <xsm/xsm.h>
+#include <asm/platform.h>
  #include <asm/setup.h>
    static bool __init device_tree_node_matches(const void *fdt, int node, @@ -68,7 +69,7 @@ static int __init device_tree_get_meminfo(const void *fdt, int node,
      unsigned int i, banks;
      const __be32 *cell;
      u32 reg_cells = address_cells + size_cells;
-    paddr_t start, size;
+    u64 start, size;
      struct meminfo *mem = data;
        if ( address_cells < 1 || size_cells < 1 )
@@ -219,7 +220,7 @@ static void __init process_multiboot_node(const void *fdt, int node,
      const struct fdt_property *prop;
      const __be32 *cell;
      bootmodule_kind kind;
-    paddr_t start, size;
+    u64 start, size;
      int len;
      /* sizeof("/chosen/") + DT_MAX_NAME + '/' + DT_MAX_NAME + '/0' => 92 */
      char path[92];
@@ -379,7 +380,8 @@ static int __init process_shm_node(const void *fdt, int node,
  {
      const struct fdt_property *prop, *prop_id, *prop_role;
      const __be32 *cell;
-    paddr_t paddr, gaddr, size;
+    paddr_t paddr = 0, gaddr = 0, size = 0;

For a first 0 is a valid address. So we should not use is as initialization.

+    u64 dt_paddr, dt_gaddr, dt_size;
      struct meminfo *mem = &bootinfo.reserved_mem;
      unsigned int i;
      int len;
@@ -443,10 +445,14 @@ static int __init process_shm_node(const void *fdt, int node,
      }
        cell = (const __be32 *)prop->data;
-    device_tree_get_reg(&cell, address_cells, address_cells, &paddr, &gaddr);
-    size = dt_next_cell(size_cells, &cell);
+    device_tree_get_reg(&cell, address_cells, address_cells, &dt_paddr,
+                        &dt_gaddr);
+    translate_dt_address_size(&dt_paddr, &dt_gaddr, &paddr, &gaddr
If we function return a value, then this should be checked. If not, then it should be explained.

In this case, it is not clear to me who is checking the conversion was successful.
Sorry, I missed this. The caller should have checked for the return value and "return -EINVAL" for the conversion error.

I am in two minds.

I am thinking that instead of returing error from translate_dt_address_size(), the function can invoke panic() when it detects incorrect address/size.

Any errors related to incorrect address/size (ie providing 64 bit for PA_32) should be treated as fatal. But I do not see any precedent for this (ie libfdt does not panic for an error).

We could return an error from translate_dt_address_size() as we are doing today. It means that the errors need to be checked by all the callers (which adds extra code).

- Ayan


Overall, I think this will increase the amount of code. So before doing the modification, I think we need to agree on whether this is worth it to check the device-tree values.

Cheers,




 


Rackspace

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