14:31 <drewfustini> geertu: have you ever thought about something like GPIO aggregator for other classes of embedded peripherals? I'm thinking about the context of application running in a container on an embedded system (like an ARM SoC) where peripheral access needs to be controlled. I suppose overall, udev works for this, but I think it may not be granular enough for some types of devices.

14:33 <drewfustini> the background is this started with a client saying they wanted " virtio + lxc" but I'm not sure that is actually what they... their goal is to provide a more isolation between applications in an automotive SoC. GPIO aggregator seems to work great for GPIO... but I'm thinking about how isolation between applications could work for applications that are using other types of peripherals.

14:35 <javierm> drewfustini: I think GPIO aggregator only works with the deprecated sysfs interface ?

14:35 <javierm> drewfustini: but in general I think the solution for this is to bind mount the chardevs for the container to access it

14:35 <drewfustini> I believe it creates a new gpiochip with just lines specified

14:37 <drewfustini> javierm: thanks for the link to libkrun. That does look promising.

14:38 <javierm> drewfustini: you are welcome. Feel free to ping Sergio if you want more details, he is always eager to help :)

14:38 <drewfustini> I've been trying to understand if the request for "virtio + lxc" makes sense and I think it could in the context of libkrun

14:39 <javierm> drewfustini: yeah, the security boundaries and level of isolation are different for containers and VMs so I think that makes sense

14:39 <geertu> javierm: it works with whatever userspace GPIO you have enabled in your kernel, i.e. both sysfs and chardev

14:39 <javierm> and being able to package / ship something as an OCI container but running it was a very lightweight VM makes sense

14:40 <javierm> geertu: ah, I see. Cool

14:40 <geertu> drewfustini: You mean like restricting access to a single i2c device on the bus?

14:41 <geertu> spi already has different spidev devices for each device, while i2c has a single chardev allowing you to access all devices on the bus.

14:41 <drewfustini> Yeah, I think that could be part of it.

14:42 <javierm> drewfustini: I see there's a drivers/gpio/gpio-virtio.c driver

14:42 <drewfustini> Yeah, SPI should be handled by udev okay. i2c seems more complicated. Also CAN bus too.

14:43 <geertu> drewfustini: Would https://github.com/oasis-tcs/virtio-spec/blob/master/virtio-i2c.tex help? (I didn't read it)

14:44 <drewfustini> Yeah, I think that is where this vendors request from virtio + lxc comes from. There are already virtio device types specified for all the hardware peripherals that they care about

14:44 <drewfustini> However, they did not feel that kvm+qemu for each application made sense

14:46 <javierm> drewfustini: kvm+qemu could mean many things though, for example there's a microvm machine type: https://qemu.readthedocs.io/en/latest/system/i386/microvm.html

14:46 <javierm> which in theory shouldn't have the same perf penalty that running lets say a full virtual machine with all peripherals virtualized

14:46 <drewfustini> I think that led to the idea of melding the more "light weight" isolation of linux containers (namespace, cgroups, capabilities) with peripheral abstraction that virtio devices provide. I've been trying to think how this would work though as I couldn't find anyone using virtio devices without a hypervisor. Though @javierm pointed me to libkrun yesterday which looks promising https://github.com/containers/libkrun

14:47 <hanetzer> libkrun?

14:48 <javierm> drewfustini: the goal of that project (and qemu microvm machine type that also sergio started) is to find a middle ground between the trade-offs of containers vs VMs

14:48 <drewfustini> javierm: yeah, I've also been trying to help this vendor to quantify why they don't want kvm+qemu.

14:48 <javierm> drewfustini: his point is that there isn't really a dichotomy as most people think

14:48 <drewfustini> hanetzer: this is libkrun https://github.com/containers/libkrun

14:48 <hanetzer> dasting.

14:49 <drewfustini> javierm: thanks for the microvm link.

14:50 <drewfustini> that is an interesting point that there is more of a middle ground than I was conceptualizing between VM and container

14:52 <drewfustini> I found this yesterday too... it was interesting to see it is possible to have the advantages for virtio devices without a hypervisor. Though this was a bit different - how to let a core not running Linux, better interface with Linux - "Hypervisor-less Virtio for Real-time and Safety" - Maarten Koning, Wind River https://www.youtube.com/watch?v=YnQcpndlTHE

14:52 <javierm> drewfustini: interesting

14:58 <ajb-linaro> drewfustini: you know we have a vhost-user gpio backend for exactly this use case?

15:00 <drewfustini> ajb-linaro: thank you... I had not really looked to closely at these topics until this week. Is this related? https://github.com/rust-vmm/vhost-device/pull/76

15:01 <drewfustini> Interesting... https://qemu.readthedocs.io/en/latest/interop/vhost-user.html

15:02 <drewfustini> > In the current implementation QEMU is the front-end, and the back-end is the external process consuming the virtio queues

15:02 <drewfustini> so no need for a hypervisor it seems?

15:08 <maz> there is *never* a need for a hypervisor... ;-)

15:12 <ajb-linaro> drewfustini: yeah exactly that

15:13 <ajb-linaro> drewfustini: so in the vhost-user case you can either just be the backend for emulation (no hypervisor) or run KVM and it works pretty much the same (except the kernel delivers eventfd/irqfd direct to the backend)

15:16 <drewfustini> thank you, that is very helpful

15:21 <Xogium> so... this isn't strictly kernel related but I've got no clue where else to ask... I'm trying to migrate away from pure ATF and use ATF+optee on stm32mp1. I built it and it all went well until... this. I have no idea what its complaining about, I don't exactly understand the optee seeing I started on that about 3 hours ago

15:22 <Xogium> I/TC: Pager is enabled. Hashes: 2080 bytes

15:22 <Xogium> E/TC:0 0 init_runtime:464 Hash failed for page 0 at 0x29600000: res 0xffff000f

15:22 <Xogium> E/TC:0 0 Panic

15:22 <Xogium> anyone has any clue what this means ?

15:23 <Xogium> is it talking about pages as in pages in memory ?

15:25 <Xogium> fwiw I'm doing this because st gave up on maintaining ATF security framework and optee all at once

15:30 <Xogium> I'd ask the st community forum for help, but seeing as its not very usable with a screen reader... I try my luck on irc :D

15:47 <geertu> drewfustini: Probably we just need a way to create an i2c chardev that allows access to a specific set of one or more devices on the bus? I.e. the actual userspace API on the chardev would stay the same.

15:49 <geertu> In theory, you could even combine devices from multiple buses (real aggregation!), but then you need to remap addresses in case of conflicts, which has its own set of problems (i.e. when you need to write an i2c address to a specific register of an i2c device)

16:15 <drewfustini> geertu: I think that is a very interesting idea. I could see this being useful.

16:55 <arnd> geertu: I have a vague memory that the same thing came up when vireshk worked on the virtio-i2c backend