<daniels>
(relatedly, it would be great if that could share a kernel tree with the rest of everyone else, and also if b2c had the same container that executes in gitlab-ci rather than something external?)
<mupuf>
We did not. It's a new change the kernel, it's a zink change that exposed a kernel bug
thenemesis has joined #dri-devel
<mupuf>
We are using the same container as gitlab-ci , unless you are talking about the trigger container?
<mupuf>
As for sharing the kernel, would it be OK if others stopped using modules?
Zopolis4 has quit [Quit: Connection closed for inactivity]
thenemesis has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
<DavidHeidelberg[m]>
mupuf: about sharing modules outside of the rootfs.. we though about it
<DavidHeidelberg[m]>
I personally think it's good idea, if we consider integration with KernelCI, so we could "replace kernel ondemand"
<mupuf>
100%
<mupuf>
Yeah, I like having the kernel and user space separated
<mupuf>
I added support for modules in b2c last week
<mupuf>
I ended up with the following interface: a kernel file (vmlinuz), a modules.cpio.xz, and a firmware.cpio.xz
<mupuf>
This way, bootloaders can download all the initrds and the kernel will extract them all
<mupuf>
(In EFI mode)
<mupuf>
For legacy mode, the bootloader usually decompresses them, concatenates them, then start the kernel
<mupuf>
And for rootfs operations, extracting a tarball or a cpio archive is similar-enough
<mupuf>
B2C's makefile creates the cpio archives for us (it finds the firmware needed for all the modules you compiled)
<mupuf>
DavidHeidelberg[m]: how does that sound like?
thenemesis has joined #dri-devel
<alyssa>
Lovely, nir_reg rework is crashing on armhf but not arm64..
junaid has quit [Remote host closed the connection]
<DavidHeidelberg[m]>
mupuf: "me likey". I guess first step is distribute modules separately for the start.
junaid has joined #dri-devel
smiles_1111 has quit [Read error: Connection reset by peer]
smiles_1111 has joined #dri-devel
thenemesis has quit [Ping timeout: 480 seconds]
smilessh has joined #dri-devel
smiles_1111 has quit [Read error: Connection reset by peer]
thenemesis has joined #dri-devel
<daniels>
mupuf: btw I forgot to reply the other week when you were talking about b2c doing NFS, but it still really hurts ...
<mupuf>
Loool, isn't that what you use?
<daniels>
I mean
<daniels>
in this scheme, you've got the device pulling the container image over the network, writing it to the nfsroot over the network, reading it back over the network to decompress it, writing the uncompressed image back over the network, then executing from there
<daniels>
in our scheme, the controller (which has substantially more I/O capacity than a low-end Arm board) decompresses the rootfs to local storage, then the device just executes straight out of that nfsroot
<mupuf>
Yeah, but you know the extraction would happen only once, right?
<mupuf>
The first time you boot this container, following times would be cached
<daniels>
assuming that the storage is completely persistent, which for us it isn't because we have KCI and CrOS testing and $customer_product testing, none of which use b2c
<daniels>
so we'd have to go semi-rewrite LAVA to understand different job classes and allocate persistent storage for them
<mupuf>
Good to know
djbw has joined #dri-devel
<mupuf>
So, the NFS shares are created per job, ack
<daniels>
even so there would still be a moderate amount of pain because we typically have 15 DUTs per device type, so you get a lower hit rate, and afaict you'd still have the issue that you'd have the DUT as the one expanding the image (NFS read -> CPU decompress -> NFS write); not only does the CPU time hurt because their CPUs are fairly weak, but even when you've got 15 completely partitioned networks, the network load of doing so is
<daniels>
... not low
<Company>
quesstion: is there a good way to emulate the capabilities of old/embedded hardware with Mesa? Stuff like max texture size and shader limits and whatnot?
<daniels>
yeah, in the LAVA model we download (with two-tier local caching; one per-dispatcher i.e. shared between roughly 15 DUTs and one LAVA-global) the tarball and decompress it on the x86 dispatcher, then the LAVA device just has that as nfsroot=
<mupuf>
We pull containers through a caching proxy too
<mupuf>
But yeah, to support b2c, you would need to add per-machine NFS shares not managed by lava
<daniels>
or add support to LAVA for some kind of semi-persistent 'use this rootfs for everything Mesa on this device, and here's how to clean up after the jobs too' storage mode - but yeah, my concern is mainly the expansion being done on the DUT requiring too much load on an already-slammed network + low-end CPU
<daniels>
it's not impossible of course, just trying to share why it's seriously non-trivial
<mupuf>
And adding local storage is also not doable? Would solve your network issue
<daniels>
ehh
<mupuf>
Anyway, moving mesa to containers-only isn't blocked by using b2c in lava
<daniels>
it's doable, but the economics are poor
<daniels>
if your DUT costs $1k for the whole rig, then dropping $200 on decent NVMe isn't terrible
<mupuf>
Just means that you'll be stuck with an indirection
<daniels>
if your DUT costs $60, then pairing it with $200 NVMe is ... less obviously good
<mupuf>
(Trigger container)
<mupuf>
Lol, yeah
<daniels>
so yeah, if there's an obvious need for it then it's doable, but if the only cost is 'wtf is this rootfs upload step' then we'll just spend the $60k elsewhere
<mupuf>
Well, the cost is the gitlab-ci.yml complexity being so high that other projects need to import it
<mupuf>
That's just gonna work
<mupuf>
But, I guess there could be a gitlab to LAVA converter to hide everything
<daniels>
yeah, that's something we are working on in the background
<daniels>
we've been treating it as a nice-to-have bit of tech-debt cleanup but less urgent than ... *gestures at everything*
<mupuf>
Good :)
<mupuf>
Well, at least we agree on the goal!
<mupuf>
I guess I'll need to look at the bare metal infra next, to see how it could be simplified
<mupuf>
(To be shareable between projects)
* mupuf
's goal is to bring testing to more projects
<mupuf>
eric_engestrom: You may be interested in the above discussion
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
thenemesis_ has joined #dri-devel
thenemesis_ has quit []
thenemesis_ has joined #dri-devel
ayaka has joined #dri-devel
ayaka has quit []
ayaka has joined #dri-devel
thenemesis__ has joined #dri-devel
thenemesis has quit [Ping timeout: 480 seconds]
junaid has quit [Remote host closed the connection]
<mattst88>
one thing that might be useful is a little program that just wraps igt_drm_clients_scan and prints the current DRM clients
Kayden has quit [Quit: to JF]
Major_Biscuit has quit []
<DavidHeidelberg[m]>
mupuf: we thinking about allowing KernelCI to share pipeline (limited to LAVA, since other job does't have priorities and don't want to block pre-merge)
<DavidHeidelberg[m]>
daniels: nicely said. I think we can prepare stuff in that direction if it dowsn't ivolve too much work?
heat has joined #dri-devel
heat_ has quit [Read error: No route to host]
<daniels>
DavidHeidelberg[m]: yep, good thing to think about and work towards
alyssa has left #dri-devel [#dri-devel]
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
<mupuf>
DavidHeidelberg[m]: share pipeline?
<DavidHeidelberg[m]>
*share the jobs
<daniels>
mupuf: you've reminded me that we need to extend the LAVA structured-logging MR I pointed you to to both bm and b2c; do you/Charlie have some spare cycles for that atm?
<daniels>
(we're elbow-deep in a bunch of stuff including bifurcating LAVA to pivot from UART to SSH for control and feedback because it turns out it is possible to build a UART so unreliable it's unusable)
<mupuf>
Charlie is working on vkcts, but Eric just joined the team. Maybe he'll be up for it!
<mupuf>
Good luck with the pivot!
* mupuf
's plan for consoles is to extend netconsole to become a TTY over IP
<mupuf>
DavidHeidelberg[m]: how are you planning to share the jobs?
<DavidHeidelberg[m]>
Trigger pipeline with injected kernel and modules
<mupuf>
Oh, sounds like a great idea!
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
<mupuf>
DavidHeidelberg[m]: how is kernel ci packaging its kernel and modules?
<DemiMarie>
mupuf: please ensure that there is a layer of encryption and authentication (perhaps WireGuard?) over that!
<mupuf>
DemiMarie: over what?
<DemiMarie>
mupuf: the TTY over IP
<DemiMarie>
Because people will do things like expose a TTY on the public Internet
<mupuf>
TTL=1 to the rescue?
* mupuf
fails to see how one could get early boot messages if TLS or WG was mandated
<mupuf>
But people can be free to set things up then use the right source IP to go through a VPN
<Sachiel>
I don't know what it would be protecting either, since anyone can just go look at the jobs output on gitlab anyway
<mupuf>
I guess DemiMarie is worried about users shooting themselves in the foot by choosing to use this driver rather than SSH
<DemiMarie>
mupuf: yup
<DemiMarie>
And my thought was to require that WG is built-in (not a module) and that the secrets are available during early boot.
<mupuf>
I guess with ipv6 we could force a local-only network
<DemiMarie>
mupuf: is this read-write or output-only?
<DemiMarie>
> And my thought was to require that WG is built-in (not a module) and that the secrets are available during early boot.
<DemiMarie>
Could this work?
<mupuf>
I want it read/write
<mupuf>
In theory, yeah. In practice, could luck upstreaming that
<DemiMarie>
Why “good luck upstreaming that”?
<mupuf>
Because the TTY subsystem is already messy enough :D
<mupuf>
And people will say: this is policy, it belongs to the userspace
<DemiMarie>
To which my response would be: we need to get logs from before userspace starts, so it cannot run in userspace, and there is going to be a login prompt on it, so it must be encrypted.
<mupuf>
To which they will say: Use SSH. TTY is for debug only :D
<mupuf>
Or local-only
<DemiMarie>
And my response is that people need to be able to debug stuff they may not have a physically secure connection to.
<mupuf>
And then silence will fall :D
<DemiMarie>
The authorized public key could be provided on the kernel command line and the secret key could be specified as a TPM NVRAM index or a UEFI variable GUID.
<mupuf>
Good ideas, but why enforce that the driver uses this interface? Why not have: setup wireguard through the kernel cmdline, and setup this driver through the cmdline?
<mupuf>
Then users may shoot themselves in the foot... but don't have to
<DemiMarie>
mupuf: users _will_ shoot themselves in the foot. That is why secure by default is so important.
<mupuf>
And the wg work can be reused for other services like samba, NFS, or whatever
<DemiMarie>
Maybe guard the insecure feature by unsafe_allow_insecure_unencrypted_tty_write or similar?
<mupuf>
You are so damn right... and making a lot of sense...
<DemiMarie>
Thank you
* mupuf
used to be a security researcher, in a past life
<mupuf>
Even chatted with your CEO :d
<DemiMarie>
You are correct that having the secure connection be configured separately is a much cleaner design.
<DemiMarie>
🤣
<DemiMarie>
If you mean Marek, I think he is CTO, but that is a trivial nit.
<mupuf>
I meant Johanna
<mupuf>
Wasn't she the CEO?
<mupuf>
Anyway, the best would likely to hide this driver behind CONFIG_EXPERT
<mupuf>
And add that this is not for end users, but meant for automated farms
<DemiMarie>
Maybe? Joanna left ITL before I joined.
<DemiMarie>
Maybe hide it behind BROKEN, so that anyone who wants to use it must apply a trivial kernel patch? Or hide it behind something like INSECURE_NETWORK_TTY?
cmichael has quit [Quit: Leaving]
<mupuf>
Well, as long as it isn't accidentally shipped to users, and the doc makes it clear what the security level is (none), not sure how adding more hoops will do
* mupuf
always have to read netconsoles.txt
<mupuf>
I doubt people would remember the cmdline by heart :D
gouchi has joined #dri-devel
<mupuf>
TLS may be supported though, not sure how this works without an RTC
<mupuf>
Bed time! Thanks for the chat DemiMarie, it was a pleasure :)
<DemiMarie>
mupuf: Good night! Thanks for the chat, it was a pleasure here too.
Kayden has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
clever has quit [Ping timeout: 480 seconds]
clever has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
MrCooper has quit [Remote host closed the connection]
<mattst88>
DavidHeidelberg[m]: you've committed some radeon+VA-API+CI stuff today, so maybe you know :)
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
tobiasjakobi has joined #dri-devel
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
agd5f has quit [Read error: No route to host]
agd5f has joined #dri-devel
tobiasjakobi has quit [Ping timeout: 480 seconds]
<daniels>
mupuf: don't ever try to do anything with netconsole - it's a dead end
<daniels>
it relies on being able to push data whilst holding all the locks, which works very well for proper low-level UART, and very poorly for usbeth
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
MrCooper has quit [Remote host closed the connection]
* mareko
isn't a CTO yet
MrCooper has joined #dri-devel
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
mvlad has quit [Remote host closed the connection]
Duke`` has quit [Ping timeout: 480 seconds]
<DemiMarie>
mupuf: your best option for console output is USB debug capability, which is explicitly designed for this purpose.
tursulin has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
djbw has quit [Read error: Connection reset by peer]
djbw has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
JohnnyonF has quit [Read error: Connection reset by peer]
JohnnyonFlame has joined #dri-devel
gouchi has quit [Remote host closed the connection]
<DavidHeidelberg[m]>
mattst88: Haha, I knew I should touch it. I'll try to look in hour (away from the PC) ;)
<DavidHeidelberg[m]>
*shouldn't
<mattst88>
lol
ngcortes has joined #dri-devel
<DavidHeidelberg[m]>
look at backtrace on the phone, it seems to me to be likely nir issue, otherwise it should be catched earlier
ngcortes has quit [Ping timeout: 480 seconds]
<DavidHeidelberg[m]>
we had the vaapi testing in-place for a while I think
<daniels>
DemiMarie: eh? no-one is exposing TTYs over public IP
<daniels>
DemiMarie: please give us the respect of assuming that we've thought for more than two seconds about what we're doing
<airlied>
the fact someone can create a UART that doesn't work is still impressing me
<daniels>
airlied: me too! which is why we spent a few weeks properly bottoming it out before concluding that the hardware was actually, somehow, terminally broken
<airlied>
daniels: I'd recommend a serial over uart device, but I think those are all terminally broken as well :-P
<daniels>
... serial over uart?
<DemiMarie>
daniels: I trust that nobody here would do that. I was assuming the feature got into the mainline kernel and included in distros.
<DemiMarie>
In which case someone else might well make this mistake.
<daniels>
DemiMarie: we're not making a mainline distribution, we're making a dedicated CI system
<daniels>
there would need to be a lot of terrible decisions in the chain to Ubuntu shipping an SSH server which accepted known predefined SSH keys to log in by default; no-one here would propose him, and no-one in the chain to shipping would accept them either
<DemiMarie>
daniels: I was referring to the kernel TTY idea proposed earlier. That seemed to be essentially kernel-mode telnet to me.
<daniels>
DemiMarie: sure, but the idea that anyone who had spent multiple years making a CI system would just expose the lot over public IPs and forget that they were public, is pretty insulting tbh
<DemiMarie>
daniels: that was not my intent and I am sorry it came across that way.
<daniels>
DemiMarie: no problem; it's useful to provide insight and perspective, but just please try to remember that the people you are talking to are not idiots, and have probably thought about what they're doing for more than a few seconds, so don't need to have blisteringly obvious things explained at them
<DemiMarie>
daniels: Thank you. Would better phrasing have been something like, “If this gets upstreamed and included in distros, it is likely that an inexperienced person will expose it to the public Internet, either accidentally or without understanding the consequences.”?
<daniels>
I honestly can't imagine a distro that would suddenly start exposing TTYs over IP without considering what might happen
dcz_ has quit [Ping timeout: 480 seconds]
<daniels>
(and for this specific application, none of the Mesa CI DUTs have publicly-routable IPs)
<daniels>
it's not novel either. Alpine could start shipping passwordless root@ SSH access by default tomorrow, but I'd not expect them to. it's probably not worth a security advisory to them to let them know they shouldn't do it tho.
<bl4ckb0ne>
ill watch psykose to make sure it never happens
apinheiro has quit [Quit: Leaving]
<DemiMarie>
daniels: Oh of course no distro would do it by default. “Inexperienced person” refers to the _end user_, not a distro maintainer.
<psykose>
i've seen worse security advisories
<psykose>
like '3rd party repo has insecure custom installer script on github'
<psykose>
just the other day
* psykose
grumbles in distro maintainer
<DemiMarie>
Was that where the confusion was?
<psykose>
was that to me? just an offhand comment, i'm not confused by anything you've said :)
ngcortes has joined #dri-devel
<DavidHeidelberg[m]>
mattst88: I don't see anything obvious, try to create mesa/mesa issue and cc someone from amd working on vaapi impl.
<mattst88>
DavidHeidelberg[m]: thanks
jkrzyszt has quit [Ping timeout: 480 seconds]
Zopolis4 has joined #dri-devel
frankbinns has quit [Remote host closed the connection]
<karolherbst>
Kayden: 78a195f252d558c828c20bebda4bd9252534f53d regressed OpenCL conversion tests for long -> float conversions :(
<Kayden>
that's...odd
<Kayden>
aren't you hitting nir_lower_int64 in brw_postprocess_nir?
<Kayden>
it seemed like it was getting called twice
<karolherbst>
ohh, it continues to compile, the result is just wrong
<karolherbst>
for input == 0xfffffffeffffffff
<Kayden>
._.
<Kayden>
probably some optimization happening now that's broken
ngcortes has quit [Remote host closed the connection]
ngcortes has joined #dri-devel
pcercuei has quit [Quit: dodo]
Jeremy_Rand_Talos has quit [Remote host closed the connection]
Jeremy_Rand_Talos has joined #dri-devel
<karolherbst>
mhhh, looks like some clamping got removed.. but that's kinda hard to track down
<Kayden>
is there something I have to do to get iris to work with rusticl other than IRIS_ENABLE_CLOVER=1? clinfo is showing rusticl but it's not loading iris_dri
<Kayden>
had it working before but I lost my history
<karolherbst>
rusticl only repsects RUSTICL_ENABLE
<karolherbst>
RUSTICL_ENABLE=iris
<karolherbst>
anyway, you want to run this test: ./build/test_conformance/conversions/test_conversions float_rtn_long -w -1
<Kayden>
ah thanks
<karolherbst>
this kinda smells like an opt being slightly broken tbh
<Kayden>
yep.
<Kayden>
for 64-bit
<karolherbst>
sooo
<karolherbst>
there is a imax uadd_sat 0x20, iadd 0x1f, ineg uclz a, b sequence missing