Here's the full patch for GENPVH+cmdline MMIO+Firecracker support
https://imil.net/NetBSD/genpvh+mmio.patch
This patch includes:
- generic PVH boot for qemu, Firecracker etc... see the "PVH boot with
qemu" thread for details
- a new bus, pvbus, used to attach devices that could be used in m
On 1/6/24 08:33, Emile 'iMil' Heitor wrote:
To support this, I've attached `virtio*` to a newly created bus,
`cmdlinebus?` which is attached to mainbus in amd64_mainbus.c
I am not entirely sure this is the cleanest way to proceed and
would like to have your feedback.
I like the design of Ope
Update
My NetBSD/amd64 branch can now boot using PVH on qemu/x86_64,
qemu/microvm and Firecracker using MMIO backed block devices.
It also supports multiple VirtIO devices such as NICs.
The last blocking point was that Firecracker only supports one data
segment and as such needs DMA bouncing w
Update
I've got current/amd64 booting on an MMIO-backed block device
with qemu's microvm machine, in both ACPI and command-line-hack
(which passes the "device" address as a kernel parameter).
If anybody wants to give it a try:
$ qemu-system-x86_64 -M microvm,rtc=on -enable-kvm -m 256 -cpu hos
On 12/26/23 11:35, Emile 'iMil' Heitor wrote:
intercepted (or so it seems); I thought the hang, which
actually happens sys/kern/subr_disk.c:disk_read_sectors/biowait,
Found it. Wrong bus_space_write_4() in virtio_mmio_setup_queue(),
100% my fault, sorry for the noise.
IRQ is triggered, block
Following up
I ported the "Linux MPtable bug"-feature found by Colin and
IOAPIC is now detected
https://github.com/NetBSD/src/commit/37e57b3a0f464246611a005a350e01e25e091bfe
Nevertheless, the disk IRQ from Firecracker is still not
intercepted (or so it seems); I thought the hang, which
actuall
On 12/20/23 16:56, Taylor R Campbell wrote:
My guess is that this is not going to be MSI -- it'll either be i8259
or ioapic. In that case, it may work to do this:
Thanks a lot for that, here's the result, unfortunately it still
hangs at the first VOP_OPEN() from subr_disk_open.c and the
han
> Date: Wed, 20 Dec 2023 08:37:32 +0100
> From: Emile 'iMil' Heitor
>
> On 12/20/23 06:55, Emile 'iMil' Heitor wrote:
>
> > Well that's the thing, I can't find where does MMIO attaches on FreeBSD,
> > they have a very simple way of creating the resources:
>
> After a bit of digging, their virti
On 12/20/23 06:55, Emile 'iMil' Heitor wrote:
Well that's the thing, I can't find where does MMIO attaches on FreeBSD,
they have a very simple way of creating the resources:
After a bit of digging, their virtio_mmio device attaches to "nexus0",
which if I understand correctly, is our mainbu
On 12/19/23 13:11, Taylor R Campbell wrote:
to queue a task and then run it. Normally softint_schedule is called
from a hard interrupt handler. Here, you need something in the host
to get hard interrupts.
For example, on ACPI systems there are ACPI interrupt resources that
can be used with
> Date: Tue, 19 Dec 2023 08:55:32 +0100
> From: Emile 'iMil' Heitor
>
> Maybe related: the interrupt handler function I wrote uses
> softint_establish() as there's no "real" hardware behind this
> block device, is this the correct way to deal with it?
You need to use softint_schedule in order fo
On 12/16/23 10:25, Emile 'iMil' Heitor wrote:
FYI I'm on it, based on Colin Percival's work here
https://github.com/freebsd/freebsd-src/blob/main/sys/dev/virtio/mmio/virtio_mmio_cmdline.c
I'm getting some results but Firecracker uses MMIO v2 and we only have
v1 so there's still quite some work
On 2/23/22 20:26, el16095 wrote:
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
On 2/23/22 20:26, el16095 wrote:
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
Στις 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 wante
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 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 co
17 matches
Mail list logo
