Re: [PATCH 1/7] xen/arm: Lookup bootinfo shm bank during the mapping

[Luca Fancellu <Luca.Fancellu@xxxxxxx>]

Hi Michal,

Thanks for your review.

> On 6 May 2024, at 14:24, Michal Orzel <michal.orzel@xxxxxxx> wrote:
> 
> Hi Luca,
> 
> On 23/04/2024 10:25, Luca Fancellu wrote:
>> 
>> 
>> The current static shared memory code is using bootinfo banks when it
>> needs to find the number of borrower, so every time assign_shared_memory
> s/borrower/borrowers

Will fix

> 
>> is called, the bank is searched in the bootinfo.shmem structure.
>> 
>> There is nothing wrong with it, however the bank can be used also to
>> retrieve the start address and size and also to pass less argument to
>> assign_shared_memory. When retrieving the information from the bootinfo
>> bank, it's also possible to move the checks on alignment to
>> process_shm_node in the early stages.
> Is this change really required for what you want to achieve? At the moment 
> the alignment checks
> are done before first use, which requires these values to be aligned. FDT 
> processing part does not need it.

That’s true, but it would separate better the parsing part, in the end what is 
the point of failing later if, for example,
some value are passed but not aligned? 

> 
>> 
>> So create a new function find_shm() which takes a 'struct shared_meminfo'
> Can we name it find_shm_bank() or find_shm_bank_by_id()?
> I agree that it's better to use a unique ID rather than matching by 
> address/size

Yes either names are good for me, I would use find_shm_bank_by_id

> 
>> structure and the shared memory ID, to look for a bank with a matching ID,
>> take the physical host address and size from the bank, pass the bank to
>> assign_shared_memory() removing the now unnecessary arguments and finally
>> remove the acquire_nr_borrower_domain() function since now the information
>> can be extracted from the passed bank.
>> Move the "xen,shm-id" parsing early in process_shm to bail out quickly in
>> case of errors (unlikely), as said above, move the checks on alignment
>> to process_shm_node.
>> 
>> Drawback of this change is that now the bootinfo are used also when the
>> bank doesn't need to be allocated, however it will be convinient later
>> to use it as an argument for assign_shared_memory when dealing with
>> the use case where the Host physical address is not supplied by the user.
>> 
>> Signed-off-by: Luca Fancellu <luca.fancellu@xxxxxxx>
>> ---
>> xen/arch/arm/static-shmem.c | 105 ++++++++++++++++++++----------------
>> 1 file changed, 58 insertions(+), 47 deletions(-)
>> 
>> diff --git a/xen/arch/arm/static-shmem.c b/xen/arch/arm/static-shmem.c
>> index 09f474ec6050..f6cf74e58a83 100644
>> --- a/xen/arch/arm/static-shmem.c
>> +++ b/xen/arch/arm/static-shmem.c
>> @@ -19,29 +19,24 @@ static void __init __maybe_unused build_assertions(void)
>>                  offsetof(struct shared_meminfo, bank)));
>> }
>> 
>> -static int __init acquire_nr_borrower_domain(struct domain *d,
>> -                                             paddr_t pbase, paddr_t psize,
>> -                                             unsigned long *nr_borrowers)
>> +static const struct membank __init *find_shm(const struct membanks *shmem,
>> +                                             const char *shm_id)
>> {
>> -    const struct membanks *shmem = bootinfo_get_shmem();
>>     unsigned int bank;
>> 
>> -    /* Iterate reserved memory to find requested shm bank. */
>> +    BUG_ON(!shmem || !shm_id);
> Is it really necessary? For example, before calling find_shm(), strlen is 
> used on shm_id

So, I guess I did that to have more robust code, in case someone changes the 
code in the
future and perhaps removes something we rely on. If you object to them I will 
remove though,
here and the other related points below.

> 
>> +
>>     for ( bank = 0 ; bank < shmem->nr_banks; bank++ )
>>     {
>> -        paddr_t bank_start = shmem->bank[bank].start;
>> -        paddr_t bank_size = shmem->bank[bank].size;
>> -
>> -        if ( (pbase == bank_start) && (psize == bank_size) )
>> +        if ( strncmp(shm_id, shmem->bank[bank].shmem_extra->shm_id,
>> +                     MAX_SHM_ID_LENGTH) == 0 )
> Why not strcmp? AFAICS it's been validated many times already
> 
>>             break;
>>     }
>> 
>>     if ( bank == shmem->nr_banks )
>> -        return -ENOENT;
>> -
>> -    *nr_borrowers = shmem->bank[bank].shmem_extra->nr_shm_borrowers;
>> +        return NULL;
>> 
>> -    return 0;
>> +    return &shmem->bank[bank];
>> }
>> 
>> /*
>> @@ -103,14 +98,20 @@ static mfn_t __init acquire_shared_memory_bank(struct 
>> domain *d,
>>     return smfn;
>> }
>> 
>> -static int __init assign_shared_memory(struct domain *d,
>> -                                       paddr_t pbase, paddr_t psize,
>> -                                       paddr_t gbase)
>> +static int __init assign_shared_memory(struct domain *d, paddr_t gbase,
>> +                                       const struct membank *shm_bank)
>> {
>>     mfn_t smfn;
>>     int ret = 0;
>>     unsigned long nr_pages, nr_borrowers, i;
>>     struct page_info *page;
>> +    paddr_t pbase, psize;
>> +
>> +    BUG_ON(!shm_bank || !shm_bank->shmem_extra);
> Is it really necessary? Isn't shm_bank already validated? It's not very 
> common to have NULL checks in internal functions.
> 

[...]

>> 
>> @@ -440,6 +431,26 @@ int __init process_shm_node(const void *fdt, int node, 
>> uint32_t address_cells,
>>     device_tree_get_reg(&cell, address_cells, address_cells, &paddr, &gaddr);
>>     size = dt_next_cell(size_cells, &cell);
>> 
>> +    if ( !IS_ALIGNED(paddr, PAGE_SIZE) )
>> +    {
>> +        printk("fdt: physical address 0x%"PRIpaddr" is not suitably 
>> aligned.\n",
>> +               paddr);
>> +        return -EINVAL;
>> +    }
>> +
>> +    if ( !IS_ALIGNED(gaddr, PAGE_SIZE) )
>> +    {
>> +        printk("fdt: guest address 0x%"PRIpaddr" is not suitably 
>> aligned.\n",
>> +               gaddr);
>> +        return -EINVAL;
>> +    }
>> +
>> +    if ( !IS_ALIGNED(size, PAGE_SIZE) )
> What sense does it make to check for size being aligned before checking for 
> size being 0? It would pass this check.

Yes, but in the end we are doing that to print a different error message, so it 
would pass
for 0 and it’s totally fine, but in the end it will fail afterwards. I don’t 
see functional disruptions
having this one before the other, what is the concern here?

> 
>> +    {
>> +        printk("fdt: size 0x%"PRIpaddr" is not suitably aligned\n", size);
>> +        return -EINVAL;
>> +    }
>> +
>>     if ( !size )
>>     {
>>         printk("fdt: the size for static shared memory region can not be 
>> zero\n");
>> --
>> 2.34.1
>> 

Cheers,
Luca