On Thu, 18 Jul 2024 09:20:15 -0400 Mary Strodl <mstrodl@xxxxxxxxxxxxxxxxxxx> wrote: > On Thu, Jul 18, 2024 at 01:53:23PM +0100, Matthew Wilcox wrote: > > That does work, but I would assume that since this BIOS exists to > > communicate with the hardware that it'd need various special privileges > > and that running in ring 3 would not work. > > Exactly. > > > Ultimately, better off running the whole thing inside a VM and passing > > the device through to the guest. Or ignoring the BIOS entirely and > > implementing direct access to the hardware. But neither of these > > approaches is "a way to do what I'm trying to do", they're entirely > > different approaches to making this hardware work. > > If I ran the whole thing inside a VM, I would still need support in the > kernel, right? > > As far as I know, there is no documentation on Congatec's side about the > underlying interface. Obviously I could disassemble the blob in the BIOS > and figure it out, but I suspect that will have much less hardware > compatibility and be subject to random breakage if they make a BIOS > update or something. Plus, I would probably run afoul of copyright if I > wrote a driver after doing that. > > I'm not really thrilled that this is their design either, but I'm not > sure that there is a better answer... > The hardware is weird, but we should try to support it in some fashion. But without making dangerous functionality more widely available. So we're looking for some solution which can be fully contained within that hardware's driver. Dumb idea, there will be other ideas: is it practical to take that code blob out of the BIOS, put it into a kernel module (as a .byte table in a .s file and suitable C interfacing), compile that up and insmod that module?
