ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
heat has quit [Ping timeout: 252 seconds]
mraynal has quit [Read error: Connection reset by peer]
mraynal has joined #armlinux
Peng_Fan has joined #armlinux
jclsn has quit [Ping timeout: 246 seconds]
jclsn has joined #armlinux
rvalue has quit [Ping timeout: 265 seconds]
rvalue has joined #armlinux
lain6141 has quit [Read error: Connection reset by peer]
lain6141 has joined #armlinux
rvalue has quit [Ping timeout: 248 seconds]
Lucanis has joined #armlinux
BiteriaFedoral has joined #armlinux
rvalue has joined #armlinux
BiteriaFedoral has quit [Changing host]
BiteriaFedoral has joined #armlinux
nsaenz has joined #armlinux
nsaenz has quit [Ping timeout: 276 seconds]
SystemError has quit [Remote host closed the connection]
mvaittin has joined #armlinux
BiteriaFedoral has quit [Quit: Client closed]
cbeznea has joined #armlinux
luispm has joined #armlinux
monstr has joined #armlinux
gclement has joined #armlinux
frieder has joined #armlinux
cbeznea_ has joined #armlinux
markussp0 has joined #armlinux
ex--parrot has joined #armlinux
ex-parrot has quit [Ping timeout: 246 seconds]
sally has quit [Read error: Connection reset by peer]
markussp has quit [Ping timeout: 246 seconds]
frieder has quit [Ping timeout: 246 seconds]
cbeznea has quit [Ping timeout: 246 seconds]
benh has quit [Ping timeout: 246 seconds]
sihloo has quit [Ping timeout: 246 seconds]
jwerner has quit [Ping timeout: 246 seconds]
markussp0 is now known as markussp
sihloo_ has joined #armlinux
jwerner has joined #armlinux
frieder has joined #armlinux
benh has joined #armlinux
nsaenz_ has joined #armlinux
nsaenz_ has quit [Remote host closed the connection]
nsaenz has joined #armlinux
Guest37 has joined #armlinux
Guest37 has quit [Write error: Broken pipe]
rockosov has joined #armlinux
SystemError has joined #armlinux
headless has joined #armlinux
heat has joined #armlinux
apritzel has joined #armlinux
<ajb-linaro>
arnd do you have an opinion on Arm growing in-kernel support for fixing up misaligned accesses? (c.f. 20240827130829.43632-1-alex.bennee@linaro.org)
<HdkR>
^ I also have a need for kernel fixing unaligned atomics :)
<ajb-linaro>
HdkR surely unaligned atomics is just a violation of the architecture?
<HdkR>
Indeed, but I do have a need for the kernel to handle it for x86 emulation
<HdkR>
split-lock emulation can't occur safely without kernel intervention due to a mutex needing to be held between processes
<ajb-linaro>
HdkR isn't that a userspace problem (QEMU does indeed do this)
<HdkR>
split-locks move it outside of userspace scope sadly
* ajb-linaro
is unfamiliar with split-locks
<HdkR>
It could theoretically be emulated in userspace if TME was supported. Since commits could see the tear across a cacheline or 16B granule, but that's not going to happen anytime soon
<ajb-linaro>
I thought the kernel only got involved to allow things to sleep until the lock was released
<HdkR>
Yea, that occurs in x86 when the detection is enabled on Intel or Zen5 platforms. Either forcibly put the thread to sleep, or log plus let it pass through
<HdkR>
To emulate the split-lock properly on ARM, the kernel needs to catch the SIGBUS, lock a global mutex, emulate the unaligned atomic, then unlock the mutex.
<HdkR>
qemu-user-static can only do this in-process, otherwise a global lock between all qemu-user-static instances with shared memory can hang if a process gets killed at a bad time
<ajb-linaro>
Much as it would be nice to get extra help from the kernel for QEMU I suspect this may run into more objections (we still haven't got an ioctl to prevent inode clashes when emulating 32 bit systems on 64 bit hosts)
<HdkR>
That would be nice to get fixed as well
<HdkR>
Also need to get TPIDRRO_EL0 wired up for Wine
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
prabhakalad has quit [Remote host closed the connection]
prabhakalad has joined #armlinux
headless has quit [Quit: Konversation terminated!]
lain6141 has quit [Read error: Connection reset by peer]
lain6141 has joined #armlinux
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #armlinux
iivanov_ has joined #armlinux
iivanov has quit [Ping timeout: 252 seconds]
luispm has quit [Ping timeout: 248 seconds]
amitk_ has joined #armlinux
amitk has quit [Ping timeout: 276 seconds]
fvincenzo has joined #armlinux
fvincenzo has quit [Quit: leaving]
fvincenzo has joined #armlinux
fvincenzo has quit [Client Quit]
luispm has joined #armlinux
fvincenzo has joined #armlinux
fvincenzo has quit [Client Quit]
<arnd>
HdkR: we probably wouldn't just outright emulate split locks for normal processes in the kernel, but having some type of user interface to ask for an atomic operation would solve your problem, right?
<arnd>
I wonder if that could be done either inside of drivers/misc/ntsync.c, or in another driver with a similar user facing API
<arnd>
ajb-linaro: I don't understand your series, what exactly is the hardware bug it is working around?
<arnd>
are write-combining and write-through cached mappings to memory areas broken, or something else?
fvincenzo has joined #armlinux
fvincenzo has quit [Client Quit]
fvincenzo has joined #armlinux
fvincenzo has quit [Client Quit]
fvincenzo has joined #armlinux
fvincenzo has quit [Client Quit]
fvincenzo has joined #armlinux
<ardb>
that looks similar to the PCIe interconnect bug we had on SynQuacer
<ardb>
ajb-linaro: unaligned access to device memory fault for a reason, so papering over that is not an acceptable solution
<ajb-linaro>
ardb arnd: its a workaround for a PCI bug - the GPU card memory is mapped as device memory and then non-aligned accesses fixed up in the handler
<ardb>
i understand that
<ardb>
as i said, we had the same bug on SynQuacer, hence the patched nouveau driver
<ajb-linaro>
I think without it you end up with silently corrupted memory being written into the GPU ram
<ardb>
well, not the same bug, most likely, but one that needed a similar workaround
iivanov_ has quit [Remote host closed the connection]
iivanov has joined #armlinux
<ajb-linaro>
I never got the nouveau driver to work properly on the SQ - and of course using EL2 to work around > 32 bit accesses meant no virtualisation
<ardb>
yeah the GPU userland uses VRAM as normal memory, including DC ZVA and arbitrary alignment
<ardb>
ajb-linaro: it worked with the shipped GPU card, but for you'd need different hacks for different NV generations
<ajb-linaro>
anyway I understand if it can never be merged - it will be another in a long line of Arm PCI implementations that are trash
<ardb>
and even that never worked properly, just well enough to run an accelerated desktop but no video decoding acceleration etc
<ardb>
precisely
<ardb>
will we ever learn
fvincenzo has quit [Quit: leaving]
<ardb>
AMD Seattle worked fine though - it is just the Synopsys and Cadence IP that is crap
fvincenzo has joined #armlinux
<ajb-linaro>
anyway if you can comment on the thread then the patches can just live in the downstreams. I guess this is different to the userspace unaligned fixups that arm32 does?
<ardb>
ajb-linaro: yeah completely different
<ardb>
that should never have been merged, but it increased compat with x86 only user space of the era
<HdkR>
arnd: Yea, being able to ask for atomic emulation wuold solve my problem, and also let me resolve it if/when there is TME hardware on the market
<HdkR>
er, would let me stop asking for it and resolve in userspace if/when TME hardware is on the market*
<ardb>
don't hold your breath on that one
psydroid2 has joined #armlinux
<HdkR>
I'm not, that's why I'm wanting kernel support :P
<ardb>
atomic emulation as in stopping all CPUs and all other masters?
tom5760 has quit [Remote host closed the connection]
lane has quit [Remote host closed the connection]
bryanb has quit [Remote host closed the connection]
d4ve has quit [Remote host closed the connection]
sfo has quit [Remote host closed the connection]
tleb has quit [Remote host closed the connection]
lane has joined #armlinux
tleb has joined #armlinux
bryanb has joined #armlinux
sfo has joined #armlinux
tom5760 has joined #armlinux
d4ve has joined #armlinux
tiagom has joined #armlinux
<HdkR>
uh, unaligned atomic memory operations that are causing the split locks (and cross 16-byte granule on LSE2 hardware)
fvincenzo has quit [Quit: leaving]
fvincenzo has joined #armlinux
vingu has quit [Quit: Leaving.]
vingu has joined #armlinux
vingu has quit [Client Quit]
vingu has joined #armlinux
fvincenzo has quit [Ping timeout: 246 seconds]
mvaittin has quit [Ping timeout: 248 seconds]
fvincenzo has joined #armlinux
fvincenzo has quit [Ping timeout: 246 seconds]
lain6141 has quit [Read error: Connection reset by peer]
lain6141 has joined #armlinux
HerbY_NL has joined #armlinux
apritzel has quit [Quit: Leaving]
HerbY_NL has quit [Client Quit]
mrkajetanp has joined #armlinux
gclement has quit [Ping timeout: 246 seconds]
monstr has quit [Remote host closed the connection]
headless has joined #armlinux
Clem has joined #armlinux
mvaittin has joined #armlinux
luispm has quit [Quit: Leaving]
mvaittin has quit [Ping timeout: 248 seconds]
frieder has quit [Remote host closed the connection]
fvincenzo has joined #armlinux
fvincenzo has quit [Client Quit]
<arnd>
ajb-linaro: so the original problem is that unaligned access to memory BARs on this controller silently corrupt data, so using 'device' access is a way of forcing them to trap rather than a hardware requirement itself?
<arnd>
And this only affects user applications that rely on undefined behavior, since the aarch64 ABI requires struct members to be naturally aligned, right?
sudeepholla_ has joined #armlinux
prabhakalad has quit [Ping timeout: 244 seconds]
sudeepholla_ has quit [Ping timeout: 248 seconds]
<ardb>
arnd: the cortex-strings library uses overlapping, misaligned loads and stores to implement memset and memcpy efficiently for inputs that are not a multiple of 16 bytes
sudeepholla_ has joined #armlinux
<ardb>
and DC ZVA will fault on device memory even if it is correctly aligned
<ardb>
so no ABI violation is necessarily implied here
mrkajetanp has quit [Ping timeout: 248 seconds]
<ajb-linaro>
arnd yes as far as I understand it
<ajb-linaro>
arnd does the ABI extend to the structure of GPU command buffers and textures?
sudeepholla_ has quit [Remote host closed the connection]
sudeepholla_ has joined #armlinux
siak has joined #armlinux
sudeepholla_ has quit [Ping timeout: 252 seconds]
sudeepholla_ has joined #armlinux
nsaenz has quit [Remote host closed the connection]
SystemError has quit [Remote host closed the connection]
SystemError has joined #armlinux
HerbY_NL has joined #armlinux
HerbY_NL has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
tiagom has quit [Ping timeout: 252 seconds]
lain6141 has quit [Read error: Connection reset by peer]
lain6141 has joined #armlinux
lain6141 has quit [Changing host]
lain6141 has joined #armlinux
tiagom has joined #armlinux
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #armlinux
<arnd>
ajb-linaro: the ABI would be for any code written in C or using compatible calling conventions. There are probably too many other things that can happen in the end.
<arnd>
I think for the stringops there could be a platform specific workaround, since there are already microarchitecture based optimizations for memcpy() and memset() on other CPUs.
<arnd>
gcc will also create intentionally misaligned accesses when it knows it's benefitial on that CPU. E.g. when you assign the second and third u16 member in a struct, it may choose to use a 32-bit store. The ABI just requires that each member by itself is aligned
prabhakalad has joined #armlinux
cbeznea_ has quit [Ping timeout: 252 seconds]
headless has quit [Quit: Konversation terminated!]