[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [RFC PATCH v2 00/15] xen/arm: port Linux LL/SC and LSE atomics helpers to Xen.
On 11/11/2020 21:51, Ash Wilding wrote: From: Ash Wilding <ash.j.wilding@xxxxxxxxx> Hey, Hi Ash, I've found some time to improve this series a bit: Changes since RFC v1 ==================== - Broken up patches into smaller chunks to aid in readability. - As per Julien's feedback I've also introduced intermediary patches that first remove Xen's existing headers, then pull in the current Linux versions as-is. This means we only need to review the changes made while porting to Xen, rather than reviewing the existing Linux code. - Pull in Linux's <asm-generic/rwonce.h> as <xen/rwonce.h> for __READ_ONCE()/__WRITE_ONCE() instead of putting these in Xen's <xen/compiler.h>. While doing this, provide justification for dropping Linux's <linux/compiler_types.h> and relaxing the __READ_ONCE() usage of __unqual_scalar_typeof() to just typeof() (see patches #5 and #6). Keeping the rest of the cover-letter unchanged as it would still be good to discuss these things: Arguments in favour of doing this ================================= - Lets SMMUv3 driver switch to using <asm/atomic.h> rather than maintaining its own implementation of the helpers. - Provides mitigation against XSA-295 [2], which affects both arm32 and arm64, across all versions of Xen, and may allow a domU to maliciously or erroneously DoS the hypervisor. - All Armv8-A core implementations since ~2017 implement LSE so there is an argument to be made we are long overdue support in Xen. This is compounded by LSE atomics being more performant than LL/SC atomics in most real-world applications, especially at high core counts. - We may be able to get improved performance when using LL/SC too as Linux provides helpers with relaxed ordering requirements which are currently not available in Xen, though for this we would need to go back through existing code to see where the more relaxed versions can be safely used. - Anything else? Arguments against doing this ============================ - Limited testing infrastructure in place to ensure use of new atomics helpers does not introduce new bugs and regressions. This is a particularly strong argument given how difficult it can be to identify and debug malfunctioning atomics. The old adage applies, "If it ain't broke, don't fix it." I am not too concerned about the Linux atomics implementation. They are well tested and your changes doesn't seem to touch the implementation itself. However, I vaguely remember that some of the atomics helper in Xen are somewhat much stronger than the Linux counterpart. Would you be able to look at all the existing helpers and see whether the memory ordering diverge? Once we have a list we could decide whether we want to make them stronger again or check the callers. Cheers, -- Julien Grall
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |