Hi Bertrand > On 16 Oct 2023, at 2:31 pm, Bertrand Marquis <bertrand.marq...@arm.com> wrote: > > Hi Julien, > >> On 16 Oct 2023, at 11:07, Julien Grall <jul...@xen.org> wrote: >> >> Hi, >> >> On 13/10/2023 16:24, Federico Serafini wrote: >>> Add missing parameter names, no functional change. >>> Signed-off-by: Federico Serafini <federico.seraf...@bugseng.com> >>> --- >>> xen/drivers/passthrough/arm/smmu.c | 6 +++--- >> >> This file is using the Linux coding style because it is imported from Linux. >> I was under the impression we would exclude such file for now. >> >> Looking at exclude-list.json, it doesn't seem to be present. I think this >> patch should be replaced with adding a line in execlude-list.json. > > I think that during one of the discussions we said that this file already > deviated quite a lot from the status in Linux and we wanted to turn it to Xen > coding style in the future hence it is not listed in the exclude file. > At the end having a working smmu might be critical in a safety context so it > will make sense to also check this part of xen. > > @Rahul: do you agree ?
Yes, you are right current SMMUv3 code already deviates quite a lot from the status of Linux because Xen handles the command queue in a different way than the way Linux handles it. More detailed can be found at the start of the SMMUv3 file. I am pasting it here also. * 5. Latest version of the Linux SMMUv3 code implements the commands queue * access functions based on atomic operations implemented in Linux. * Atomic functions used by the commands queue access functions are not * implemented in XEN therefore we decided to port the earlier version * of the code. Atomic operations are introduced to fix the bottleneck of * the SMMU command queue insertion operation. A new algorithm for * inserting commands into the queue is introduced, which is * lock-free on the fast-path. * Consequence of reverting the patch is that the command queue insertion * will be slow for large systems as spinlock will be used to serializes * accesses from all CPUs to the single queue supported by the hardware. * Once the proper atomic operations will be available in XEN the driver * can be updated. Anyway because of above reason backporting SMMUv3 Linux driver patches to Xen are not straight forward. If making smmu-v3.c to Xen coding style helps in safety context I am okay with that. Regards, Rahul
