05:35 <vireshk> arnd, geertu Here is the current I2C solution we have, in case you want to have a look. https://github.com/rust-vmm/vhost-device/tree/main/i2c

05:37 <vireshk> geertu, In our case, we are handling this aggregation within the I2C backend itself (which runs on the host). The backend takes as an input, which devices (on which I2C busses) are allocated to which VM (or socket which is used for communication with the frontend). And then the backend just allows those particular devices for specific VMs.

05:38 <vireshk> For GPIO, we are relying on the GPIO aggregator at the moment, as it makes the management in the backend very simple.

06:23 <Xogium> well.. starting to think ATF+optee = headaches due to so much convoluted process

06:24 <Xogium> I really can't get this thinkg to boot. Not even getting to u-boot

06:33 <geertu> vireshk: Thanks, handling this in the backend was what I had done for GPIO originally, too. But the virt guys didn't like that, and suggested creating an aggregator instead.

06:44 <geertu> Mainly because it would reduce the attack surface.

06:46 <vireshk> geertu, right

07:51 <javierm> geertu, vireshk: I wonder how this could be generalized, we have proper abstractions to patition resources like memory (VM), CPU (processes) and storage (FS) but don't have something for peripherals/devices

07:52 <javierm> it seems there is a need to have kind of virtualized devices on top of the real devices, so that these virtual devices could be assigned to different containers

07:55 <javierm> *containers or VMs (if the kernel managed the partition, the VMM could even pass-through the virtual device)

07:59 <maz> javierm: mediated devices are a fairly close match to what you describe.

08:00 <javierm> maz: thanks, I wasn't aware of https://www.kernel.org/doc/html/latest/driver-api/vfio-mediated-device.html

08:17 <geertu> maz: That's for DMA devices?

08:22 <maz> geertu: no necessarily. there is an example in the tree for a basic UART. the doc is pretty heavy on DMA and IOMMU because that's the hard part, but there is no strict requirement for it.

17:03 <drewfustini> maz: thanks, mediated devices looks quite interesting

17:07 <drewfustini> vireshk: thanks for the link to vhost-device-i2c

17:12 <maz> drewfustini: np

18:08 <steev> wasn't this error a thing around 5.17 and vmware/parallels had to do a fix? https://usercontent.irccloud-cdn.com/file/g9XPRorq/Screen%20Shot%202022-06-23%20at%201.07.04%20PM.png

18:08 <j`ey> looks similar yes

18:09 <steev> thought so, i'll poke vmware again

18:09 <j`ey> it was reading ID_AA64ISAR2_EL1 that caused that

18:10 <j`ey> steev: I assumed it was fixed since noone was complaining anymore

18:17 <steev> j`ey: i had assumed so too, but now that I'm thinking about it, in Kali we were reverting those patches in the previous kernels

18:18 <ardb> steev: it would be quite helpful to know which instruction lives at __cpuinfo_store_cpu+0x84 in your kernel

18:18 <steev> ardb: is there a way for me to get that?

18:18 <j`ey> scripts/faddr2line

18:19 <steev> this is one of the original m1 airs

18:19 <j`ey> scripts/faddr2line vmlinux __cpuinfo_store_cpu+0x84

18:19 <steev> give me a moment to boot the older kernel

18:22 <steev> and to clone the kernel, apparently that script isn't part of the headers install for debian packages

18:23 <ardb> steev: all you really need is the vmlinux file from the kernel build and objdump

18:26 <steev> ardb: if i were smart, likely - that said, running faddr2line vmlinuz __cpuinfo_store_cpu+0x84 returns no match

18:27 <steev> it's arm64 so the vmlinuz and the vmlinux file should be identical, no?

18:29 <ardb> no vmlinuz is the compressed binary

18:29 <ardb> you will need the ELF file from the kernel build

18:29 <steev> oh right, we bzip not gzip

18:29 <ardb> no the ELF file not the unzipped binary image

18:30 <steev> okay, downloading the dbg package and hopefully its in there

18:33 <steev> ~/linux/scripts/faddr2line vmlinux-5.18.0-kali2-arm64 __cpuinfo_store_cpu+0x84

18:33 <steev> __cpuinfo_store_cpu+0x84/0x260:

18:33 <steev> ?? ??:0

21:02 <ardb> strange

21:03 <ardb> if you run objdump -d on it (or ${CROSS_COMPILE}objdump if needed)

21:03 <ardb> and search for that symbol name?

21:23 <steev> https://paste.debian.net/1245019

21:24 <steev> are we miscompiling it somehow?

21:31 <steev> oh, i see, hold up

21:33 <steev> ardb: https://paste.debian.net/1245020/

21:34 <j`ey> ffff800008022324: d5380640 mrs x0, id_aa64isar2_el1

21:34 <steev> okay so it's the same issue