Re: [XEN PATCH v1] xen/arm : Add support for SMMUv3 driver

[Bertrand Marquis <Bertrand.Marquis@xxxxxxx>]

Hi Julien,

> On 27 Oct 2020, at 14:37, Julien Grall <julien@xxxxxxx> wrote:
> 
> 
> 
> On 27/10/2020 14:19, Bertrand Marquis wrote:
>> Hi Julien,
> 
> Hi Bertrand,
> 
>>> On 26 Oct 2020, at 19:05, Julien Grall <julien@xxxxxxx> wrote:
>>> 
>>> On 26/10/2020 12:10, Ash Wilding wrote:
>>>> Hi,
>>> 
>>> Hi Ash,
>>> 
>>>>> 1. atomic_set_release
>>>>> 2. atomic_fetch_andnot_relaxed
>>>>> 3. atomic_cond_read_relaxed
>>>>> 4. atomic_long_cond_read_relaxed
>>>>> 5. atomic_long_xor
>>>>> 6. atomic_set_release
>>>>> 7. atomic_cmpxchg_relaxed might be we can use atomic_cmpxchg that is
>>>>>    implemented in XEN need to check.
>>>>> 8. atomic_dec_return_release
>>>>> 9. atomic_fetch_inc_relaxed
>>>> If we're going to pull in Linux's implementations of the above atomics
>>>> helpers for SMMUv3, and given the majority of SMMUv3 systems are v8.1+
>>>> with LSE, perhaps this would be a good time to drop the current
>>>> atomic.h in Xen completely and pull in both Linux's LL/SC and LSE
>>>> helpers,
>>> 
>>> When I originally answered to the thread, I thought about suggesting 
>>> importing LSE. But I felt it was too much to ask in order to merge the 
>>> SMMUv3 code.
>>> 
>>> However, I would love to have support for LSE in Xen as this would solve 
>>> other not yet fully closed security issue with LL/SC (see XSA-295 [2]).
>>> 
>>> Would Arm be willing to add support for LSE before merging the SMMUv3?
>> We are willing to work on LSE but I cannot commit on me and my team to start 
>> working on this subject before the end of the year.
> 
> That's fine. There are other way we can bridge the gap between Xen and Linux 
> in order to get the latest version (see more below).
> 
>> So I think it would be good to integrate this version of SMMUv3 and we can 
>> then update it to the latest Linux one once LSE has been added.
> 
> As I pointed out in my first e-mail on this thread, I am quite concerned that 
> we are going to (re-)introduce bugs that have been fixed in Linux.
> Did you investigate that this is not going to happen?

We will take the action to check changes in Linux in the driver since the 
version we are based on to make sure no critical fixes have been done
that are needed in our code.

> 
> However, I think we can manage to get the latest version without requiring 
> LSE. It should be possible to provide dumb version of most the helpers.

If this is done, there would still be after a big work on switching to the 
newer code from Linux, testing and reviewing it.

Updating the driver after those dumb versions are added would still be possible.

Cheers
Bertrand

> 
>> I think it make sense in the meantime to discuss how this should be designed 
>> but it might be a good idea to make a specific discussion thread for that.
> 
> Make sense. Can you start a new thread?
> 
> Cheers,
> 
> -- 
> Julien Grall