Martin Lucina

@g2p Any comments on this, especially regarding an optimum "maximum I/O unit" size for wodan?

@g2p The thing is, as things stand today all our APIs involve copying. So, ignoring the issues with seccomp, a large (e.g. 4MiB) block size is not practical as it...

That makes sense to me. I'd try and fix crosvm to support multiboot, otherwise we'd have to maintain some kind of virtio-for-crosvm subtarget inside Solo5 which would be a pain.

> crosvm matches the 64-bit BOOT PROTOCOL described in [...] Hmm, okay. I guess that makes sense for them since all the(ir) world is Linux. Though you mentioned that crosvm...

> For now my first idea was to chainload Linux->Solo5/Virtio through kexec. I think some people tried that ages ago and it didn't work. Our virtio code is minimal so...

Off the top of my head, you could add a `.text.linuxboot` or somesuch with the Linux entry point into `boot.S`, then it should just be a case of something like:...

I've been thinking about what to do here for the Linux case. There are two cases where the behaviour should be quite different: 1. _In a non-containerized setup_: unlike the...

On the FreeBSD side, it looks like we might have to revert this entirely (see #312). Update on the Linux side -- I'm no longer convinced we should do anything...

Ok, so, in the light of: 1. Discussion in #316, the real fix here is as described in https://github.com/Solo5/solo5/pull/316#issuecomment-464757104 (fixing the FreeBSD vmm APIs). 2. The build system refactoring in...

#366 implements a capsicum(4) sandbox for Solo5/hvt on FreeBSD 12+. Removing the FreeBSD labels from this, as I consider this done there.