Στις 23/02/2022 16:56, Jonathan A. Kollasch έγραψε:
On Wed, Feb 23, 2022 at 12:28:36PM +0200, el16095 wrote:I've been working on a NetBSD-based unikernel and trying to make itcompatible with the Firecracker VMM. Seeing as Firecracker only supports the MMIO transport method for VirtIO, I wanted to implement MMIO support for myunikernel.I've seen that newer versions of NetBSD than what my source code was using have code for MMIO and specifically that Virtio MMIO support was implemented for ARM in NetBSD 9.0. So, what I want to ask is there similar support for amd64 also and if not are there some basics I could imitate from how it was implemented for ARM to get it working for amd64 also? Alternatively, is there any reading material you can suggest that explains how the device system works in NetBSD, so that I might possibly understand what changeswould be needed by myself?There shouldn't be anything preventing our existing Virtio MMIO via ACPIcode from working on amd64 in -current. Probably just needs enabling and testing. The "virtio* at acpi?" attachment is not currently included in the i386 or amd64 GENERIC kernels however. I don't even know that Firecracker informs the guest about VirtioMMIO devices via ACPI (or FDT). If not, you'll need to create glue codesimilar to virtio_acpi.c or virtio_mmio_fdt.c.
Thanks, that's very helpful.Firecracker informs VMs about MMIO devices by appending to the boot command line a string like this "virtio_mmio.device=4K@0xd0000000:5" ([virtio_mmio.]device=<size>@<baseaddr>:<irq>). So, from what I understand I'd need to write glue code that takes this information and uses it to setup the MMIO devices on the VM side the way Firecracker expects it to; and then attach virtio through that, right? I'm a little uncertain how NetBSD's device discovery works, though, and how I can make it look at the boot commandline for the MMIO devices. Would I need to implement a match/probe function that receives the info from there? And would I then also use the probe function to add the device found to a device list (alldevs, perhaps)? If I make it so, is there something I need to do to let the driver know its match function is actually probing/that it performs indirect configuration?
An additional question I have on top of that is, how would I go about mapping a physical address to a virtual one? I believe the address Firecracker provides is a physical one, while what we need for the drivers is a virtual address. I tried to use functions from UVM, but I had some problems with that, so I wondered if that's the standard/only way to do that or if there's something else I could try.
-- George Gkanas