06:21 flowejam: Hey all, I'm quite new to kernel dev, with a handful of small patches (in C). I guess I'm looking for an excuse to learn Rust, and thought of contributing to the Rust for linux project after going through the Rust book. Would it be better just to stay focused on submitting patches in C though? I guess since I'm neither experienced in kernel dev nor in Rust, I'm wondering if this project is mainly just for very experienced ker
06:24 dolphin: flowejam: It of course depends on what your end goal is, but the Rust in kernel is not standard Rust in many ways
06:24 dolphin: if you want to be effective in fixing bugs or implementing features, may be good to get familiar with the C side of things and work on the Rust skills orthogonally
07:42 mripard: mlankhorst: will you send the drm-misc-next PR ?
08:23 fomys: emersion: VKMS devices will all have a different name (folder name in configFS) see make_device_group / https://lore.kernel.org/all/20250901122541.9983-3-jose.exposito89@gmail.com/ + https://elixir.bootlin.com/linux/v6.17.1/source/drivers/gpu/drm/vkms/vkms_drv.c#L156-L157
08:24 fomys: The only one named "vkms" is the default device (modprobe vkms create_default_dev=1)
08:24 emersion: oh you're in here, nice
08:24 emersion: cool!
08:24 emersion: so yeah it's more of a businfo than a deviceinfo
08:31 fomys: Yes, I'm here, I just need to remember to open my IRC client x)
13:32 gfxstrand: cwabbott: It would be lovely if I could get an ack on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37803 at some point
13:33 gfxstrand: I can just land the first patch without the turnip one but that seems kinda pointless
15:03 alyssa: gfxstrand: will my ack count
15:03 alyssa: oh danylo did it
17:45 gfxstrand: robclark, bbrezillon: I think I'm going to drop util_l1_cacheline_size() in favor of just making util_cpu_caps.cacheline correct on arm
17:46 robclark: seems reasonable
17:50 gfxstrand: I just need to double-check that my 32-bit code works.
18:34 HdkR: gfxstrand: How does this work on hardware with different d-cacheline size depending on core?
18:34 gfxstrand: HdkR: Good question!
18:34 gfxstrand: Presumably we have to flush at the minimum size because we don't know what core we're on but assume granularity of the higher size.
18:34 gfxstrand: Ugh...
18:35 HdkR: :>
18:35 gfxstrand: Probably want DminLine for flushes but CWG for granularity
18:37 gfxstrand: Wait... Is CTR per-core?
18:38 HdkR: yeppers
18:38 gfxstrand: Big.little is evil
18:39 HdkR: It's almost like the kernel should provide some min/max values for all cores in the system or something.
18:39 gfxstrand: Would be nice...
18:40 gfxstrand: There's SV_LEVEL1_DCACHE_LINESIZE but glibc just implements that by grabbing the bit from CTR_EL0 on whatever core you're on
18:40 HdkR: It's a good joke that one
18:42 gfxstrand: Are people actually making chips where those two are different?
18:42 HdkR: Of course!
18:42 vsyrjala: maybe the instruction should just take start+end and dtrt
18:43 HdkR: A common config is 64-byte on the big core, and 32-byte on the small cores.
18:45 gfxstrand: https://www.mono-project.com/news/2016/09/12/arm64-icache/
18:45 HdkR: Samsung infamously shipped a big.little configuration where I think it was 128B and 64B and failed to broadcast all cache clears across the boundary resulting in fun interleaved non-cleared lines
18:45 HdkR: Oh hey, there it is :P
18:47 gfxstrand: https://github.com/mono/mono/pull/3549/files
18:47 gfxstrand: But even that's not correct because the process can get re-scheduled min-clear
18:48 HdkR: Yea, definitely a bug in that
18:48 HdkR: You want to start from the minimum and work up instead
18:48 gfxstrand: But you don't know the minimum
18:48 HdkR: Well, minimum is 4 bytes :P
18:49 gfxstrand: Sure, but you don't want to flush every dword
18:49 gfxstrand: You want to know the actual minimum (64B in this case)
18:49 gfxstrand: But unless you can ask the kernel to bounce you around between CPUs, there's no way to get that
18:49 HdkR: yep
18:50 HdkR: and the sysfs cache topology information doesn't store any of that either, so you can't query through there
18:50 gfxstrand: I can walk /sys/devices/system/cpu/cpu*/cache/index0/coherency_line_size
18:51 HdkR: If it exists
18:51 gfxstrand: yes
18:51 HdkR: It's not guaranteed~
18:51 gfxstrand: I assume it doesn't on Android
18:51 HdkR: It doesn't exist on my Radxa with Linux
18:51 gfxstrand: entertaining
18:52 HdkR:stacks the pile of garbage higher
18:52 gfxstrand: It's almost like we need an actual system call for this
18:53 HdkR: It does exist on my other device although. So it was either added between 6.11 and 6.16, or Debian kernel is missing something...Or Maybe just missing on ACPI platforms?
18:53 HdkR: It's a cluster.
18:54 gfxstrand: I don't have it on my TX1
18:54 gfxstrand: But I have it on my mediatech chromebook
18:54 HdkR: :chefs_kiss:
18:54 gfxstrand: 6.15 vs. 6.12
18:54 vsyrjala: parse /proc/cpuinfo?
18:54 HdkR: cpuinfo doesn't have it
18:54 gfxstrand: Doesn't have it
18:55 HdkR: ARM Kernel maintainers have claimed that /proc/cpuinfo is immutable and no new information can be added to it.
18:55 gfxstrand: Do I at least have this in kernel data structures?
18:55 gfxstrand: Because I'm happy to add a getparam and a drm helper
18:55 gfxstrand: Ugh... No I'm not happy to do that
18:55 alyssa: gfxstrand: do you need a hug
18:55 gfxstrand: I want this in common code, damnit!
18:56 HdkR: Welcome to my garbage pile, enjoy the mess of ARM.
18:56 gfxstrand: I was already hating Arm this week.
18:56 gfxstrand: daniels owes me soooo many beers...
18:57 HdkR: Last time I asked about exposing information like this, I got told it could be a security implication so I walked out of the channel.
18:57 alyssa: *checks train schedules*
18:57 gfxstrand: Uh.... And not being able to proper cache maintenance isn't?
18:57 HdkR: :)
18:57 gfxstrand: WebGPU attackers are gonna have a field day
18:57 Sachiel: just remove all the caches
18:58 gfxstrand: We already tried that. Sucks for perf. Now we're trying to turn the caches back on.
18:58 gfxstrand: You know what's really bad for security? Big.little.
18:58 gfxstrand: Sorry. big.LITTLE
18:58 gfxstrand: Because that makes sense
18:58 HdkR: Ultra.Pro.Premium.Nano now
18:59 gfxstrand: I kinda want to steal the Mono implementation and call it a day
18:59 gfxstrand: Reading a register at the start of the loop shouldn't cost that much
19:00 gfxstrand: And we just pray no one moves us to a different core
19:00 gfxstrand: mid-loop
19:01 gfxstrand: alyssa: Looks like it's too late to catch a train yet today
19:01 HdkR: You know the kernel is going to hit at a bad time and then you'll have spurious corruption.
19:01 HdkR: Which'll be even harder to track down
19:03 gfxstrand: Then we'll write the minimum cache size to a file and and it'll work when they restart their app
19:03 HdkR: :D
19:03 gfxstrand: In any case, this has answered one very important question: I'm going to have separate files per-arch.
19:04 gfxstrand: But ugh... So how do I provide the Vulkan query
19:04 alyssa: gfxstrand: Yeah... earliest I could hug you is 24h from now sadly
19:05 alyssa: uh wait that's a lie flights exist
19:05 gfxstrand: :giggle:
19:05 f_: no they don't, not in this world
19:05 f_: :P
19:05 alyssa: that's the spirit
19:05 f_: it's the intention that counts, heh
19:06 gfxstrand: Only fights. We're all out of flights.
19:06 f_: I believe I could fly
19:06 f_: ahem, sorry
19:06 f_: f_ly
19:07 gfxstrand: Yeah, I need to know min/max
19:07 gfxstrand: There's no way I can implement Vulkan correctly otherwise
19:08 gfxstrand: For nouveau, we're fortunate to have a pretty fixed set of CPUs to work with.
19:08 gfxstrand: I'm a lot more worried about Mali
19:08 gfxstrand: Or IMG
19:09 gfxstrand: I suppose I can fire off a bunch of threads and hope at least one hits each CPU core
19:09 HdkR: ooo, actually does the kernel emulate CTL_EL0 with differing features these days?
19:10 HdkR: hmmm
19:10 HdkR: CTR_EL0*
19:13 gfxstrand: Yeah, the kernel does have a trap for CTR_EL0
19:14 HdkR: Looking at cpufeature.c it looks like it does generate the minimum for L1I and L1D even
19:14 HdkR: So you might actually be safe to read it once.
19:14 gfxstrand: But I need both min and max
19:15 HdkR: Welp
19:16 gfxstrand: It's possible I can use CWG
19:16 gfxstrand: But I don't know
19:16 HdkR:checks was CWG affects
19:17 HdkR: That /does/ hit the FTR_HIGHER_OR_ZERO_SAFE path so maybe!
19:19 gfxstrand: HdkR: I hope you realize that you've signed up to review this code. :P
19:20 HdkR: I mean, what other madhatter would there be to look at it? :P
19:20 gfxstrand: Me, apparently. (-:
19:22 HdkR: I do wonder when that emulation got dropped in to the kernel though. Maybe it's been there ever since Samsung messed it up and I just didn't remember it.
21:33 gfxstrand: Okay, I think it's about as good as it's going to get.