This commit introduces the static heap memory, which is parts of RAM
reserved in the beginning of the boot time for heap.
Firstly, since a new type of memory bank is needed for marking the
memory bank solely as the heap, this commit defines `enum membank_type`
and use this enum in function device_tree_get_meminfo(). Changes of
code are done accordingly following the introduction of this enum.
Also, this commit introduces the logic to parse the static heap
configuration in device tree. If the memory bank is reserved as heap
through `xen,static-heap` property in device tree `chosen` node, the
memory will be marked as static heap type.
A documentation section is added, describing the definition of static
heap memory and the method of enabling the static heap memory through
device tree at boot time.
Signed-off-by: Henry Wang <Henry.Wang@arm.com>
Signed-off-by: Penny Zheng <penny.zheng@arm.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org> # DT interface
---
Changes from v2 to v3:
- Define `enum membank_type` properly, drop the typedef.
- Rename the feature terminology to static heap.
- Rename MEMBANK_MEMORY to MEMBANK_DEFAULT and MEMBANK_XEN_DOMAIN to
MEMBANK_STATIC_DOMAIN. Add comments to `enum membank_type`.
- Correct typo, add the clarification of the static heap region
should contain enough memory below 4GB to cater 32-bit DMA for Arm32,
and add the 64KB alignment requirement in doc.
- Add Stefano's Acked-by for device tree interface.
Changes from v1 to v2:
- Rename the device tree property to xen,static-heap to avoid confusion.
- Change of commit msg and doc wording, correct typo in commit msg.
- Do not change the process_chosen_node() return type.
- Add an empty line in make_memory_node() memory type check to improve
readability.
- Use enum membank_type to make the memory type cleaner.
Changes from RFC to v1:
- Rename the terminology to reserved heap.
---
docs/misc/arm/device-tree/booting.txt | 48 +++++++++++++++++++++++++++
xen/arch/arm/bootfdt.c | 33 +++++++++++++++---
xen/arch/arm/domain_build.c | 8 +++--
xen/arch/arm/include/asm/setup.h | 22 +++++++++++-
xen/arch/arm/setup.c | 2 +-
5 files changed, 104 insertions(+), 9 deletions(-)
diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt
index 98253414b8..5ba7d186aa 100644
--- a/docs/misc/arm/device-tree/booting.txt
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -378,3 +378,51 @@ device-tree:
This will reserve a 512MB region starting at the host physical address
0x30000000 to be exclusively used by DomU1.
+
+
+Static Heap Memory
+==================
+
+The static heap memory refers to parts of RAM reserved in the beginning of
+boot time for heap. The memory is reserved by configuration in the device
+tree using physical address ranges.
+
+The static heap memory declared in the device tree defines the memory areas
+that will be reserved to be used exclusively as heap.
+
+- For Arm32, since there are separated heaps, the static heap will be used
+for both domheap and xenheap. The admin should make sure that the static
+heap region should contain enough memory below 4GB to cater 32-bit DMA.
+
+- For Arm64, since there is a single heap, the defined static heap areas
+shall always go to the heap allocator.
+
+The static heap memory is an optional feature and can be enabled by adding
+below device tree properties in the `chosen` node.
+
+The dtb should have the following properties:
+
+- xen,static-heap
+
+ Property under the top-level "chosen" node. It specifies the address
+ and size of Xen static heap memory. Note that at least a 64KB
+ alignment is required.
+
+- #xen,static-heap-address-cells and #xen,static-heap-size-cells
+
+ Specify the number of cells used for the address and size of the
+ "xen,static-heap" property under "chosen".
+
+Below is an example on how to specify the static heap in device tree:
+
+ / {
+ chosen {
+ #xen,static-heap-address-cells = <0x2>;
+ #xen,static-heap-size-cells = <0x2>;
+ xen,static-heap = <0x0 0x30000000 0x0 0x40000000>;
+ ...
+ };
+ };
+
+RAM starting from the host physical address 0x30000000 of 1GB size will
+be reserved as static heap.
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 1a79b969af..cb23fad571 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -64,7 +64,7 @@ void __init device_tree_get_reg(const __be32 **cell, u32 address_cells,
static int __init device_tree_get_meminfo(const void *fdt, int node,
const char *prop_name,
u32 address_cells, u32 size_cells,
- void *data, bool xen_domain)
+ void *data, enum membank_type type)
{
const struct fdt_property *prop;
unsigned int i, banks;
@@ -95,7 +95,7 @@ static int __init device_tree_get_meminfo(const void *fdt, int node,
continue;
mem->bank[mem->nr_banks].start = start;
mem->bank[mem->nr_banks].size = size;
- mem->bank[mem->nr_banks].xen_domain = xen_domain;
+ mem->bank[mem->nr_banks].type = type;
mem->nr_banks++;
}
@@ -185,7 +185,7 @@ static int __init process_memory_node(const void *fdt, int node,
void *data)
{
return device_tree_get_meminfo(fdt, node, "reg", address_cells, size_cells,
- data, false);
+ data, MEMBANK_DEFAULT);
}
static int __init process_reserved_memory_node(const void *fdt, int node,
@@ -301,6 +301,30 @@ static int __init process_chosen_node(const void *fdt, int node,
paddr_t start, end;
int len;
+ if ( fdt_get_property(fdt, node, "xen,static-heap", NULL) )
+ {
+ int rc;
+ u32 address_cells = device_tree_get_u32(fdt, node,
+ "#xen,static-heap-address-cells", 0);
+ u32 size_cells = device_tree_get_u32(fdt, node,
+ "#xen,static-heap-size-cells", 0);
+
+ printk("Checking for static heap in /chosen\n");
+ if ( address_cells < 1 || size_cells < 1 )
+ {
+ printk("fdt: node `%s': invalid #xen,static-heap-address-cells or #xen,static-heap-size-cells\n",
+ name);
+ return -EINVAL;
+ }
+
+ rc = device_tree_get_meminfo(fdt, node, "xen,static-heap",
+ address_cells, size_cells,
+ &bootinfo.reserved_mem,
+ MEMBANK_STATIC_HEAP);
+ if ( rc )
+ return rc;
+ }
+
printk("Checking for initrd in /chosen\n");
prop = fdt_get_property(fdt, node, "linux,initrd-start", &len);
@@ -360,7 +384,8 @@ static int __init process_domain_node(const void *fdt, int node,
"#xen,static-mem-size-cells", 0);
return device_tree_get_meminfo(fdt, node, "xen,static-mem", address_cells,
- size_cells, &bootinfo.reserved_mem, true);
+ size_cells, &bootinfo.reserved_mem,
+ MEMBANK_STATIC_DOMAIN);
}
static int __init early_scan_node(const void *fdt,
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index b76a84e8f5..0741645014 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1038,9 +1038,11 @@ static int __init make_memory_node(const struct domain *d,
if ( mem->nr_banks == 0 )
return -ENOENT;
- /* find first memory range not bound to a Xen domain */
- for ( i = 0; i < mem->nr_banks && mem->bank[i].xen_domain; i++ )
+ /* find first memory range not bound to a Xen domain nor heap */
+ for ( i = 0; i < mem->nr_banks &&
+ (mem->bank[i].type != MEMBANK_DEFAULT); i++ )
;
+
if ( i == mem->nr_banks )
return 0;
@@ -1062,7 +1064,7 @@ static int __init make_memory_node(const struct domain *d,
u64 start = mem->bank[i].start;
u64 size = mem->bank[i].size;
- if ( mem->bank[i].xen_domain )
+ if ( mem->bank[i].type == MEMBANK_STATIC_DOMAIN )
continue;
dt_dprintk(" Bank %d: %#"PRIx64"->%#"PRIx64"\n",
diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
index 5815ccf8c5..6bea15acff 100644
--- a/xen/arch/arm/include/asm/setup.h
+++ b/xen/arch/arm/include/asm/setup.h
@@ -22,11 +22,31 @@ typedef enum {
BOOTMOD_UNKNOWN
} bootmodule_kind;
+enum membank_type {
+ /*
+ * The MEMBANK_DEFAULT type refers to either reserved memory for the
+ * device (or firmware) or any memory that will be used by the allocator.
+ * The meaning depends on where the memory bank is actually used.
+ */
+ MEMBANK_DEFAULT,
+ /*
+ * The MEMBANK_STATIC_DOMAIN type is used to indicate whether the memory
+ * bank is bound to a static Xen domain. It is only valid when the bank
+ * is in reserved_mem.
+ */
+ MEMBANK_STATIC_DOMAIN,
+ /*
+ * The MEMBANK_STATIC_HEAP type is used to indicate whether the memory
+ * bank is reserved as static heap. It is only valid when the bank is
+ * in reserved_mem.
+ */
+ MEMBANK_STATIC_HEAP,
+};
struct membank {
paddr_t start;
paddr_t size;
- bool xen_domain; /* whether the memory bank is bound to a Xen domain. */
+ enum membank_type type;
};
struct meminfo {
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 7814fe323d..3c36c050bf 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -644,7 +644,7 @@ static void __init init_staticmem_pages(void)
for ( bank = 0 ; bank < bootinfo.reserved_mem.nr_banks; bank++ )
{
- if ( bootinfo.reserved_mem.bank[bank].xen_domain )
+ if ( bootinfo.reserved_mem.bank[bank].type == MEMBANK_STATIC_DOMAIN )
{
mfn_t bank_start = _mfn(PFN_UP(bootinfo.reserved_mem.bank[bank].start));
unsigned long bank_pages = PFN_DOWN(bootinfo.reserved_mem.bank[bank].size);
--
2.17.1Hi Henry,
While reviewing the binding sent by Penny I noticed some inconsistency
with the one you introduced. See below.
On 07/09/2022 09:36, Henry Wang wrote:
> +- xen,static-heap
> +
> + Property under the top-level "chosen" node. It specifies the address
> + and size of Xen static heap memory. Note that at least a 64KB
> + alignment is required.
> +
> +- #xen,static-heap-address-cells and #xen,static-heap-size-cells
> +
> + Specify the number of cells used for the address and size of the
> + "xen,static-heap" property under "chosen".
> +
> +Below is an example on how to specify the static heap in device tree:
> +
> + / {
> + chosen {
> + #xen,static-heap-address-cells = <0x2>;
> + #xen,static-heap-size-cells = <0x2>;
Your binding, is introduce #xen,static-heap-{address, size}-cells
whereas Penny's one is using #{address, size}-cells even if the property
is not "reg".
I would like some consistency in the way we define bindings. Looking at
the tree, we already seem to have introduced
#xen-static-mem-address-cells. So maybe we should follow your approach?
That said, I am wondering whether we should just use one set of property
name.
I am open to suggestion here. My only request is we are consistent (i.e.
this doesn't depend on who wrote the bindings).
Cheers,
--
Julien Grall
Hi Julien,
On 07/09/2022 13:36, Julien Grall wrote:
>
> Hi Henry,
>
> While reviewing the binding sent by Penny I noticed some inconsistency
> with the one you introduced. See below.
>
> On 07/09/2022 09:36, Henry Wang wrote:
>> +- xen,static-heap
>> +
>> + Property under the top-level "chosen" node. It specifies the address
>> + and size of Xen static heap memory. Note that at least a 64KB
>> + alignment is required.
>> +
>> +- #xen,static-heap-address-cells and #xen,static-heap-size-cells
>> +
>> + Specify the number of cells used for the address and size of the
>> + "xen,static-heap" property under "chosen".
>> +
>> +Below is an example on how to specify the static heap in device tree:
>> +
>> + / {
>> + chosen {
>> + #xen,static-heap-address-cells = <0x2>;
>> + #xen,static-heap-size-cells = <0x2>;
>
> Your binding, is introduce #xen,static-heap-{address, size}-cells
> whereas Penny's one is using #{address, size}-cells even if the property
> is not "reg".
>
> I would like some consistency in the way we define bindings. Looking at
> the tree, we already seem to have introduced
> #xen-static-mem-address-cells. So maybe we should follow your approach?
>
> That said, I am wondering whether we should just use one set of property
> name.
>
> I am open to suggestion here. My only request is we are consistent (i.e.
> this doesn't depend on who wrote the bindings).
>
In my opinion we should follow the device tree specification which states
that the #address-cells and #size-cells correspond to the reg property.
This would mean that for all the custom properties we introduce we need
custom address and size properties (just like for static-mem/static-heap).
~Michal
On 07/09/2022 13:12, Michal Orzel wrote:
> Hi Julien,
Hi Michal,
> On 07/09/2022 13:36, Julien Grall wrote:
>>
>> Hi Henry,
>>
>> While reviewing the binding sent by Penny I noticed some inconsistency
>> with the one you introduced. See below.
>>
>> On 07/09/2022 09:36, Henry Wang wrote:
>>> +- xen,static-heap
>>> +
>>> + Property under the top-level "chosen" node. It specifies the address
>>> + and size of Xen static heap memory. Note that at least a 64KB
>>> + alignment is required.
>>> +
>>> +- #xen,static-heap-address-cells and #xen,static-heap-size-cells
>>> +
>>> + Specify the number of cells used for the address and size of the
>>> + "xen,static-heap" property under "chosen".
>>> +
>>> +Below is an example on how to specify the static heap in device tree:
>>> +
>>> + / {
>>> + chosen {
>>> + #xen,static-heap-address-cells = <0x2>;
>>> + #xen,static-heap-size-cells = <0x2>;
>>
>> Your binding, is introduce #xen,static-heap-{address, size}-cells
>> whereas Penny's one is using #{address, size}-cells even if the property
>> is not "reg".
>>
>> I would like some consistency in the way we define bindings. Looking at
>> the tree, we already seem to have introduced
>> #xen-static-mem-address-cells. So maybe we should follow your approach?
>>
>> That said, I am wondering whether we should just use one set of property
>> name.
>>
>> I am open to suggestion here. My only request is we are consistent (i.e.
>> this doesn't depend on who wrote the bindings).
>>
> In my opinion we should follow the device tree specification which states
> that the #address-cells and #size-cells correspond to the reg property.
Hmmm.... Looking at [1], the two properties are not exclusive to 'reg'
Furthermore, I am not aware of any restriction for us to re-use them. Do
you have a pointer?
Cheers,
[1] https://elinux.org/Device_Tree_Mysteries#.23xxx-cells_property_name
>
> ~Michal
--
Julien Grall
On 07/09/2022 14:32, Julien Grall wrote:
> [CAUTION: External Email]
>
> On 07/09/2022 13:12, Michal Orzel wrote:
>> Hi Julien,
>
> Hi Michal,
>
>> On 07/09/2022 13:36, Julien Grall wrote:
>>>
>>> Hi Henry,
>>>
>>> While reviewing the binding sent by Penny I noticed some inconsistency
>>> with the one you introduced. See below.
>>>
>>> On 07/09/2022 09:36, Henry Wang wrote:
>>>> +- xen,static-heap
>>>> +
>>>> + Property under the top-level "chosen" node. It specifies the address
>>>> + and size of Xen static heap memory. Note that at least a 64KB
>>>> + alignment is required.
>>>> +
>>>> +- #xen,static-heap-address-cells and #xen,static-heap-size-cells
>>>> +
>>>> + Specify the number of cells used for the address and size of the
>>>> + "xen,static-heap" property under "chosen".
>>>> +
>>>> +Below is an example on how to specify the static heap in device tree:
>>>> +
>>>> + / {
>>>> + chosen {
>>>> + #xen,static-heap-address-cells = <0x2>;
>>>> + #xen,static-heap-size-cells = <0x2>;
>>>
>>> Your binding, is introduce #xen,static-heap-{address, size}-cells
>>> whereas Penny's one is using #{address, size}-cells even if the property
>>> is not "reg".
>>>
>>> I would like some consistency in the way we define bindings. Looking at
>>> the tree, we already seem to have introduced
>>> #xen-static-mem-address-cells. So maybe we should follow your approach?
>>>
>>> That said, I am wondering whether we should just use one set of property
>>> name.
>>>
>>> I am open to suggestion here. My only request is we are consistent (i.e.
>>> this doesn't depend on who wrote the bindings).
>>>
>> In my opinion we should follow the device tree specification which states
>> that the #address-cells and #size-cells correspond to the reg property.
>
> Hmmm.... Looking at [1], the two properties are not exclusive to 'reg'
> Furthermore, I am not aware of any restriction for us to re-use them. Do
> you have a pointer?
As we are discussing re-usage of #address-cells and #size-cells for custom properties that are not "reg",
I took this info from the latest device tree specs found under https://www.devicetree.org/specifications/:
"The #address-cells property defines the number of <u32> cells used to encode the address field in a child node's reg property"
and
"The #size-cells property defines the number of <u32> cells used to encode the size field in a child node’s reg property"
>
> Cheers,
>
> [1] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Felinux.org%2FDevice_Tree_Mysteries%23.23xxx-cells_property_name&data=05%7C01%7Cmichal.orzel%40amd.com%7C40290431f16748808b6308da90ccfc53%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637981507324472512%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=okN60ULg2Dx3cnlA5vPLMR%2F8QAKnbGmBpz7goXb5usw%3D&reserved=0
>
>>
>> ~Michal
>
> --
> Julien Grall
>
~Michal
On 07/09/2022 13:41, Michal Orzel wrote:
>
>
> On 07/09/2022 14:32, Julien Grall wrote:
>> [CAUTION: External Email]
>>
>> On 07/09/2022 13:12, Michal Orzel wrote:
>>> Hi Julien,
>>
>> Hi Michal,
>>
>>> On 07/09/2022 13:36, Julien Grall wrote:
>>>>
>>>> Hi Henry,
>>>>
>>>> While reviewing the binding sent by Penny I noticed some inconsistency
>>>> with the one you introduced. See below.
>>>>
>>>> On 07/09/2022 09:36, Henry Wang wrote:
>>>>> +- xen,static-heap
>>>>> +
>>>>> + Property under the top-level "chosen" node. It specifies the address
>>>>> + and size of Xen static heap memory. Note that at least a 64KB
>>>>> + alignment is required.
>>>>> +
>>>>> +- #xen,static-heap-address-cells and #xen,static-heap-size-cells
>>>>> +
>>>>> + Specify the number of cells used for the address and size of the
>>>>> + "xen,static-heap" property under "chosen".
>>>>> +
>>>>> +Below is an example on how to specify the static heap in device tree:
>>>>> +
>>>>> + / {
>>>>> + chosen {
>>>>> + #xen,static-heap-address-cells = <0x2>;
>>>>> + #xen,static-heap-size-cells = <0x2>;
>>>>
>>>> Your binding, is introduce #xen,static-heap-{address, size}-cells
>>>> whereas Penny's one is using #{address, size}-cells even if the property
>>>> is not "reg".
>>>>
>>>> I would like some consistency in the way we define bindings. Looking at
>>>> the tree, we already seem to have introduced
>>>> #xen-static-mem-address-cells. So maybe we should follow your approach?
>>>>
>>>> That said, I am wondering whether we should just use one set of property
>>>> name.
>>>>
>>>> I am open to suggestion here. My only request is we are consistent (i.e.
>>>> this doesn't depend on who wrote the bindings).
>>>>
>>> In my opinion we should follow the device tree specification which states
>>> that the #address-cells and #size-cells correspond to the reg property.
>>
>> Hmmm.... Looking at [1], the two properties are not exclusive to 'reg'
>> Furthermore, I am not aware of any restriction for us to re-use them. Do
>> you have a pointer?
>
> As we are discussing re-usage of #address-cells and #size-cells for custom properties that are not "reg",
> I took this info from the latest device tree specs found under https://www.devicetree.org/specifications/:
> "The #address-cells property defines the number of <u32> cells used to encode the address field in a child node's reg property"
> and
> "The #size-cells property defines the number of <u32> cells used to encode the size field in a child node’s reg property"
Right. But there is nothing in the wording suggesting that
#address-cells and #size-cells can't be re-used. From [1], it is clear
that the meaning has changed.
So why can't we do the same?
Cheers,
--
Julien Grall
On 07/09/2022 14:45, Julien Grall wrote:
>
> On 07/09/2022 13:41, Michal Orzel wrote:
>>
>>
>> On 07/09/2022 14:32, Julien Grall wrote:
>>> [CAUTION: External Email]
>>>
>>> On 07/09/2022 13:12, Michal Orzel wrote:
>>>> Hi Julien,
>>>
>>> Hi Michal,
>>>
>>>> On 07/09/2022 13:36, Julien Grall wrote:
>>>>>
>>>>> Hi Henry,
>>>>>
>>>>> While reviewing the binding sent by Penny I noticed some inconsistency
>>>>> with the one you introduced. See below.
>>>>>
>>>>> On 07/09/2022 09:36, Henry Wang wrote:
>>>>>> +- xen,static-heap
>>>>>> +
>>>>>> + Property under the top-level "chosen" node. It specifies the address
>>>>>> + and size of Xen static heap memory. Note that at least a 64KB
>>>>>> + alignment is required.
>>>>>> +
>>>>>> +- #xen,static-heap-address-cells and #xen,static-heap-size-cells
>>>>>> +
>>>>>> + Specify the number of cells used for the address and size of the
>>>>>> + "xen,static-heap" property under "chosen".
>>>>>> +
>>>>>> +Below is an example on how to specify the static heap in device tree:
>>>>>> +
>>>>>> + / {
>>>>>> + chosen {
>>>>>> + #xen,static-heap-address-cells = <0x2>;
>>>>>> + #xen,static-heap-size-cells = <0x2>;
>>>>>
>>>>> Your binding, is introduce #xen,static-heap-{address, size}-cells
>>>>> whereas Penny's one is using #{address, size}-cells even if the property
>>>>> is not "reg".
>>>>>
>>>>> I would like some consistency in the way we define bindings. Looking at
>>>>> the tree, we already seem to have introduced
>>>>> #xen-static-mem-address-cells. So maybe we should follow your approach?
>>>>>
>>>>> That said, I am wondering whether we should just use one set of property
>>>>> name.
>>>>>
>>>>> I am open to suggestion here. My only request is we are consistent (i.e.
>>>>> this doesn't depend on who wrote the bindings).
>>>>>
>>>> In my opinion we should follow the device tree specification which states
>>>> that the #address-cells and #size-cells correspond to the reg property.
>>>
>>> Hmmm.... Looking at [1], the two properties are not exclusive to 'reg'
>>> Furthermore, I am not aware of any restriction for us to re-use them. Do
>>> you have a pointer?
>>
>> As we are discussing re-usage of #address-cells and #size-cells for custom properties that are not "reg",
>> I took this info from the latest device tree specs found under https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.devicetree.org%2Fspecifications%2F&data=05%7C01%7Cmichal.orzel%40amd.com%7C4f35e9f93b7443ac73c808da90cecc22%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637981515122993111%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=TiESYS6RXdiPLX8WFUV0CsztAvK7mHSud%2B0xoJqwAw0%3D&reserved=0:
>> "The #address-cells property defines the number of <u32> cells used to encode the address field in a child node's reg property"
>> and
>> "The #size-cells property defines the number of <u32> cells used to encode the size field in a child node’s reg property"
>
> Right. But there is nothing in the wording suggesting that
> #address-cells and #size-cells can't be re-used. From [1], it is clear
> that the meaning has changed.
>
> So why can't we do the same?
I think this is a matter of how someone reads these sentences.
I do not think that such documents need to state:
"This property is for the reg. Do not use it for other purposes."
The first part of the sentence is enough to inform what is supported.
On the other hand, looking at [1] these properties got new purposes
so I think we could do the same. Now the question is whether we want that.
I think it is doable to just have a single pair of #address/#size properties.
For instance xen,shared-mem requiring just 0x1 for address/size
and reg requiring 0x2. This would just imply putting additional 0x00.
>
> Cheers,
>
> --
> Julien Grall
Hi Michal,
> On 7 Sep 2022, at 14:09, Michal Orzel <michal.orzel@amd.com> wrote:
>
>
> On 07/09/2022 14:45, Julien Grall wrote:
>>
>> On 07/09/2022 13:41, Michal Orzel wrote:
>>>
>>>
>>> On 07/09/2022 14:32, Julien Grall wrote:
>>>> [CAUTION: External Email]
>>>>
>>>> On 07/09/2022 13:12, Michal Orzel wrote:
>>>>> Hi Julien,
>>>>
>>>> Hi Michal,
>>>>
>>>>> On 07/09/2022 13:36, Julien Grall wrote:
>>>>>>
>>>>>> Hi Henry,
>>>>>>
>>>>>> While reviewing the binding sent by Penny I noticed some inconsistency
>>>>>> with the one you introduced. See below.
>>>>>>
>>>>>> On 07/09/2022 09:36, Henry Wang wrote:
>>>>>>> +- xen,static-heap
>>>>>>> +
>>>>>>> + Property under the top-level "chosen" node. It specifies the address
>>>>>>> + and size of Xen static heap memory. Note that at least a 64KB
>>>>>>> + alignment is required.
>>>>>>> +
>>>>>>> +- #xen,static-heap-address-cells and #xen,static-heap-size-cells
>>>>>>> +
>>>>>>> + Specify the number of cells used for the address and size of the
>>>>>>> + "xen,static-heap" property under "chosen".
>>>>>>> +
>>>>>>> +Below is an example on how to specify the static heap in device tree:
>>>>>>> +
>>>>>>> + / {
>>>>>>> + chosen {
>>>>>>> + #xen,static-heap-address-cells = <0x2>;
>>>>>>> + #xen,static-heap-size-cells = <0x2>;
>>>>>>
>>>>>> Your binding, is introduce #xen,static-heap-{address, size}-cells
>>>>>> whereas Penny's one is using #{address, size}-cells even if the property
>>>>>> is not "reg".
>>>>>>
>>>>>> I would like some consistency in the way we define bindings. Looking at
>>>>>> the tree, we already seem to have introduced
>>>>>> #xen-static-mem-address-cells. So maybe we should follow your approach?
>>>>>>
>>>>>> That said, I am wondering whether we should just use one set of property
>>>>>> name.
>>>>>>
>>>>>> I am open to suggestion here. My only request is we are consistent (i.e.
>>>>>> this doesn't depend on who wrote the bindings).
>>>>>>
>>>>> In my opinion we should follow the device tree specification which states
>>>>> that the #address-cells and #size-cells correspond to the reg property.
>>>>
>>>> Hmmm.... Looking at [1], the two properties are not exclusive to 'reg'
>>>> Furthermore, I am not aware of any restriction for us to re-use them. Do
>>>> you have a pointer?
>>>
>>> As we are discussing re-usage of #address-cells and #size-cells for custom properties that are not "reg",
>>> I took this info from the latest device tree specs found under https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.devicetree.org%2Fspecifications%2F&data=05%7C01%7Cmichal.orzel%40amd.com%7C4f35e9f93b7443ac73c808da90cecc22%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637981515122993111%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=TiESYS6RXdiPLX8WFUV0CsztAvK7mHSud%2B0xoJqwAw0%3D&reserved=0:
>>> "The #address-cells property defines the number of <u32> cells used to encode the address field in a child node's reg property"
>>> and
>>> "The #size-cells property defines the number of <u32> cells used to encode the size field in a child node’s reg property"
>>
>> Right. But there is nothing in the wording suggesting that
>> #address-cells and #size-cells can't be re-used. From [1], it is clear
>> that the meaning has changed.
>>
>> So why can't we do the same?
> I think this is a matter of how someone reads these sentences.
> I do not think that such documents need to state:
> "This property is for the reg. Do not use it for other purposes."
> The first part of the sentence is enough to inform what is supported.
>
> On the other hand, looking at [1] these properties got new purposes
> so I think we could do the same. Now the question is whether we want that.
> I think it is doable to just have a single pair of #address/#size properties.
> For instance xen,shared-mem requiring just 0x1 for address/size
> and reg requiring 0x2. This would just imply putting additional 0x00.
I think we want in general to reduce complexity when possible.
Here we are adding a lot of entries in the device tree where we know that
in all cases having only 2 will work all the time.
I am not convinced by the arguments on not using #address-cells and will
leave that one to Stefano
But in any case we should only add one pair here for sure, as you say the
only implication is to add a couple of 0 in the worst case.
Cheers
Bertrand
>
>>
>> Cheers,
>>
>> --
>> Julien Grall
On 07/09/2022 15:28, Bertrand Marquis wrote:
>
> Hi Michal,
>
>> On 7 Sep 2022, at 14:09, Michal Orzel <michal.orzel@amd.com> wrote:
>>
>>
>> On 07/09/2022 14:45, Julien Grall wrote:
>>>
>>> On 07/09/2022 13:41, Michal Orzel wrote:
>>>>
>>>>
>>>> On 07/09/2022 14:32, Julien Grall wrote:
>>>>> [CAUTION: External Email]
>>>>>
>>>>> On 07/09/2022 13:12, Michal Orzel wrote:
>>>>>> Hi Julien,
>>>>>
>>>>> Hi Michal,
>>>>>
>>>>>> On 07/09/2022 13:36, Julien Grall wrote:
>>>>>>>
>>>>>>> Hi Henry,
>>>>>>>
>>>>>>> While reviewing the binding sent by Penny I noticed some inconsistency
>>>>>>> with the one you introduced. See below.
>>>>>>>
>>>>>>> On 07/09/2022 09:36, Henry Wang wrote:
>>>>>>>> +- xen,static-heap
>>>>>>>> +
>>>>>>>> + Property under the top-level "chosen" node. It specifies the address
>>>>>>>> + and size of Xen static heap memory. Note that at least a 64KB
>>>>>>>> + alignment is required.
>>>>>>>> +
>>>>>>>> +- #xen,static-heap-address-cells and #xen,static-heap-size-cells
>>>>>>>> +
>>>>>>>> + Specify the number of cells used for the address and size of the
>>>>>>>> + "xen,static-heap" property under "chosen".
>>>>>>>> +
>>>>>>>> +Below is an example on how to specify the static heap in device tree:
>>>>>>>> +
>>>>>>>> + / {
>>>>>>>> + chosen {
>>>>>>>> + #xen,static-heap-address-cells = <0x2>;
>>>>>>>> + #xen,static-heap-size-cells = <0x2>;
>>>>>>>
>>>>>>> Your binding, is introduce #xen,static-heap-{address, size}-cells
>>>>>>> whereas Penny's one is using #{address, size}-cells even if the property
>>>>>>> is not "reg".
>>>>>>>
>>>>>>> I would like some consistency in the way we define bindings. Looking at
>>>>>>> the tree, we already seem to have introduced
>>>>>>> #xen-static-mem-address-cells. So maybe we should follow your approach?
>>>>>>>
>>>>>>> That said, I am wondering whether we should just use one set of property
>>>>>>> name.
>>>>>>>
>>>>>>> I am open to suggestion here. My only request is we are consistent (i.e.
>>>>>>> this doesn't depend on who wrote the bindings).
>>>>>>>
>>>>>> In my opinion we should follow the device tree specification which states
>>>>>> that the #address-cells and #size-cells correspond to the reg property.
>>>>>
>>>>> Hmmm.... Looking at [1], the two properties are not exclusive to 'reg'
>>>>> Furthermore, I am not aware of any restriction for us to re-use them. Do
>>>>> you have a pointer?
>>>>
>>>> As we are discussing re-usage of #address-cells and #size-cells for custom properties that are not "reg",
>>>> I took this info from the latest device tree specs found under https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.devicetree.org%2Fspecifications%2F&data=05%7C01%7Cmichal.orzel%40amd.com%7C83da1eb9d32441cb9e8108da90d4f2d6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637981541539851438%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3M9aT3LjCEOhZUHWSbgSSmKppY1Wion4TT3BeKLnWSo%3D&reserved=0:
>>>> "The #address-cells property defines the number of <u32> cells used to encode the address field in a child node's reg property"
>>>> and
>>>> "The #size-cells property defines the number of <u32> cells used to encode the size field in a child node’s reg property"
>>>
>>> Right. But there is nothing in the wording suggesting that
>>> #address-cells and #size-cells can't be re-used. From [1], it is clear
>>> that the meaning has changed.
>>>
>>> So why can't we do the same?
>> I think this is a matter of how someone reads these sentences.
>> I do not think that such documents need to state:
>> "This property is for the reg. Do not use it for other purposes."
>> The first part of the sentence is enough to inform what is supported.
>>
>> On the other hand, looking at [1] these properties got new purposes
>> so I think we could do the same. Now the question is whether we want that.
>> I think it is doable to just have a single pair of #address/#size properties.
>> For instance xen,shared-mem requiring just 0x1 for address/size
>> and reg requiring 0x2. This would just imply putting additional 0x00.
>
> I think we want in general to reduce complexity when possible.
> Here we are adding a lot of entries in the device tree where we know that
> in all cases having only 2 will work all the time.
>
> I am not convinced by the arguments on not using #address-cells and will
> leave that one to Stefano
>
> But in any case we should only add one pair here for sure, as you say the
> only implication is to add a couple of 0 in the worst case.
I agree. The only drawback is the need to modify the already introduced properties
to be coherent.
>
> Cheers
> Bertrand
>
>>
>>>
>>> Cheers,
>>>
>>> --
>>> Julien Grall
>
Hi Michal, > -----Original Message----- > From: Michal Orzel <michal.orzel@amd.com> > > I am not convinced by the arguments on not using #address-cells and will > > leave that one to Stefano > > > > But in any case we should only add one pair here for sure, as you say the > > only implication is to add a couple of 0 in the worst case. > I agree. The only drawback is the need to modify the already introduced > properties > to be coherent. You mean the #xen,static-mem-address/size-cells? I think this is the only one existing. I can add another prerequisite patch in my series after we reach an agreement. Kind regards, Henry > > > > > Cheers > > Bertrand > > > >> > >>> > >>> Cheers, > >>> > >>> -- > >>> Julien Grall > >
Hi Henry, > On 7 Sep 2022, at 14:35, Henry Wang <Henry.Wang@arm.com> wrote: > > Hi Michal, > >> -----Original Message----- >> From: Michal Orzel <michal.orzel@amd.com> >>> I am not convinced by the arguments on not using #address-cells and will >>> leave that one to Stefano >>> >>> But in any case we should only add one pair here for sure, as you say the >>> only implication is to add a couple of 0 in the worst case. >> I agree. The only drawback is the need to modify the already introduced >> properties >> to be coherent. > > You mean the #xen,static-mem-address/size-cells? I think this is the only one > existing. I can add another prerequisite patch in my series after we reach an > agreement. No the standard device tree ones: #address-cells #size-cells Those have a default value if unspecified. Bertrand > > Kind regards, > Henry > >> >>> >>> Cheers >>> Bertrand >>> >>>> >>>>> >>>>> Cheers, >>>>> >>>>> -- >>>>> Julien Grall >>>
> On 7 Sep 2022, at 14:31, Michal Orzel <michal.orzel@amd.com> wrote:
>
>
>
> On 07/09/2022 15:28, Bertrand Marquis wrote:
>>
>> Hi Michal,
>>
>>> On 7 Sep 2022, at 14:09, Michal Orzel <michal.orzel@amd.com> wrote:
>>>
>>>
>>> On 07/09/2022 14:45, Julien Grall wrote:
>>>>
>>>> On 07/09/2022 13:41, Michal Orzel wrote:
>>>>>
>>>>>
>>>>> On 07/09/2022 14:32, Julien Grall wrote:
>>>>>> [CAUTION: External Email]
>>>>>>
>>>>>> On 07/09/2022 13:12, Michal Orzel wrote:
>>>>>>> Hi Julien,
>>>>>>
>>>>>> Hi Michal,
>>>>>>
>>>>>>> On 07/09/2022 13:36, Julien Grall wrote:
>>>>>>>>
>>>>>>>> Hi Henry,
>>>>>>>>
>>>>>>>> While reviewing the binding sent by Penny I noticed some inconsistency
>>>>>>>> with the one you introduced. See below.
>>>>>>>>
>>>>>>>> On 07/09/2022 09:36, Henry Wang wrote:
>>>>>>>>> +- xen,static-heap
>>>>>>>>> +
>>>>>>>>> + Property under the top-level "chosen" node. It specifies the address
>>>>>>>>> + and size of Xen static heap memory. Note that at least a 64KB
>>>>>>>>> + alignment is required.
>>>>>>>>> +
>>>>>>>>> +- #xen,static-heap-address-cells and #xen,static-heap-size-cells
>>>>>>>>> +
>>>>>>>>> + Specify the number of cells used for the address and size of the
>>>>>>>>> + "xen,static-heap" property under "chosen".
>>>>>>>>> +
>>>>>>>>> +Below is an example on how to specify the static heap in device tree:
>>>>>>>>> +
>>>>>>>>> + / {
>>>>>>>>> + chosen {
>>>>>>>>> + #xen,static-heap-address-cells = <0x2>;
>>>>>>>>> + #xen,static-heap-size-cells = <0x2>;
>>>>>>>>
>>>>>>>> Your binding, is introduce #xen,static-heap-{address, size}-cells
>>>>>>>> whereas Penny's one is using #{address, size}-cells even if the property
>>>>>>>> is not "reg".
>>>>>>>>
>>>>>>>> I would like some consistency in the way we define bindings. Looking at
>>>>>>>> the tree, we already seem to have introduced
>>>>>>>> #xen-static-mem-address-cells. So maybe we should follow your approach?
>>>>>>>>
>>>>>>>> That said, I am wondering whether we should just use one set of property
>>>>>>>> name.
>>>>>>>>
>>>>>>>> I am open to suggestion here. My only request is we are consistent (i.e.
>>>>>>>> this doesn't depend on who wrote the bindings).
>>>>>>>>
>>>>>>> In my opinion we should follow the device tree specification which states
>>>>>>> that the #address-cells and #size-cells correspond to the reg property.
>>>>>>
>>>>>> Hmmm.... Looking at [1], the two properties are not exclusive to 'reg'
>>>>>> Furthermore, I am not aware of any restriction for us to re-use them. Do
>>>>>> you have a pointer?
>>>>>
>>>>> As we are discussing re-usage of #address-cells and #size-cells for custom properties that are not "reg",
>>>>> I took this info from the latest device tree specs found under https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.devicetree.org%2Fspecifications%2F&data=05%7C01%7Cmichal.orzel%40amd.com%7C83da1eb9d32441cb9e8108da90d4f2d6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637981541539851438%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3M9aT3LjCEOhZUHWSbgSSmKppY1Wion4TT3BeKLnWSo%3D&reserved=0:
>>>>> "The #address-cells property defines the number of <u32> cells used to encode the address field in a child node's reg property"
>>>>> and
>>>>> "The #size-cells property defines the number of <u32> cells used to encode the size field in a child node’s reg property"
>>>>
>>>> Right. But there is nothing in the wording suggesting that
>>>> #address-cells and #size-cells can't be re-used. From [1], it is clear
>>>> that the meaning has changed.
>>>>
>>>> So why can't we do the same?
>>> I think this is a matter of how someone reads these sentences.
>>> I do not think that such documents need to state:
>>> "This property is for the reg. Do not use it for other purposes."
>>> The first part of the sentence is enough to inform what is supported.
>>>
>>> On the other hand, looking at [1] these properties got new purposes
>>> so I think we could do the same. Now the question is whether we want that.
>>> I think it is doable to just have a single pair of #address/#size properties.
>>> For instance xen,shared-mem requiring just 0x1 for address/size
>>> and reg requiring 0x2. This would just imply putting additional 0x00.
>>
>> I think we want in general to reduce complexity when possible.
>> Here we are adding a lot of entries in the device tree where we know that
>> in all cases having only 2 will work all the time.
>>
>> I am not convinced by the arguments on not using #address-cells and will
>> leave that one to Stefano
>>
>> But in any case we should only add one pair here for sure, as you say the
>> only implication is to add a couple of 0 in the worst case.
> I agree. The only drawback is the need to modify the already introduced properties
> to be coherent.
Agree, someone will need to do a pass on the whole doc which might be easier with all things in.
Cheers
Bertrand
>
>>
>> Cheers
>> Bertrand
>>
>>>
>>>>
>>>> Cheers,
>>>>
>>>> --
>>>> Julien Grall
On 07/09/2022 15:33, Bertrand Marquis wrote:
>
>> On 7 Sep 2022, at 14:31, Michal Orzel <michal.orzel@amd.com> wrote:
>>
>>
>>
>> On 07/09/2022 15:28, Bertrand Marquis wrote:
>>>
>>> Hi Michal,
>>>
>>>> On 7 Sep 2022, at 14:09, Michal Orzel <michal.orzel@amd.com> wrote:
>>>>
>>>>
>>>> On 07/09/2022 14:45, Julien Grall wrote:
>>>>>
>>>>> On 07/09/2022 13:41, Michal Orzel wrote:
>>>>>>
>>>>>>
>>>>>> On 07/09/2022 14:32, Julien Grall wrote:
>>>>>>> [CAUTION: External Email]
>>>>>>>
>>>>>>> On 07/09/2022 13:12, Michal Orzel wrote:
>>>>>>>> Hi Julien,
>>>>>>>
>>>>>>> Hi Michal,
>>>>>>>
>>>>>>>> On 07/09/2022 13:36, Julien Grall wrote:
>>>>>>>>>
>>>>>>>>> Hi Henry,
>>>>>>>>>
>>>>>>>>> While reviewing the binding sent by Penny I noticed some inconsistency
>>>>>>>>> with the one you introduced. See below.
>>>>>>>>>
>>>>>>>>> On 07/09/2022 09:36, Henry Wang wrote:
>>>>>>>>>> +- xen,static-heap
>>>>>>>>>> +
>>>>>>>>>> + Property under the top-level "chosen" node. It specifies the address
>>>>>>>>>> + and size of Xen static heap memory. Note that at least a 64KB
>>>>>>>>>> + alignment is required.
>>>>>>>>>> +
>>>>>>>>>> +- #xen,static-heap-address-cells and #xen,static-heap-size-cells
>>>>>>>>>> +
>>>>>>>>>> + Specify the number of cells used for the address and size of the
>>>>>>>>>> + "xen,static-heap" property under "chosen".
>>>>>>>>>> +
>>>>>>>>>> +Below is an example on how to specify the static heap in device tree:
>>>>>>>>>> +
>>>>>>>>>> + / {
>>>>>>>>>> + chosen {
>>>>>>>>>> + #xen,static-heap-address-cells = <0x2>;
>>>>>>>>>> + #xen,static-heap-size-cells = <0x2>;
>>>>>>>>>
>>>>>>>>> Your binding, is introduce #xen,static-heap-{address, size}-cells
>>>>>>>>> whereas Penny's one is using #{address, size}-cells even if the property
>>>>>>>>> is not "reg".
>>>>>>>>>
>>>>>>>>> I would like some consistency in the way we define bindings. Looking at
>>>>>>>>> the tree, we already seem to have introduced
>>>>>>>>> #xen-static-mem-address-cells. So maybe we should follow your approach?
>>>>>>>>>
>>>>>>>>> That said, I am wondering whether we should just use one set of property
>>>>>>>>> name.
>>>>>>>>>
>>>>>>>>> I am open to suggestion here. My only request is we are consistent (i.e.
>>>>>>>>> this doesn't depend on who wrote the bindings).
>>>>>>>>>
>>>>>>>> In my opinion we should follow the device tree specification which states
>>>>>>>> that the #address-cells and #size-cells correspond to the reg property.
>>>>>>>
>>>>>>> Hmmm.... Looking at [1], the two properties are not exclusive to 'reg'
>>>>>>> Furthermore, I am not aware of any restriction for us to re-use them. Do
>>>>>>> you have a pointer?
>>>>>>
>>>>>> As we are discussing re-usage of #address-cells and #size-cells for custom properties that are not "reg",
>>>>>> I took this info from the latest device tree specs found under https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.devicetree.org%2Fspecifications%2F&data=05%7C01%7Cmichal.orzel%40amd.com%7Cc677a7983cd94e48620708da90d5a15f%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637981544487489692%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1uwtf%2F6shf2PiKu0XZPFNQ%2B6iyhLrMsYb1XEru3IGlg%3D&reserved=0:
>>>>>> "The #address-cells property defines the number of <u32> cells used to encode the address field in a child node's reg property"
>>>>>> and
>>>>>> "The #size-cells property defines the number of <u32> cells used to encode the size field in a child node’s reg property"
>>>>>
>>>>> Right. But there is nothing in the wording suggesting that
>>>>> #address-cells and #size-cells can't be re-used. From [1], it is clear
>>>>> that the meaning has changed.
>>>>>
>>>>> So why can't we do the same?
>>>> I think this is a matter of how someone reads these sentences.
>>>> I do not think that such documents need to state:
>>>> "This property is for the reg. Do not use it for other purposes."
>>>> The first part of the sentence is enough to inform what is supported.
>>>>
>>>> On the other hand, looking at [1] these properties got new purposes
>>>> so I think we could do the same. Now the question is whether we want that.
>>>> I think it is doable to just have a single pair of #address/#size properties.
>>>> For instance xen,shared-mem requiring just 0x1 for address/size
>>>> and reg requiring 0x2. This would just imply putting additional 0x00.
>>>
>>> I think we want in general to reduce complexity when possible.
>>> Here we are adding a lot of entries in the device tree where we know that
>>> in all cases having only 2 will work all the time.
>>>
>>> I am not convinced by the arguments on not using #address-cells and will
>>> leave that one to Stefano
>>>
>>> But in any case we should only add one pair here for sure, as you say the
>>> only implication is to add a couple of 0 in the worst case.
>> I agree. The only drawback is the need to modify the already introduced properties
>> to be coherent.
>
> Agree, someone will need to do a pass on the whole doc which might be easier with all things in.
>
Well, not only docs. If we decide to use a single pair of #address-cells and #size-cells, then
we need to modify the code that expects different properties e.g. xen,static-mem-{address/size}-cells.
> Cheers
> Bertrand
>
>>
>>>
>>> Cheers
>>> Bertrand
>>>
>>>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>> --
>>>>> Julien Grall
>
Hi,
> On 7 Sep 2022, at 14:37, Michal Orzel <michal.orzel@amd.com> wrote:
>
>
>
> On 07/09/2022 15:33, Bertrand Marquis wrote:
>>
>>> On 7 Sep 2022, at 14:31, Michal Orzel <michal.orzel@amd.com> wrote:
>>>
>>>
>>>
>>> On 07/09/2022 15:28, Bertrand Marquis wrote:
>>>>
>>>> Hi Michal,
>>>>
>>>>> On 7 Sep 2022, at 14:09, Michal Orzel <michal.orzel@amd.com> wrote:
>>>>>
>>>>>
>>>>> On 07/09/2022 14:45, Julien Grall wrote:
>>>>>>
>>>>>> On 07/09/2022 13:41, Michal Orzel wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 07/09/2022 14:32, Julien Grall wrote:
>>>>>>>> [CAUTION: External Email]
>>>>>>>>
>>>>>>>> On 07/09/2022 13:12, Michal Orzel wrote:
>>>>>>>>> Hi Julien,
>>>>>>>>
>>>>>>>> Hi Michal,
>>>>>>>>
>>>>>>>>> On 07/09/2022 13:36, Julien Grall wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Henry,
>>>>>>>>>>
>>>>>>>>>> While reviewing the binding sent by Penny I noticed some inconsistency
>>>>>>>>>> with the one you introduced. See below.
>>>>>>>>>>
>>>>>>>>>> On 07/09/2022 09:36, Henry Wang wrote:
>>>>>>>>>>> +- xen,static-heap
>>>>>>>>>>> +
>>>>>>>>>>> + Property under the top-level "chosen" node. It specifies the address
>>>>>>>>>>> + and size of Xen static heap memory. Note that at least a 64KB
>>>>>>>>>>> + alignment is required.
>>>>>>>>>>> +
>>>>>>>>>>> +- #xen,static-heap-address-cells and #xen,static-heap-size-cells
>>>>>>>>>>> +
>>>>>>>>>>> + Specify the number of cells used for the address and size of the
>>>>>>>>>>> + "xen,static-heap" property under "chosen".
>>>>>>>>>>> +
>>>>>>>>>>> +Below is an example on how to specify the static heap in device tree:
>>>>>>>>>>> +
>>>>>>>>>>> + / {
>>>>>>>>>>> + chosen {
>>>>>>>>>>> + #xen,static-heap-address-cells = <0x2>;
>>>>>>>>>>> + #xen,static-heap-size-cells = <0x2>;
>>>>>>>>>>
>>>>>>>>>> Your binding, is introduce #xen,static-heap-{address, size}-cells
>>>>>>>>>> whereas Penny's one is using #{address, size}-cells even if the property
>>>>>>>>>> is not "reg".
>>>>>>>>>>
>>>>>>>>>> I would like some consistency in the way we define bindings. Looking at
>>>>>>>>>> the tree, we already seem to have introduced
>>>>>>>>>> #xen-static-mem-address-cells. So maybe we should follow your approach?
>>>>>>>>>>
>>>>>>>>>> That said, I am wondering whether we should just use one set of property
>>>>>>>>>> name.
>>>>>>>>>>
>>>>>>>>>> I am open to suggestion here. My only request is we are consistent (i.e.
>>>>>>>>>> this doesn't depend on who wrote the bindings).
>>>>>>>>>>
>>>>>>>>> In my opinion we should follow the device tree specification which states
>>>>>>>>> that the #address-cells and #size-cells correspond to the reg property.
>>>>>>>>
>>>>>>>> Hmmm.... Looking at [1], the two properties are not exclusive to 'reg'
>>>>>>>> Furthermore, I am not aware of any restriction for us to re-use them. Do
>>>>>>>> you have a pointer?
>>>>>>>
>>>>>>> As we are discussing re-usage of #address-cells and #size-cells for custom properties that are not "reg",
>>>>>>> I took this info from the latest device tree specs found under https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.devicetree.org%2Fspecifications%2F&data=05%7C01%7Cmichal.orzel%40amd.com%7Cc677a7983cd94e48620708da90d5a15f%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637981544487489692%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1uwtf%2F6shf2PiKu0XZPFNQ%2B6iyhLrMsYb1XEru3IGlg%3D&reserved=0:
>>>>>>> "The #address-cells property defines the number of <u32> cells used to encode the address field in a child node's reg property"
>>>>>>> and
>>>>>>> "The #size-cells property defines the number of <u32> cells used to encode the size field in a child node’s reg property"
>>>>>>
>>>>>> Right. But there is nothing in the wording suggesting that
>>>>>> #address-cells and #size-cells can't be re-used. From [1], it is clear
>>>>>> that the meaning has changed.
>>>>>>
>>>>>> So why can't we do the same?
>>>>> I think this is a matter of how someone reads these sentences.
>>>>> I do not think that such documents need to state:
>>>>> "This property is for the reg. Do not use it for other purposes."
>>>>> The first part of the sentence is enough to inform what is supported.
>>>>>
>>>>> On the other hand, looking at [1] these properties got new purposes
>>>>> so I think we could do the same. Now the question is whether we want that.
>>>>> I think it is doable to just have a single pair of #address/#size properties.
>>>>> For instance xen,shared-mem requiring just 0x1 for address/size
>>>>> and reg requiring 0x2. This would just imply putting additional 0x00.
>>>>
>>>> I think we want in general to reduce complexity when possible.
>>>> Here we are adding a lot of entries in the device tree where we know that
>>>> in all cases having only 2 will work all the time.
>>>>
>>>> I am not convinced by the arguments on not using #address-cells and will
>>>> leave that one to Stefano
>>>>
>>>> But in any case we should only add one pair here for sure, as you say the
>>>> only implication is to add a couple of 0 in the worst case.
>>> I agree. The only drawback is the need to modify the already introduced properties
>>> to be coherent.
>>
>> Agree, someone will need to do a pass on the whole doc which might be easier with all things in.
>>
> Well, not only docs. If we decide to use a single pair of #address-cells and #size-cells, then
> we need to modify the code that expects different properties e.g. xen,static-mem-{address/size}-cells.
Right I forgot that some parts are already in.
So we will need an extra patch to handle those.
Bertrand
>
>> Cheers
>> Bertrand
>>
>>>
>>>>
>>>> Cheers
>>>> Bertrand
>>>>
>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> --
>>>>>> Julien Grall
Hi Bertrand and Michal,
I don't want to spam the email so I just reply here...
> -----Original Message-----
> From: Bertrand Marquis <Bertrand.Marquis@arm.com>
> >>>> But in any case we should only add one pair here for sure, as you say
> the
> >>>> only implication is to add a couple of 0 in the worst case.
> >>> I agree. The only drawback is the need to modify the already introduced
> properties
> >>> to be coherent.
> >>
> >> Agree, someone will need to do a pass on the whole doc which might be
> easier with all things in.
> >>
> > Well, not only docs. If we decide to use a single pair of #address-cells and
> #size-cells, then
> > we need to modify the code that expects different properties e.g.
> xen,static-mem-{address/size}-cells.
>
> Right I forgot that some parts are already in.
> So we will need an extra patch to handle those.
I think I've addressed all comments from Julien regarding my series,
so I think I've got some bandwidth to do the clean-up patch tomorrow
after the agreement, unless someone would like to do it himself?
Kind regards,
Henry
>
> Bertrand
>
> >
> >> Cheers
> >> Bertrand
> >>
> >>>
> >>>>
> >>>> Cheers
> >>>> Bertrand
> >>>>
> >>>>>
> >>>>>>
> >>>>>> Cheers,
> >>>>>>
> >>>>>> --
> >>>>>> Julien Grall
>
Hi Henry,
On 07/09/2022 14:49, Henry Wang wrote:
>> -----Original Message-----
>> From: Bertrand Marquis <Bertrand.Marquis@arm.com>
>>>>>> But in any case we should only add one pair here for sure, as you say
>> the
>>>>>> only implication is to add a couple of 0 in the worst case.
>>>>> I agree. The only drawback is the need to modify the already introduced
>> properties
>>>>> to be coherent.
>>>>
>>>> Agree, someone will need to do a pass on the whole doc which might be
>> easier with all things in.
>>>>
>>> Well, not only docs. If we decide to use a single pair of #address-cells and
>> #size-cells, then
>>> we need to modify the code that expects different properties e.g.
>> xen,static-mem-{address/size}-cells.
>>
>> Right I forgot that some parts are already in.
>> So we will need an extra patch to handle those.
>
> I think I've addressed all comments from Julien regarding my series,
If it is not too late for you would you be able to resend your series
without the 'address-cells'/'size-cells' change? This will give me the
opportunity to have an other review today.
> so I think I've got some bandwidth to do the clean-up patch tomorrow
> after the agreement, unless someone would like to do it himself?
Renaming "xen,static-mem-..." is a bit tricky because they have been
defined in Xen 4.16.
I couldn't find any support statement specific to the static memory
feature. So it would technically fall under the "dom0less" section which
is security supported.
That said, I don't think we can consider that the static memory feature
is even supported because, until yesterday, the code wasn't properly
handling request to balloon in/out. So I would view this is a tech
preview (Could someone send a patch to clarify SUPPORT.MD)?
This would mean that would be that we could consider the binding
unstable and we could do a straight renaming. That said, I can
understand this may be undesirable.
If that's the case then we would need to keep the current binding as-is.
So we would have two options:
1) Provide a new compatible so #address-cells #size-cells can be
used. The current binding can be deprecated
2) Leave as-is and accept the difference
I don't have a strong opinion on which way to go. Whichever, it would be
good to write down the rationale in the commit message of the "future"
patch.
I would not block this series on the renaming for existing property
(what matter is the new ones are consistent with the discussion). The
renaming could be done afterwards. I would even say post the feature
freeze on Friday because this could be considered as a bug fix (assuming
you agree as the release manager :)).
Cheers,
--
Julien Grall
On Wed, 7 Sep 2022, Julien Grall wrote:
> On 07/09/2022 14:49, Henry Wang wrote:
> > > -----Original Message-----
> > > From: Bertrand Marquis <Bertrand.Marquis@arm.com>
> > > > > > > But in any case we should only add one pair here for sure, as you
> > > > > > > say
> > > the
> > > > > > > only implication is to add a couple of 0 in the worst case.
> > > > > > I agree. The only drawback is the need to modify the already
> > > > > > introduced
> > > properties
> > > > > > to be coherent.
> > > > >
> > > > > Agree, someone will need to do a pass on the whole doc which might be
> > > easier with all things in.
> > > > >
> > > > Well, not only docs. If we decide to use a single pair of #address-cells
> > > > and
> > > #size-cells, then
> > > > we need to modify the code that expects different properties e.g.
> > > xen,static-mem-{address/size}-cells.
> > >
> > > Right I forgot that some parts are already in.
> > > So we will need an extra patch to handle those.
> >
> > I think I've addressed all comments from Julien regarding my series,
>
> If it is not too late for you would you be able to resend your series without
> the 'address-cells'/'size-cells' change? This will give me the opportunity to
> have an other review today.
>
> > so I think I've got some bandwidth to do the clean-up patch tomorrow
> > after the agreement, unless someone would like to do it himself?
>
> Renaming "xen,static-mem-..." is a bit tricky because they have been defined
> in Xen 4.16.
>
> I couldn't find any support statement specific to the static memory feature.
> So it would technically fall under the "dom0less" section which is security
> supported.
>
> That said, I don't think we can consider that the static memory feature is
> even supported because, until yesterday, the code wasn't properly handling
> request to balloon in/out. So I would view this is a tech preview (Could
> someone send a patch to clarify SUPPORT.MD)?
>
> This would mean that would be that we could consider the binding unstable and
> we could do a straight renaming. That said, I can understand this may be
> undesirable.
>
> If that's the case then we would need to keep the current binding as-is. So we
> would have two options:
> 1) Provide a new compatible so #address-cells #size-cells can be used. The
> current binding can be deprecated
> 2) Leave as-is and accept the difference
>
> I don't have a strong opinion on which way to go. Whichever, it would be good
> to write down the rationale in the commit message of the "future" patch.
>
> I would not block this series on the renaming for existing property (what
> matter is the new ones are consistent with the discussion). The renaming could
> be done afterwards. I would even say post the feature freeze on Friday because
> this could be considered as a bug fix (assuming you agree as the release
> manager :)).
I very much agree that we should be consistent. Consistency aside, I
would prefer *not* to introduce #xen,static-heap-address-cells and
#xen,static-heap-size-cells and instead reuse the regular #address-cells
and #size-cells. I think there is no reason why we shouldn't.
I was about to write something about it a couple of days ago but then I
noticed that we had already introduced #xen,static-mem-address-cells and
#xen,static-mem-size-cells. In order to be consistent I didn't say
anything and gave my ack.
But actually I think it is better to get rid of them all. I think we
should:
1) do not introduce #xen,static-heap-address-cells and
#xen,static-heap-size-cells in this series, instead rely on
#address-cells and #size-cells. Please write in the binding that the
number of address cells and size cells of xen,static-heap is determined
by the parent #address-cells and #size-cells. (It has to be the parent
because that is how #address-cells and #size-cells are defined.)
2) Also remove "#xen,static-mem-address-cells" and
"#xen,static-mem-size-cells", and also use #address-cells and
#size-cells for xen,static-mem as well. I think we should do that in
this release for consistency. Any volunteers? :-)
It is not going to break anything because, not only static-mem is tech
preview, but also it is very likely that if someone was using
#xen,static-heap-address-cells it would be setting it to the same value
as #address-cells. So in the vast majority of cases it would continue to
work as expected (not that we couldn't change it anyway, given that it
is a tech preview.)
So I am aligned with Julien on this.
Hi Stefano, > -----Original Message----- > From: Stefano Stabellini <sstabellini@kernel.org> > > I would not block this series on the renaming for existing property (what > > matter is the new ones are consistent with the discussion). The renaming > could > > be done afterwards. I would even say post the feature freeze on Friday > because > > this could be considered as a bug fix (assuming you agree as the release > > manager :)). > > I very much agree that we should be consistent. Consistency aside, I > would prefer *not* to introduce #xen,static-heap-address-cells and > #xen,static-heap-size-cells and instead reuse the regular #address-cells > and #size-cells. I think there is no reason why we shouldn't. > > I was about to write something about it a couple of days ago but then I > noticed that we had already introduced #xen,static-mem-address-cells and > #xen,static-mem-size-cells. In order to be consistent I didn't say > anything and gave my ack. > > But actually I think it is better to get rid of them all. I think we > should: > > 1) do not introduce #xen,static-heap-address-cells and > #xen,static-heap-size-cells in this series, instead rely on > #address-cells and #size-cells. Please write in the binding that the > number of address cells and size cells of xen,static-heap is determined > by the parent #address-cells and #size-cells. (It has to be the parent > because that is how #address-cells and #size-cells are defined.) Ack, I will do in v5, also drop your previous ack so you can take a look again. > > 2) Also remove "#xen,static-mem-address-cells" and > "#xen,static-mem-size-cells", and also use #address-cells and > #size-cells for xen,static-mem as well. I think we should do that in > this release for consistency. Any volunteers? :-) I will add a new patch in the end of this series for static-mem cleanup. This can be merged later as a bug fix according to the discussion with Julien. Kind regards, Henry > > It is not going to break anything because, not only static-mem is tech > preview, but also it is very likely that if someone was using > #xen,static-heap-address-cells it would be setting it to the same value > as #address-cells. So in the vast majority of cases it would continue to > work as expected (not that we couldn't change it anyway, given that it > is a tech preview.) > > So I am aligned with Julien on this.
On Wed, 7 Sep 2022, Stefano Stabellini wrote:
> On Wed, 7 Sep 2022, Julien Grall wrote:
> > On 07/09/2022 14:49, Henry Wang wrote:
> > > > -----Original Message-----
> > > > From: Bertrand Marquis <Bertrand.Marquis@arm.com>
> > > > > > > > But in any case we should only add one pair here for sure, as you
> > > > > > > > say
> > > > the
> > > > > > > > only implication is to add a couple of 0 in the worst case.
> > > > > > > I agree. The only drawback is the need to modify the already
> > > > > > > introduced
> > > > properties
> > > > > > > to be coherent.
> > > > > >
> > > > > > Agree, someone will need to do a pass on the whole doc which might be
> > > > easier with all things in.
> > > > > >
> > > > > Well, not only docs. If we decide to use a single pair of #address-cells
> > > > > and
> > > > #size-cells, then
> > > > > we need to modify the code that expects different properties e.g.
> > > > xen,static-mem-{address/size}-cells.
> > > >
> > > > Right I forgot that some parts are already in.
> > > > So we will need an extra patch to handle those.
> > >
> > > I think I've addressed all comments from Julien regarding my series,
> >
> > If it is not too late for you would you be able to resend your series without
> > the 'address-cells'/'size-cells' change? This will give me the opportunity to
> > have an other review today.
> >
> > > so I think I've got some bandwidth to do the clean-up patch tomorrow
> > > after the agreement, unless someone would like to do it himself?
> >
> > Renaming "xen,static-mem-..." is a bit tricky because they have been defined
> > in Xen 4.16.
> >
> > I couldn't find any support statement specific to the static memory feature.
> > So it would technically fall under the "dom0less" section which is security
> > supported.
> >
> > That said, I don't think we can consider that the static memory feature is
> > even supported because, until yesterday, the code wasn't properly handling
> > request to balloon in/out. So I would view this is a tech preview (Could
> > someone send a patch to clarify SUPPORT.MD)?
> >
> > This would mean that would be that we could consider the binding unstable and
> > we could do a straight renaming. That said, I can understand this may be
> > undesirable.
> >
> > If that's the case then we would need to keep the current binding as-is. So we
> > would have two options:
> > 1) Provide a new compatible so #address-cells #size-cells can be used. The
> > current binding can be deprecated
> > 2) Leave as-is and accept the difference
> >
> > I don't have a strong opinion on which way to go. Whichever, it would be good
> > to write down the rationale in the commit message of the "future" patch.
> >
> > I would not block this series on the renaming for existing property (what
> > matter is the new ones are consistent with the discussion). The renaming could
> > be done afterwards. I would even say post the feature freeze on Friday because
> > this could be considered as a bug fix (assuming you agree as the release
> > manager :)).
>
> I very much agree that we should be consistent. Consistency aside, I
> would prefer *not* to introduce #xen,static-heap-address-cells and
> #xen,static-heap-size-cells and instead reuse the regular #address-cells
> and #size-cells. I think there is no reason why we shouldn't.
>
> I was about to write something about it a couple of days ago but then I
> noticed that we had already introduced #xen,static-mem-address-cells and
> #xen,static-mem-size-cells. In order to be consistent I didn't say
> anything and gave my ack.
>
> But actually I think it is better to get rid of them all. I think we
> should:
>
> 1) do not introduce #xen,static-heap-address-cells and
> #xen,static-heap-size-cells in this series, instead rely on
> #address-cells and #size-cells. Please write in the binding that the
> number of address cells and size cells of xen,static-heap is determined
> by the parent #address-cells and #size-cells. (It has to be the parent
> because that is how #address-cells and #size-cells are defined.)
>
> 2) Also remove "#xen,static-mem-address-cells" and
> "#xen,static-mem-size-cells", and also use #address-cells and
> #size-cells for xen,static-mem as well. I think we should do that in
> this release for consistency. Any volunteers? :-)
I should also add that I don't think we should change the compatible
string for xen,static-mem. If the feature is tech preview, maybe we
can consider the device tree bindings tech preview as well? I think that
would be OK.
If you don't think is OK, then I suggest to:
- first check "#xen,static-mem-address-cells" and
"#xen,static-mem-size-cells" for compatibility
- if missing, use the regular #address-cells and #size-cells
This way we retain compatibility. Either way, I wouldn't change the
compatible string for xen,static-mem.
Hi Julien, > -----Original Message----- > From: Julien Grall <julien@xen.org> > > I think I've addressed all comments from Julien regarding my series, > > If it is not too late for you would you be able to resend your series > without the 'address-cells'/'size-cells' change? This will give me the > opportunity to have an other review today. I will be off after resending this so you can have another look today. > > > so I think I've got some bandwidth to do the clean-up patch tomorrow > > after the agreement, unless someone would like to do it himself? > > Renaming "xen,static-mem-..." is a bit tricky because they have been > defined in Xen 4.16. > > I couldn't find any support statement specific to the static memory > feature. So it would technically fall under the "dom0less" section which > is security supported. > > That said, I don't think we can consider that the static memory feature > is even supported because, until yesterday, the code wasn't properly > handling request to balloon in/out. So I would view this is a tech > preview (Could someone send a patch to clarify SUPPORT.MD)? In current code, the static allocation is in SUPPORT.md as tech preview. > > This would mean that would be that we could consider the binding > unstable and we could do a straight renaming. That said, I can > understand this may be undesirable. > > If that's the case then we would need to keep the current binding as-is. > So we would have two options: > 1) Provide a new compatible so #address-cells #size-cells can be > used. The current binding can be deprecated > 2) Leave as-is and accept the difference > > I don't have a strong opinion on which way to go. Whichever, it would be > good to write down the rationale in the commit message of the "future" > patch. > > I would not block this series on the renaming for existing property > (what matter is the new ones are consistent with the discussion). The > renaming could be done afterwards. I would even say post the feature > freeze on Friday because this could be considered as a bug fix (assuming > you agree as the release manager :)). Actually this is the one I want to discuss with you, I am good with considering this clean-up patch as a bug fix. Kind regards, Henry > > Cheers, > > -- > Julien Grall
On 07/09/2022 15:04, Julien Grall wrote:
> Hi Henry,
>
> On 07/09/2022 14:49, Henry Wang wrote:
>>> -----Original Message-----
>>> From: Bertrand Marquis <Bertrand.Marquis@arm.com>
>>>>>>> But in any case we should only add one pair here for sure, as you
>>>>>>> say
>>> the
>>>>>>> only implication is to add a couple of 0 in the worst case.
>>>>>> I agree. The only drawback is the need to modify the already
>>>>>> introduced
>>> properties
>>>>>> to be coherent.
>>>>>
>>>>> Agree, someone will need to do a pass on the whole doc which might be
>>> easier with all things in.
>>>>>
>>>> Well, not only docs. If we decide to use a single pair of
>>>> #address-cells and
>>> #size-cells, then
>>>> we need to modify the code that expects different properties e.g.
>>> xen,static-mem-{address/size}-cells.
>>>
>>> Right I forgot that some parts are already in.
>>> So we will need an extra patch to handle those.
>>
>> I think I've addressed all comments from Julien regarding my series,
>
> If it is not too late for you would you be able to resend your series
> without the 'address-cells'/'size-cells' change? This will give me the
> opportunity to have an other review today.
>
>> so I think I've got some bandwidth to do the clean-up patch tomorrow
>> after the agreement, unless someone would like to do it himself?
>
> Renaming "xen,static-mem-..." is a bit tricky because they have been
> defined in Xen 4.16.
>
> I couldn't find any support statement specific to the static memory
> feature. So it would technically fall under the "dom0less" section which
> is security supported.
>
> That said, I don't think we can consider that the static memory feature
> is even supported because, until yesterday, the code wasn't properly
> handling request to balloon in/out. So I would view this is a tech
> preview (Could someone send a patch to clarify SUPPORT.MD)?
Ah. I was using the 4.16 branch. There is a patch for 4.17 to confirm
this is tech preview. I think we should consider to backport it.
Stefano can you add it in your backport list?
Cheers,
--
Julien Grall
Hi Henry,
> On 7 Sep 2022, at 14:49, Henry Wang <Henry.Wang@arm.com> wrote:
>
> Hi Bertrand and Michal,
>
> I don't want to spam the email so I just reply here...
>
>> -----Original Message-----
>> From: Bertrand Marquis <Bertrand.Marquis@arm.com>
>>>>>> But in any case we should only add one pair here for sure, as you say
>> the
>>>>>> only implication is to add a couple of 0 in the worst case.
>>>>> I agree. The only drawback is the need to modify the already introduced
>> properties
>>>>> to be coherent.
>>>>
>>>> Agree, someone will need to do a pass on the whole doc which might be
>> easier with all things in.
>>>>
>>> Well, not only docs. If we decide to use a single pair of #address-cells and
>> #size-cells, then
>>> we need to modify the code that expects different properties e.g.
>> xen,static-mem-{address/size}-cells.
>>
>> Right I forgot that some parts are already in.
>> So we will need an extra patch to handle those.
>
> I think I've addressed all comments from Julien regarding my series,
> so I think I've got some bandwidth to do the clean-up patch tomorrow
> after the agreement, unless someone would like to do it himself?
This is very nice of you.
We need to confirm first if something is actually needed or not so we need Stefano’s view here.
If so then please do it :-)
Cheers
Bertrand
>
> Kind regards,
> Henry
>
>>
>> Bertrand
>>
>>>
>>>> Cheers
>>>> Bertrand
>>>>
>>>>>
>>>>>>
>>>>>> Cheers
>>>>>> Bertrand
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> --
>>>>>>>> Julien Grall
Hi,
> On 7 Sep 2022, at 13:45, Julien Grall <julien@xen.org> wrote:
>
>
>
> On 07/09/2022 13:41, Michal Orzel wrote:
>> On 07/09/2022 14:32, Julien Grall wrote:
>>> [CAUTION: External Email]
>>>
>>> On 07/09/2022 13:12, Michal Orzel wrote:
>>>> Hi Julien,
>>>
>>> Hi Michal,
>>>
>>>> On 07/09/2022 13:36, Julien Grall wrote:
>>>>>
>>>>> Hi Henry,
>>>>>
>>>>> While reviewing the binding sent by Penny I noticed some inconsistency
>>>>> with the one you introduced. See below.
>>>>>
>>>>> On 07/09/2022 09:36, Henry Wang wrote:
>>>>>> +- xen,static-heap
>>>>>> +
>>>>>> + Property under the top-level "chosen" node. It specifies the address
>>>>>> + and size of Xen static heap memory. Note that at least a 64KB
>>>>>> + alignment is required.
>>>>>> +
>>>>>> +- #xen,static-heap-address-cells and #xen,static-heap-size-cells
>>>>>> +
>>>>>> + Specify the number of cells used for the address and size of the
>>>>>> + "xen,static-heap" property under "chosen".
>>>>>> +
>>>>>> +Below is an example on how to specify the static heap in device tree:
>>>>>> +
>>>>>> + / {
>>>>>> + chosen {
>>>>>> + #xen,static-heap-address-cells = <0x2>;
>>>>>> + #xen,static-heap-size-cells = <0x2>;
>>>>>
>>>>> Your binding, is introduce #xen,static-heap-{address, size}-cells
>>>>> whereas Penny's one is using #{address, size}-cells even if the property
>>>>> is not "reg".
>>>>>
>>>>> I would like some consistency in the way we define bindings. Looking at
>>>>> the tree, we already seem to have introduced
>>>>> #xen-static-mem-address-cells. So maybe we should follow your approach?
>>>>>
>>>>> That said, I am wondering whether we should just use one set of property
>>>>> name.
>>>>>
>>>>> I am open to suggestion here. My only request is we are consistent (i.e.
>>>>> this doesn't depend on who wrote the bindings).
>>>>>
>>>> In my opinion we should follow the device tree specification which states
>>>> that the #address-cells and #size-cells correspond to the reg property.
>>>
>>> Hmmm.... Looking at [1], the two properties are not exclusive to 'reg'
>>> Furthermore, I am not aware of any restriction for us to re-use them. Do
>>> you have a pointer?
>> As we are discussing re-usage of #address-cells and #size-cells for custom properties that are not "reg",
>> I took this info from the latest device tree specs found under https://www.devicetree.org/specifications/:
>> "The #address-cells property defines the number of <u32> cells used to encode the address field in a child node's reg property"
>> and
>> "The #size-cells property defines the number of <u32> cells used to encode the size field in a child node’s reg property"
>
> Right. But there is nothing in the wording suggesting that #address-cells and #size-cells can't be re-used. From [1], it is clear that the meaning has changed.
>
> So why can't we do the same?
I agree here, those are used for how reg is encoded but nothing says that we cannot reuse them for the encoding of something else.
Even if we do not use “reg” for those sets, they are still defining memory addresses and sizes which is coherent.
In some cases reg is used to encode something different so those could have different values that we could not use but for the chosen node, they should always set the encoding for something addressing a memory area.
So if we have a good reason then I would vote for xen,memory-* proposal but so far I could not find a reason not to use the standard ones.
Cheers
Bertrand
>
> Cheers,
>
> --
> Julien Grall
Hi Julien,
> -----Original Message-----
> From: Julien Grall <julien@xen.org>
> Subject: Re: [PATCH v3 2/4] docs, xen/arm: Introduce static heap memory
>
> Hi Henry,
>
> While reviewing the binding sent by Penny I noticed some inconsistency
> with the one you introduced. See below.
>
> On 07/09/2022 09:36, Henry Wang wrote:
> > +- xen,static-heap
> > +
> > + Property under the top-level "chosen" node. It specifies the address
> > + and size of Xen static heap memory. Note that at least a 64KB
> > + alignment is required.
> > +
> > +- #xen,static-heap-address-cells and #xen,static-heap-size-cells
> > +
> > + Specify the number of cells used for the address and size of the
> > + "xen,static-heap" property under "chosen".
> > +
> > +Below is an example on how to specify the static heap in device tree:
> > +
> > + / {
> > + chosen {
> > + #xen,static-heap-address-cells = <0x2>;
> > + #xen,static-heap-size-cells = <0x2>;
>
> Your binding, is introduce #xen,static-heap-{address, size}-cells
> whereas Penny's one is using #{address, size}-cells even if the property
> is not "reg".
>
> I would like some consistency in the way we define bindings. Looking at
> the tree, we already seem to have introduced
> #xen-static-mem-address-cells. So maybe we should follow your approach?
>
> That said, I am wondering whether we should just use one set of property
> name.
IMO now we have the pair
#xen,static-heap-{address, size}-cells and xen,static-heap for static heap.
and the pair
#xen,static-mem-{address, size}-cells and xen,static-mem for static
memory allocation for dom0less.
So at least these two are consistent.
I guess the concern you raised is related to the static shared memory for
dom0less,
...
>
> I am open to suggestion here. My only request is we are consistent (i.e.
> this doesn't depend on who wrote the bindings).
I am not sure if Penny and Stefano have some specific requirements
regarding the static shared memory usage. So I will wait for Stefano's input.
But yeah we need to keep the consistency so if we are agreed that I need to
change the binding, I will do the corresponding change.
Kind regards,
Henry
>
> Cheers,
>
> --
> Julien Grall
Hi,
> On 7 Sep 2022, at 12:48, Henry Wang <Henry.Wang@arm.com> wrote:
>
> Hi Julien,
>
>> -----Original Message-----
>> From: Julien Grall <julien@xen.org>
>> Subject: Re: [PATCH v3 2/4] docs, xen/arm: Introduce static heap memory
>>
>> Hi Henry,
>>
>> While reviewing the binding sent by Penny I noticed some inconsistency
>> with the one you introduced. See below.
>>
>> On 07/09/2022 09:36, Henry Wang wrote:
>>> +- xen,static-heap
>>> +
>>> + Property under the top-level "chosen" node. It specifies the address
>>> + and size of Xen static heap memory. Note that at least a 64KB
>>> + alignment is required.
>>> +
>>> +- #xen,static-heap-address-cells and #xen,static-heap-size-cells
>>> +
>>> + Specify the number of cells used for the address and size of the
>>> + "xen,static-heap" property under "chosen".
>>> +
>>> +Below is an example on how to specify the static heap in device tree:
>>> +
>>> + / {
>>> + chosen {
>>> + #xen,static-heap-address-cells = <0x2>;
>>> + #xen,static-heap-size-cells = <0x2>;
>>
>> Your binding, is introduce #xen,static-heap-{address, size}-cells
>> whereas Penny's one is using #{address, size}-cells even if the property
>> is not "reg".
>>
>> I would like some consistency in the way we define bindings. Looking at
>> the tree, we already seem to have introduced
>> #xen-static-mem-address-cells. So maybe we should follow your approach?
>>
>> That said, I am wondering whether we should just use one set of property
>> name.
The more I dig, the less I find a use case where we could need different values here.
Maybe just:
#xen,address-cells = <2>
#xen,size-cells = <2>
Could be enough. If some parameter needs a different value it could introduce a specific name.
Or maybe just memory-address-cells and memory-size-cells if we see a possibility to require a different value for an other address or size.
This would also make life easier for users as we could just always put those 2 in our examples.
Cheers
Bertrand
>
> IMO now we have the pair
> #xen,static-heap-{address, size}-cells and xen,static-heap for static heap.
> and the pair
> #xen,static-mem-{address, size}-cells and xen,static-mem for static
> memory allocation for dom0less.
>
> So at least these two are consistent.
>
> I guess the concern you raised is related to the static shared memory for
> dom0less,
> ...
>
>>
>> I am open to suggestion here. My only request is we are consistent (i.e.
>> this doesn't depend on who wrote the bindings).
>
> I am not sure if Penny and Stefano have some specific requirements
> regarding the static shared memory usage. So I will wait for Stefano's input.
> But yeah we need to keep the consistency so if we are agreed that I need to
> change the binding, I will do the corresponding change.
>
> Kind regards,
> Henry
>
>>
>> Cheers,
>>
>> --
>> Julien Grall
On 07/09/2022 13:12, Bertrand Marquis wrote:
> Hi,
Hi Bertrand,
>> On 7 Sep 2022, at 12:48, Henry Wang <Henry.Wang@arm.com> wrote:
>>
>> Hi Julien,
>>
>>> -----Original Message-----
>>> From: Julien Grall <julien@xen.org>
>>> Subject: Re: [PATCH v3 2/4] docs, xen/arm: Introduce static heap memory
>>>
>>> Hi Henry,
>>>
>>> While reviewing the binding sent by Penny I noticed some inconsistency
>>> with the one you introduced. See below.
>>>
>>> On 07/09/2022 09:36, Henry Wang wrote:
>>>> +- xen,static-heap
>>>> +
>>>> + Property under the top-level "chosen" node. It specifies the address
>>>> + and size of Xen static heap memory. Note that at least a 64KB
>>>> + alignment is required.
>>>> +
>>>> +- #xen,static-heap-address-cells and #xen,static-heap-size-cells
>>>> +
>>>> + Specify the number of cells used for the address and size of the
>>>> + "xen,static-heap" property under "chosen".
>>>> +
>>>> +Below is an example on how to specify the static heap in device tree:
>>>> +
>>>> + / {
>>>> + chosen {
>>>> + #xen,static-heap-address-cells = <0x2>;
>>>> + #xen,static-heap-size-cells = <0x2>;
>>>
>>> Your binding, is introduce #xen,static-heap-{address, size}-cells
>>> whereas Penny's one is using #{address, size}-cells even if the property
>>> is not "reg".
>>>
>>> I would like some consistency in the way we define bindings. Looking at
>>> the tree, we already seem to have introduced
>>> #xen-static-mem-address-cells. So maybe we should follow your approach?
>>>
>>> That said, I am wondering whether we should just use one set of property
>>> name.
>
> The more I dig, the less I find a use case where we could need different values here.
This is what I thought as well..
> Maybe just:
> #xen,address-cells = <2>
> #xen,size-cells = <2>
> Could be enough. If some parameter needs a different value it could introduce a specific name.
I think '#xen,...' is ambiguous because it doesn't tell you whether it
applies to the memory range or interrupt range. So I would got with
>
> Or maybe just memory-address-cells and memory-size-cells if we see a possibility to require a different value for an other address or size.
"#xen,memory-*".
That said, any reason to not reuse #address-cells and #size-cells here?
Cheers,
--
Julien Grall
Hi Henry,
On 07/09/2022 09:36, Henry Wang wrote:
> static int __init early_scan_node(const void *fdt,
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index b76a84e8f5..0741645014 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1038,9 +1038,11 @@ static int __init make_memory_node(const struct domain *d,
> if ( mem->nr_banks == 0 )
> return -ENOENT;
>
> - /* find first memory range not bound to a Xen domain */
> - for ( i = 0; i < mem->nr_banks && mem->bank[i].xen_domain; i++ )
> + /* find first memory range not bound to a Xen domain nor heap */
This comment could become stale if we are adding a new type. So how about:
/* find the first memory range that is reserved for device (or firmware) */
> + for ( i = 0; i < mem->nr_banks &&
> + (mem->bank[i].type != MEMBANK_DEFAULT); i++ )
> ;
> +
> if ( i == mem->nr_banks )
> return 0;
>
> @@ -1062,7 +1064,7 @@ static int __init make_memory_node(const struct domain *d,
> u64 start = mem->bank[i].start;
> u64 size = mem->bank[i].size;
>
> - if ( mem->bank[i].xen_domain )
> + if ( mem->bank[i].type == MEMBANK_STATIC_DOMAIN )
> continue;
>
> dt_dprintk(" Bank %d: %#"PRIx64"->%#"PRIx64"\n",
> diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
> index 5815ccf8c5..6bea15acff 100644
> --- a/xen/arch/arm/include/asm/setup.h
> +++ b/xen/arch/arm/include/asm/setup.h
> @@ -22,11 +22,31 @@ typedef enum {
> BOOTMOD_UNKNOWN
> } bootmodule_kind;
>
> +enum membank_type {
> + /*
> + * The MEMBANK_DEFAULT type refers to either reserved memory for the
> + * device (or firmware) or any memory that will be used by the allocator.
I realize the part of the 'or' is what I suggested. However, I wasn't
correct here (sorry).
In the context of 'mem' this is referring to any RAM. The setup code
will then find the list of the regions that doesn't overlap with the
'reserved_mem' and then give the pages to the boot allocator (and
subsequently the buddy allocator). Also...
> + * The meaning depends on where the memory bank is actually used.
... this doesn't tell the reader which means applies where. So I would
suggest the following:
The MEMBANK_DEFAULT type refers to either reserved memory for the
device/firmware (when the bank is in 'reserved_mem') or any RAM (when
the bank is in 'mem'
The rest of the code looks good to me. So once we settled on the two
comments above:
Reviewed-by: Julien Grall <jgrall@amazon.com>
Cheers,
--
Julien Grall
Hi Julien,
> -----Original Message-----
> From: Julien Grall <julien@xen.org>
> > - /* find first memory range not bound to a Xen domain */
> > - for ( i = 0; i < mem->nr_banks && mem->bank[i].xen_domain; i++ )
> > + /* find first memory range not bound to a Xen domain nor heap */
>
> This comment could become stale if we are adding a new type. So how about:
>
> /* find the first memory range that is reserved for device (or firmware) */
Ok, will use this one.
>
> > +enum membank_type {
> > + /*
> > + * The MEMBANK_DEFAULT type refers to either reserved memory for
> the
> > + * device (or firmware) or any memory that will be used by the allocator.
>
> I realize the part of the 'or' is what I suggested. However, I wasn't
> correct here (sorry).
No problem, actually, I've learned a lot about how Xen does the memory
management from your comments. So I should say thank you.
>
> In the context of 'mem' this is referring to any RAM. The setup code
> will then find the list of the regions that doesn't overlap with the
> 'reserved_mem' and then give the pages to the boot allocator (and
> subsequently the buddy allocator). Also...
>
> > + * The meaning depends on where the memory bank is actually used.
>
> ... this doesn't tell the reader which means applies where. So I would
> suggest the following:
>
> The MEMBANK_DEFAULT type refers to either reserved memory for the
> device/firmware (when the bank is in 'reserved_mem') or any RAM (when
> the bank is in 'mem'
Ok will follow that.
>
> The rest of the code looks good to me. So once we settled on the two
> comments above:
>
> Reviewed-by: Julien Grall <jgrall@amazon.com>
Thanks!
Kind regards,
Henry
>
> Cheers,
>
> --
> Julien Grall
© 2016 - 2026 Red Hat, Inc.