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

[Ash Wilding <ash.j.wilding@xxxxxxxxx>]

Hi Julien,


> Would Arm be willing to add support for LSE before merging the
> SMMUv3?

(( Taking my Arm hat off for a second and speaking independently... ))

I've been toying with doing this in my own personal time but unsure how
long it would take (unable to commit much time on it right now). I'll
let the Arm folks speak for themselves as to whether they're able and
willing do it.

If not, I don't necessarily think pulling in Linux's LL/SC and LSE
atomics helpers should block merging the SMMUv3 driver if everything
else is OK after review; we could use Rahul's versions in the driver
for now and then merge Linux's helpers later.


> I would prefer to follow the same approach as Linux and allow Xen to 
> select at boot time which implementations to use. This would enable 
> distro to provide a single binary that boot on all Armv8 and still
> allow Xen to select the best set of instructions.

Yep good idea, agreed.

Note that while Linux uses the alternatives framework for LL/SC vs LSE,
it's still controlled by CONFIG_ARM64_LSE_ATOMICS, see [3]. This would
give us the best of both worlds - distros can build with the Kconfig =y
to enable single image with runtime detection, while expert users can
still build a custom image to force use of LL/SC on v8.1+ systems should
they wish.


> I asked Jan to add this line in the commit message :). My concern was 
> that even if we provided a runtime switch (or sanity check for
> XSA-295), the GCC helpers would not be able to take advantage (the
> code is not written by Xen community).

Ahh yes, makes sense - all the more reason for us to get explicit
implementations into Xen sooner rather than later :-)


Thanks,
Ash.

> [1] https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=5d45ecabe3
> [2] https://xenbits.xen.org/xsa/advisory-295.html
[3] 
https://elixir.bootlin.com/linux/latest/source/arch/arm64/include/asm/lse.h#L7