11:24 <mraynal> robher: Hello o/ I have the feeling that you missed my questions from 1 month ago and 11 days ago on the "[PATCH v4 2/3] spi: dt-bindings: Describe stacked/parallel memories modes" thread, sorry to bother you if this is not the case, I just want to get some feedback, in particular if you are looking for a solution on the tooling side

13:54 <milkylainen> arnd: I reactivated the long lost oldconfig whine regarding nonexistent symbols (lost since 2008).

13:54 <milkylainen> $ make ARCH=arm64 defconfig

13:54 <milkylainen> *** Default configuration is based on 'defconfig'

13:54 <milkylainen> arch/arm64/configs/defconfig:543:warning: trying to assign nonexistent symbol POWER_AVS

13:55 <milkylainen> OMAP renamed stuff?

14:16 <robher> mraynal: Thanks, I did miss it. TLDR: Yes, I think you should use <uint64 uint64> form. I'll explain in the mail in a bit.

14:51 <geertu> mraynal: robher: Perhaps some #foo-cells property instead of uint64? Not all FLASHes go beyond 4 GiB

15:30 <robher> geertu: probably not cost effective to stack small flash chips...

15:32 <robher> And #foo-cells is generally for provider/consumer cases (for reg, the bus is the provider).

15:32 <geertu> robher: and parallel? dual-QSPI can be faster

15:36 <robher> geert: Not enough cases to justify the complexities of variable sized properties IMO. Every case requires code to parse. If we want more of that, figure out how to to add type information to dtb format...

16:06 <ardb> maz: i am seeing this on tx2 now

16:06 <ardb> [ 6.741572] kvm [1]: GICv3 with locally generated SEI

16:06 <ardb> [ 6.741573] kvm [1]: GICv3 sysreg trapping enabled ([G0G1D], reduced performance)

16:06 <ardb> that was the M1 workaround, no?

16:14 <alexels> ardb: Yes, if I remember correctly, it was done because it was possible on the M1 to generate an SError which was taken by the host instead of the guest.

16:14 <alexels> ardb: it was possible for the guest to generate the SError, I mean

16:18 <ardb> alexels: i remember that, yes

16:18 <ardb> but i wonder whether TX2 needs this workaround as well

16:22 <alexels> the rationale was that the locally generated SEI was deprecated and underspecified in the GIC spec

16:23 <alexels> and it was safer to do the emulation for all hardware that implemented the feature

16:26 <j`ey> maybe Im misunderstanding 0924729b21bffdd0e13f29ea6256d299fc807cff but isnt it just 'downgrading' the emulation to only trap DIR if the GIC supports it. so if TX2 supports that, it actually got less emulation, not more?

16:29 <ardb> beforehand, it did not trap anything at all

16:47 <mraynal> robher: great, thanks!

17:02 <alexels> ardb: if you think that TX2 has implemented SEIS in such a way that a guest cannot trigger SErrors in the host or do other shenanigans, you can try to convince maz to whitelist it

17:04 <maz> ardb: oh gawd...

17:06 <maz> ardb: can you check what happens when you run a version of EFI that has this stupid EOI loop with the trapping disabled?

17:07 <maz> ardb: if the host doesn't explode, then I'm perfectly happy to make this M1 specific instead of imposing it on TX2.

17:13 <maz> j`ey: TX2 never needed any emulation so far. it is the good old TX1 (aka Thunder) that needs it (and plenty of other things)

17:15 <j`ey> maz: yeah I mesed that up, I went and looked into CAVIUM_ERRATUM_30115 and saw it was for TX1

17:17 <ardb> maz: i've never seen any issue running EFI in a guest on TX2

17:17 <ardb> and i do so most days of the week :-)

17:19 <maz> ardb: OK, so we can safely assume that whatever SError this implementation is threatening us of, it is only for show.

17:19 <ardb> and it only traps DIR, i suppose, so it probably makes little difference in practice

17:19 <maz> nah, this will trap everything but PMR and BPR.

17:20 <ardb> right

17:20 <maz> so you'd really see it in benchmarks (hackbench, for example).

17:20 <maz> I'll have something shortly.

17:20 <maz> (just make it fruit specific)

17:30 <ardb> maz: i see no difference with hackbench in a guest between v5.15 and v5.16

17:31 <ardb> should i test with pseudo_nmi=1 instead?

17:34 <maz> nah, it won't make much difference. pNMI=1 hammers PMR, which isn't trapped anyway.

17:35 <maz> I'm not overly surprised it doesn't show up. the exit path is pretty short, and it is mostly sysreg accesses which are pretty fast.