Στις 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 it
compatible with the Firecracker VMM. Seeing as Firecracker only
supports the
MMIO transport method for VirtIO, I wanted to implement MMIO support
for my
unikernel.
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
changes
would be needed by myself?
There shouldn't be anything preventing our existing Virtio MMIO via
ACPI
code 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 Virtio
MMIO devices via ACPI (or FDT). If not, you'll need to create glue
code
similar 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@0xd000:5"
([virtio_mmio.]device=@:). 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
