[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [XEN v3 2/9] xen/arm: Typecast the DT values into paddr_t
On 08.02.2023 13:05, Ayan Kumar Halder wrote: > In future, we wish to support 32 bit physical address. > However, the current dt and fdt functions can only read u64 values. > We wish to make the DT functions read u64 as well u32 values (depending > on the width of physical address). Also, we wish to detect if any > truncation has occurred (ie while reading u32 physical addresses from > u64 values read from DT). > > device_tree_get_reg() should now be able to return paddr_t. This is > invoked by various callers to get DT address and size. > > For fdt_get_mem_rsv(), we have introduced wrapper ie > fdt_get_mem_rsv_paddr() while will invoke fdt_get_mem_rsv() and translate > u64 to paddr_t. The reason being we cannot modify fdt_get_mem_rsv() as > it has been imported from external source. > > For dt_read_number(), we have also introduced a wrapper ie > dt_read_paddr() to read physical addresses. We chose not to modify the > original function as it been used in places where it needs to > specifically u64 values from dt (For eg dt_property_read_u64()). > > Xen prints an error when it detects a truncation (during typecast > between u64 and paddr_t). It is not possible to return an error in all > scenarios. So, it is user's responsibility to check the error logs. > > To detect truncation, we right shift physical address by > "PADDR_BITS - 1" and then if the resulting number is greater than 1, > we know that truncation has occurred and an appropriate error log is > printed. > > Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@xxxxxxx> > --- > > Changes from > > v1 - 1. Dropped "[XEN v1 2/9] xen/arm: Define translate_dt_address_size() for > the translation between u64 and paddr_t" and > "[XEN v1 4/9] xen/arm: Use translate_dt_address_size() to translate between > device tree addr/size and paddr_t", instead > this approach achieves the same purpose. > > 2. No need to check for truncation while converting values from u64 to > paddr_t. > > v2 - 1. Use "( (dt_start >> (PADDR_SHIFT - 1)) > 1 )" to detect truncation. > 2. Introduced libfdt_xen.h to implement fdt_get_mem_rsv_paddr > 3. Logged error messages in case truncation is detected. > > xen/arch/arm/bootfdt.c | 38 ++++++++++++++++----- > xen/arch/arm/domain_build.c | 2 +- > xen/arch/arm/include/asm/setup.h | 2 +- > xen/arch/arm/setup.c | 14 ++++---- > xen/arch/arm/smpboot.c | 2 +- > xen/include/xen/device_tree.h | 21 ++++++++++++ > xen/include/xen/libfdt/libfdt_xen.h | 52 +++++++++++++++++++++++++++++ > xen/include/xen/types.h | 2 ++ > 8 files changed, 115 insertions(+), 18 deletions(-) > create mode 100644 xen/include/xen/libfdt/libfdt_xen.h Can you please avoid underscores in the names of new files, unless they're strictly required for some reason? > @@ -53,10 +53,30 @@ static bool __init device_tree_node_compatible(const void > *fdt, int node, > } > > void __init device_tree_get_reg(const __be32 **cell, u32 address_cells, > - u32 size_cells, u64 *start, u64 *size) > + u32 size_cells, paddr_t *start, paddr_t > *size) > { > - *start = dt_next_cell(address_cells, cell); > - *size = dt_next_cell(size_cells, cell); > + u64 dt_start, dt_size; No new uses of this type (and its siblings), please. We're in the process of phasing out their use. See ./CODING_STYLE. > + /* > + * dt_next_cell will return u64 whereas paddr_t may be u64 or u32. Thus, > + * there is an implicit cast from u64 to paddr_t. > + */ > + dt_start = dt_next_cell(address_cells, cell); > + dt_size = dt_next_cell(size_cells, cell); > + > + if ( (dt_start >> (PADDR_SHIFT - 1)) > 1 ) > + printk("Error: Physical address greater than max width supported\n"); > + > + if ( (dt_size >> (PADDR_SHIFT - 1)) > 1 ) > + printk("Error: Physical size greater than max width supported\n"); While I assume you wrote the checks this way to avoid "shift count too large" compiler diagnostics, personally I think this is making it harder to recognize what is wanted. Already (val >> (PADDR_SHIFT - 1)) >> 1 would be better imo, by why not simply (paddr_t)val != val? > --- a/xen/include/xen/types.h > +++ b/xen/include/xen/types.h > @@ -71,4 +71,6 @@ typedef bool bool_t; > #define test_and_set_bool(b) xchg(&(b), true) > #define test_and_clear_bool(b) xchg(&(b), false) > > +#define PADDR_SHIFT PADDR_BITS Why do we need this alias? And if we need it, on what basis did you pick the file you've put it in? Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |