Re: [PATCH v6 01/13] xen/pci: arm: add stub for is_memory_hole

[Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>]

On 04.02.22 13:00, Julien Grall wrote:
>
>
> On 04/02/2022 10:35, Oleksandr Andrushchenko wrote:
>>
>>
>> On 04.02.22 11:57, Julien Grall wrote:
>>> Hi,
>>>
>>> On 04/02/2022 09:47, Oleksandr Andrushchenko wrote:
>>>>>> Could you please help me with the exact message you would like to see?
>>>>>
>>>>> Here a summary of the discussion (+ some my follow-up thoughts):
>>>>>
>>>>> is_memory_hole() was recently introduced on x86 (see commit 75cc460a1b8c 
>>>>> "xen/pci: detect when BARs are not suitably positioned") to check whether 
>>>>> the BAR are positioned outside of a valid memory range. This was 
>>>>> introduced to work-around quirky firmware.
>>>>>
>>>>> In theory, this could also happen on Arm. In practice, this may not 
>>>>> happen but it sounds better to sanity check that the BAR contains "valid" 
>>>>> I/O range.
>>>>>
>>>>> On x86, this is implemented by checking the region is not described is in 
>>>>> the e820. IIUC, on Arm, the BARs have to be positioned in pre-defined 
>>>>> ranges. So I think it would be possible to implement is_memory_hole() by 
>>>>> going through the list of hostbridges and check the ranges.
>>>>>
>>>>> But first, I'd like to confirm my understanding with Rahul, and others.
>>>>>
>>>>> If we were going to go this route, I would also rename the function to be 
>>>>> better match what it is doing (i.e. it checks the BAR is correctly 
>>>>> placed). As a potentially optimization/hardening for Arm, we could pass 
>>>>> the hostbridge so we don't have to walk all of them.
>>>> It seems this needs to live in the commit message then? So, it is easy to 
>>>> find
>>>> as everything after "---" is going to be dropped on commit
>>> I expect the function to be fully implemented before this is will be merged.
>>>
>>> So if it is fully implemented, then a fair chunk of what I wrote would not 
>>> be necessary to carry in the commit message.
>> Well, we started from that we want *something* with TODO and now
>> you request it to be fully implemented before it is merged.
>
> I don't think I ever suggested this patch would be merged as-is. Sorry if 
> this may have crossed like this.
Np
>
> Instead, my intent by asking you to send a TODO patch is to start a 
> discussion how this function could be implemented for Arm.
>
> You sent a TODO but you didn't provide any summary on what is the issue, what 
> we want to achieve... Hence my request to add a bit more details so the other 
> reviewers can provide their opinion more easily.
Ok, so we can discuss it here, but I won't have this patch in v7
>
> Cheers,
>
Thank you,
Oleksandr