Hi Julien,
Thanks for looking at this,
> vcpu_block() is now gaining an smp_mb__after_atomic() to prevent the
> CPU to read any information about local events before the flag
> _VPF_blocked is set.
Reviewed-by: Ash Wilding
As an aside,
> I couldn't convince myself whe
Having pondered note (1) in my previous email a bit more, I imagine the reason
for using a DMB instead of acq/rel semantics is to prevent accesses following
the STLXR from being reordered between it and the LDAXR.
I won't be winning any awards for this ASCII art but hopefully it helps convey
the
Hi Julien,
Thanks for taking a look at the patches and providing feedback. I've seen your
other comments and will reply to those separately when I get a chance (maybe at
the weekend or over the Christmas break).
RE the differences in ordering semantics between Xen's and Linux's atomics
helpers,
Hey Jan,
>>
>> Note that Linux's arm32 atomics helpers use the READ_ONCE() and
>> WRITE_ONCE() macros defined in , while Linux's
>> arm64 atomics helpers use __READ_ONCE() and __WRITE_ONCE().
>
> And our ACCESS_ONCE() can't be used, or be made usable? I don't think
> we want a 3rd variant when
From: Ash Wilding
Now that we have explicit implementations of LL/SC and LSE atomics
helpers after porting Linux's versions to Xen, we can drop the reference
to gcc's built-in __sync_fetch_and_add().
This requires some fudging using container_of() because the users of
__sync_fetch_and_add
From: Ash Wilding
- Drop atomic64_t helper declarations as we don't currently have an
atomic64_t in Xen.
- Drop arch_* prefixes.
- Swap include of to just .
Signed-off-by: Ash Wilding
---
xen/include/asm-arm/arm64/atomic.h | 256 -
1 file changed, 73
From: Ash Wilding
This just involves making system_uses_lse_atomics() call cpus_have_cap()
instead of directly looking up in cpu_hwcap_keys.
Not 100% sure whether this is a valid transformation until I do a run
test.
Signed-off-by: Ash Wilding
---
xen/include/asm-arm/arm64/lse.h | 30
From: Ash Wilding
- s/arch_xchg/xchg/
- s/arch_cmpxchg/cmpxchg/
- Replace calls to BUILD_BUG() with calls to __bad_cmpxchg() as we
don't currently have a BUILD_BUG() macro in Xen and this will
equivalently cause a link-time error.
- Replace calls to VM_BUG_ON() with BUG_ON() as we
From: Ash Wilding
- Drop support for pre-Armv7 systems, including the workarounds for
the swp instruction being broken on StrongARM.
- Drop local variants as no callers in Xen.
- Keep the compiler happy by fixing __cmpxchg64()'s ptr arg to be
volatile, and casting ptr to be (const
From: Ash Wilding
- Drop arch_* prefixes.
- Redirect include of to , and swap
usage of READ_ONCE()/WRITE_ONCE() to the __* versions accordingly.
As discussed earlier in the series, we can do this because we're
accessing an atomic_t's counter member, which is an int, so the
extra
From: Ash Wilding
This patch pulls in Linux's atomics helpers for arm32 and arm64, and
their dependencies, as-is.
Note that Linux's arm32 atomics helpers use the READ_ONCE() and
WRITE_ONCE() macros defined in , while Linux's
arm64 atomics helpers use __READ_ONCE() and __WRITE_ONCE().
The only
From: Ash Wilding
- Drop kasan related helpers.
- Drop READ_ONCE() and WRITE_ONCE(); the __* versions are fine for now
as the only callers in Xen are the arm32 atomics helpers which are
always accessing an atomic_t's counter member, which is an int. This
means we can swap the arm32
From: Ash Wilding
To maintain clean diffs and dissectability, let's delete the existing
Xen atomics helpers before pulling in the Linux versions.
Signed-off-by: Ash Wilding
---
xen/include/asm-arm/arm32/atomic.h | 175 -
xen/include/asm-arm/arm32/cmpxchg.h | 229
From: Ash Wilding
As with the LL/SC atomics helpers, most of the "work" here is simply
deleting the atomic64_t helper definitions as we don't have an
atomic64_t type in Xen.
We do also need to s/__always_inline/always_inline/ to match the
qualifier name used by Xen.
Signed-off-by: A
From: Ash Wilding
Most of the "work" here is simply deleting the atomic64_t helper
definitions as we don't have an atomic64_t type in Xen.
Signed-off-by: Ash Wilding
---
xen/include/asm-arm/arm64/atomic_ll_sc.h | 134 +--
1 file changed, 6 insertions(+), 128
From: Ash Wilding
This small patch helps prepare and the arm32/arm64
specific system.h headers to play nicely with the Linux atomics helpers:
- We don't need the indirection around atomic_add_unless() anymore so
let's just pull up the old Xen arm64 definition into here and use
From: Ash Wilding
Hey,
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
From: Ash Wilding
This patch introduces the ARM64_HAS_LSE_ATOMICS hwcap.
While doing this, CONFIG_ARM64_LSE_ATOMICS is added to control whether
the hwcap is actually detected and set at runtime. Without this Kconfig
being set we will always fallback on LL/SC atomics using Armv8.0 exlusive
From: Ash Wilding
The current Arm boot_cpu_feature64() and boot_cpu_feature32() macros
are hardcoded to only detect features in ID_AA64PFR{0,1}_EL1 and
ID_PFR{0,1} respectively.
This patch replaces these macros with a new macro, boot_cpu_feature(),
which takes an explicit ID register name
From: Ash Wilding
Use the new infrastructure for detecting CPU features in other ID
registers to detect the presence of Armv8.1-LSE atomic instructions,
as reported by ID_AA64ISAR0_EL1.Atomic.
While we're here, print detection of these instructions in setup.c's
processor_id().
Signed-off
Hey Julien,
>
> First of all, thank you for taking a stab at adding LSE support in
> Xen!
No problem!
>>
>> In retrospect I should have put an intermediate patch between #3 and
>> #4, deleting the existing headers. This would have made the patch
>> diff for #4 and #5 much easier to read seeing
Hi,
In retrospect I should have put an intermediate patch between #3 and #4,
deleting the existing headers. This would have made the patch diff for
#4 and #5 much easier to read seeing as they are copying the Linux
versions wholesale into Xen.
I'll do that for V1 when we get there, but for now
Hi,
As mentioned in my reply to patch #4 just now, in retrospect I should
have put an intermediate patch between #3 and #4, deleting the existing
headers. This would have made the patch diff for #4 and #5 much easier
to read seeing as they are copying the Linux versions into Xen.
I'll do that
in the
series ports Linux's 32-bit LL/SC helpers. The patches have
been split in this way to aid in reviewing and discussing.
Signed-off-by: Ash Wilding
---
xen/include/asm-arm/arm64/atomic.h | 242 +--
xen/include/asm-arm/arm64/atomic_ll_sc.h | 236
Use the new infrastructure for detecting CPU features in other ID
registers to detect the presence of Armv8.1-LSE atomic instructions,
as reported by ID_AA64ISAR0_EL1.Atomic.
While we're here, print detection of these instructions in setup.c's
processor_id().
Signed-off-by: Ash Wilding
---
xen
we're here, cull cpu_feature64() and cpu_feature32() as they
have no callers (we only ever use the boot CPU features), and update
the printk() messages in setup.c to use the new macro.
Signed-off-by: Ash Wilding
---
xen/arch/arm/setup.c | 8 +++---
xen/include/asm-arm/cpufeature.h | 44
this patch does not actually add the ALTERNATIVE() switching based
on the hwcap being detected and set; that comes later in the series.
Signed-off-by: Ash Wilding
---
xen/arch/arm/Kconfig | 11 +++
xen/arch/arm/Makefile| 1 +
xen/arch/arm/lse.c | 13
This patch ports Linux's arm32 LL/SC atomics helpers to Xen.
The opening comment of each header file details the changes made to
that file while porting it to Xen.
Signed-off-by: Ash Wilding
---
xen/include/asm-arm/arm32/atomic.h | 261 ++
xen/include/asm-arm/arm32/cmpxchg.h
actually matter
because we do the addition in assembly and the compiler isn't smart enough
to detect signed integer overflow in inline assembly, but I thought it worth
calling out in the commit message.
Signed-off-by: Ash Wilding
---
xen/include/asm-arm/arm32/atomic.h | 2 +-
xen/include/asm-arm
first-pass
approach to get LSE atomics support merged into Xen would be greatly
appreciated.
Thanks!
Ash.
[1]
https://lore.kernel.org/xen-devel/13baac40-8b10-0def-4e44-0d8f655fc...@xen.org/
[2] https://xenbits.xen.org/xsa/advisory-295.txt
Ash Wilding (6):
xen/arm: Support detection of CP
Hi,
>> I think the best compromise is still to use an ACPI string to detect
>> the platform. For instance, would it be possible to use the OEMID
>> fields in RSDT, XSDT, FADT? Possibly even a combination of them?
>>
>> Another option might be to get the platform name from UEFI somehow.
>
> I
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).
Hi,
> 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.
33 matches
Mail list logo
