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
Pali has quit [Ping timeout: 265 seconds]
chip_x has quit [Remote host closed the connection]
mcoquelin has quit [Remote host closed the connection]
matthias_bgg has joined #armlinux
mcoquelin has joined #armlinux
Pali has joined #armlinux
* ajb-linaro
tries to wrap his head around what FEAT_LSE2 means practically - is it just you can't get memory tearing or that sequencing is enforced
chipxxx has joined #armlinux
chipxxx has quit [Remote host closed the connection]
chipxxx has joined #armlinux
<viorel_suman>
quit
viorel_suman has quit [Quit: WeeChat 3.5]
viorel_suman has joined #armlinux
Lucanis0 has joined #armlinux
iivanov has left #armlinux [Leaving...]
iivanov has joined #armlinux
Lucanis has quit [Ping timeout: 260 seconds]
plappermaul has quit [Ping timeout: 252 seconds]
<robmur01>
ajb-linaro: everything that single-copy-atomicity means in general. Plus you get to do atomic/exclusive instructions on unaligned addresses too!
mcoquelin has quit [Remote host closed the connection]
<ajb-linaro>
robmur01: the context here is for QEMU emulation. For explicit atomic operations I think we are good because we translate to host atomic operations which at the worst case just fall back to halting other cores while it does the transaction
<ajb-linaro>
but for normal memory operations we need to work out if the host gives the same guarantees for single-copy-atomicity
<robmur01>
ah, I see; no, if the host doesn't have FEAT_LSE2 itself then you won't be able to emulate it
Amit_T has joined #armlinux
<robmur01>
(within reason - it's probably technically possible as an academic exercise if you emulate the whole memory system)
<ajb-linaro>
well everything can be emulated - it's just a matter of how expensive you want that to be. For example we could just disable MTTCG for FEAT_LSE2 and then everything will be coherent
<robmur01>
admittedly I don't know what kind of memory model TCG has internally, but I'd imagine you'd have to ensure synchronisation of *all* load and store operations rather than just translate them straight to whatever native loads/stores might do, which I can easily see being impractically slow
headless has quit [Quit: Konversation terminated!]
<geertu>
ardb: "ARM: make ARCH_MULTIPLATFORM user-visible" broke half of the boards in my setup, as I need CMDLINE_FORCE for anything that boots with appended DTB, or has an old bootloader that doesn't know how to update chosen/bootargs
<geertu>
oops, bitten by auto-complete again
<geertu>
arnd: ^
<geertu>
Will look into requird changes after lunch...
<arnd>
geertu: I agree that sucks. It still seems like the right thing to do (along with changing your config to either disable ARCH_MULTIPLATFORM=n, CMDLINE_EXTEND=y or ARM_ATAG_DTB_COMPAT=y), so I'm not sure
<arnd>
let's see if others have an opinion, if you think we need more time to decide, we can always revert this dependency and have a proper discussion on the list about it.
<arnd>
geertu: I too a second look and now I no longer see what is actually going on. What what I can tell, the entire CONFIG_CMDLINE parsing should only be used if you are actually booting with ATAGS, not a DTB (appended or otherwise)
<arnd>
Could it be that instead the drivers/staging/board/ support broke, rather than the command line handling?
mcoquelin has joined #armlinux
mcoquelin has quit [Ping timeout: 268 seconds]
<ajb-linaro>
robmur01: we try to be as strong as the guest with extra barriers where required... practically this means ARM-on-x86 is generally fine
<ajb-linaro>
robmur01: if the backend is weaker we default to a single-threaded emulation
mcoquelin has joined #armlinux
<geertu>
arnd: I only use drivers/staging/board/ for the display on r8a7740/armadillo. But the change broke all my SH/R-Mobile and RZ/A boards.
<arnd>
geertu: does it work if you revert the 'depends on !ARCH_MULTIPLATFORM' on the CMDLINE_FORCE?
<geertu>
arnd: Already trung that...
<geertu>
arnd: Works on the first board I tried. I'll reply to the patch email...
<arnd>
geertu: to you have CONFIG_ATAGS set?
<arnd>
I still fail to see why how the forced command line actually gets used in a DT boot
<geertu>
arnd: Yes, and CONFIG_ATAGS_PROC, too.
<geertu>
IIRC, both are needed for kexec on arm
<geertu>
Hmm, /proc/atags does not exist, so perhaps I'm misremembering
<geertu>
arnd: the cmdline options are a choice, either CMDLINE_FROM_BOOTLOADER, CMDLINE_EXTEND, or CMDLINE_FORCE
<geertu>
oh, now I understand. I needed CONFIG_ATAGS to actually see that choice
<arnd>
geertu: what puzzles me is that the only reference to the symbols is in arch/arm/kernel/atags_parse.c, and nothing in that file should actually get called in a DT boot
<arnd>
I'm obviously missing something here
<geertu>
arnd: yes, drivers/of/fdt.c
<geertu>
arnd: arm64 has the same choice (albeit without CMDLINE_EXTEND), but not depending on ATAGS
<geertu>
similar for loongarch, microblaze, nios2, powerpc, and riscv
<arnd>
ah, that makes sense. It looked like 34b82026a507 ("fdt: fix extend of cmd line") started the current behavior, though bd51e2f59558 ("ARM: 7506/1: allow for ATAGS to be configured out when DT support is selected") tried to prevent it
<arnd>
geertu: can you send the one-line revert with a short summary to soc@kernel.org so I can apply it?
<geertu>
arnd: OK, will do.
<arnd>
we should probably also drop the 'depends on ATAGS' on the option, feel free to combine that or send another patch for this,
<geertu>
arnd: OK, will do.
<arnd>
thanks!
chip_x has joined #armlinux
chipxxx has quit [Ping timeout: 265 seconds]
<geertu>
arnd: hasn't the time arrived to not default ATAGS to y?
<arnd>
geertu: I was taking it one step at a time. 96a4ce30c27e ("ARM: add ATAGS dependencies to non-DT platforms") just made the option more visible by letting it get turned off before picking platforms
<arnd>
I'm in the middle of removing the boards marked as UNUSED_BOARD_FILES
<arnd>
there is one armv6 board (crag6410) and two armv7 boards left (cma510 and dove-db), so we could make it default=n for all v6/v7 configs after the rest is gone, or go the next step as you say and have it default =n
amitk has quit [Ping timeout: 246 seconds]
headless has quit [Quit: Konversation terminated!]
<Pali>
arnd: IIRC Dove DB has also DT support. So if you concat non-board-zImage+DTB, you could boot it also from non-DT bootloader, no?
<rfs613>
arnd: just fyi, for netwinder at least, the bootloader only passes ATAGS, and knows nothing about devicetree. A kernel with appended devicetree works, of course. Not sure if anyone is actually using their netwinder anymore though.
<arnd>
Pali: rmk has a cubox that he is still using with an out of tree board file, and he wants to keep standalone dove support because the DT version does not support all the functionality, so I left it there
<Pali>
Ah, OK. I did not know that DT version does not have all functionality.
<arnd>
I don't remember what exactly was missing, but it's been this way for a long time
<rfs613>
arnd: and following up on yesterdays dm-verity issue, I noticed it creates its own workqueue, with max_active=num_online_cpus()
<rfs613>
changing that to max_active=1, or better, switching to alloc_ordered_workqueue(), seems to solve the issue of concurrent init/update/final requests being made to crypto API.
<rfs613>
at this point I'm thinking a mail to dm-devel list is probably a good idea...
<arnd>
ardb: ^
<ardb>
arnd: thanks :-)
<rfs613>
right, thanks!
<ardb>
rfs613: yeah and cc eric biggers as well
<arnd>
I wonder if I should set up an automated highlight for "ardb"
<ardb>
i wonder if i should change my nick to ardb_not_arnd :-)
<rfs613>
arnd: funny thing is that I see how often the autocomplete messes up, so I trained myself to check carefully before sending... and yet it still happens...
<ardb>
rfs613: i'm still puzzled why the same io object (and hence the same hash desc) ends up being processed on two CPUs at once
torez has joined #armlinux
<ardb>
AIUI, there is a 1:1 mapping with BIOs and verifying those more than once seems rather pointless to me
<rfs613>
ardb: i don't think it is verifying the same object on more than one CPU. Rather it is just queuing successive operations... and if you have multiple CPUs, it is possible for the workqueue to run those operations in parallel on multipel CPUs.
<ardb>
yes but each operation should operate on a different dm_verity_io object
<rfs613>
ardb: the surprising part (for me) is that nobody else seems to have hit this... the code has been around for a long time.
<ardb>
well, you are using asynchronous crypto
<ardb>
so the crypto_wait_req() call take *much* longer
<ardb>
ah hold on
<ardb>
i wonder how much the latency is going to affect your max performance in this case
<rfs613>
ardb: so the dm_verity_io object is coming from io = dm_per_bio_data(bio, ti->per_io_data_size);
<rfs613>
which seems to be within the bio structure
<ardb>
that would mean that CPUs operating on the same hash descriptor are operating on the same bio
<rfs613>
i guess I could put some printk to try and confirm that
<rfs613>
i'm not convinced the bio are the same. They could differ, and it would still cause a problem if the .init/update/final sequence is interrupted by another call to init.
<ardb>
that would only matter if the operate on the same ahash_request
monstr has quit [Remote host closed the connection]
chip_x has quit [Read error: Connection reset by peer]
mcoquelin has quit [Remote host closed the connection]
guillaume_g has quit [Quit: Konversation terminated!]