I have everyone and welcome to Season 2 of the Small BSD, Sarri.
So I am Emil, I work in the bank.
I have flying Fabia, this didn't go away since last year.
I'm using that BSD since 1998, yes, I am that old and I am a net BSD commuter since 2009.
For those of you who use net BSD, I'm the initial pickaging author now, and old by Jonathan,
which is doing a marvelous job with it, and I am the author of the microbium version of net
BSD, which I will talk about.
Hi, everyone, as well, I'm Corbin, Pierre Pranchali, also net BSD users in 2005, commuter
since 2012, and one change since last year is that now I'm also a free BSD commuter, through
my work at the foundation of the TV.
Okay, so previously on Small BSD, last year I presented in this conference, the first
works to have a net BSD kernel booting in a few milliseconds.
That implied the first job was to implement the PVH capability to the kernel, so it can
be called by QMU with a dash kernel flag.
So that's a bit of assembly work, and some bits.
The second work was implementing the MMIO handling.
When you call a virtual machine on the BSD or free BSD, all Linux, with MMIO, the
parameters, the devices, the virtual devices are declared in a common line, so you just
have to parse the common line and declare them as devices.
First of delays, you know, the actual delay function, where in the net BSD source code, well,
kernel code, and in our case, the virtual machine case, those were not useful at all, so
I killed them, and all this to have the machine type, it's called like that.
The QMU machine type micro VM working with net BSD fully, and that's actually working
and integrated in the upcoming net BSD 11 kernel should be out, real soon, we guess, and
yes, it has the new micro VM configuration available for everybody.
Oh, yeah, it also up into work with another virtual machine manager, which is called Fire
Cracker, which is pretty good, but misses some features and makes the kernel load in a very,
very long time, like 15 millisecond, and that's not acceptable.
Okay, so, this is in two starts, so in net BSD 11, and the version I presented last
year, add all the needed devices to use machine, okay, network, disk, well, everything you
basically need to use a machine virtual machine, but there was something missing in that code,
when you are using a virtual machine, even if you are using Virtio to visualize disk, a
network and so on, you still, if you don't do anything about it, you are still emulating
the serial console, for example, okay, what that means is that for every character that's written
on the screen, you do what we call a VM exit, meaning you get out, the virtual machine,
to execute a machine instruction, well, basically command, the character to be printed
in the serial console, and there is actually a way to use Virtio devices to do that, and
it's VIO-con. So, I implemented, the first thing I implemented is the early VIO-con device,
meaning to see what's happening in the very first moments of the boot. The basic driver was already
implemented, and I put things together to have multiple Virtio consoles. This as benefits
that I didn't thought it would add. First, the first game is performance, okay, the first
game is, as you are using a Virtio device, you don't do VM exit anymore, okay, you stay
in the virtual machine to print characters. The method is pretty neat, actually, Virtio
declares what you declare, declares a register, just called the emergency right register,
while you just put your characters and they are printing the screen, that's neat. The
multiple serial lines feature what it provides, well, obviously multiple serial lines, which
can be, for example, used to control the VM, or maybe you can use it to redirect SDDRR on another
console. You can think about many, many, many, use edges. I did it, firstly, because, I don't
know, those of you who know Sergio Lopez, he works at Red Hat, and he's the author of the
micro VM machine type for QMU, and he's working on a project, which is absolutely amazing,
is called K Run. K Run, basically, is a project that allows you to run commands inside VMs,
and you have to have, obviously, a fast, putting VM to use that. And it told me, well, K Run uses
multiple Virtio consoles to run the commands, so do you have in mind to do the work, and yes.
And there's another feature that's pretty cool that I wasn't expecting, is that QMU can use
those multiple, serial consoles as circuits. So think about it, use your phone, if you
am, and suddenly you can communicate from the host to the VM and vice versa using the socket.
Let's see, let's see a quick demo.
Okay, so, all start, simple, yeah, I'll do this. I can hold you, I'll not worry.
I'll start a simple VM, and I will declare a supplementary port, okay, so that's a VM booting, okay.
And, oh, there we go. So, on the left, I'm on the VM.
If you can see host socket right here, and here I'm on the right, and I'm going to do
socket, for example, no, see stuff. Yeah, so host guest, and I can do this kind of things.
This is the name of the device of the Vio-Con device, and that's, I mean,
that doesn't look like much, but it's really cool.
Think of it, like you can control your VM from the host and vice versa. I know there are a lot
of security issues with that. I know it, so use it with extra care, but, all right.
Now, so that was one way to speed up the boot, which was in this low and now.
So that's my part, credit for the code you do, and email did maybe 95% of what's in this talk.
And I waited a long time before doing the remaining 1%, because if you gain one millisecond from 10,
it's a 10% improvement, but if I had donated the beginning, it would have been just 1%.
So now I can claim a 10% increase. Thanks to the support of memory disks. So when you load the
kernel from QMU, you use what's called a generic PVH to load the kernel. And unfortunately,
in that BSD, we didn't implement until recently, support for memory disks when loading the kernel
directly in JMPV H mode. The reason why you may want to have memory disk support for net BSD is,
for instance, if your root file system is on the FS, it's one way to actually implement it.
You initialize the system from your amd disk and then you show root in it to your ZFS volume.
Works great also for cryptography. Something I also did many years ago with CGD, that BSD driver for that.
Also, one thing you may not know is that the installer of net BSD runs in a RAM disk,
so you can actually take the generic kernel, use the RAM disk to boot on it and it can install the
system. But basically with that, you also have zero driver code, because the access to the
file system isn't memory. You only have to copy it once so you can use it safely. So it's
literally just fire and forget, which is where we gain a bit of performance when booting the system.
There's no driver initialization code or nothing. So the way this is implemented in JMPV H mode,
there is a structure, which I think was standardized by Zen, called HVM starting for.
So in that BSD, the way this works is that you have a file called Gen S assembly symbol,
let's see if, which basically helps you access the content of his structures from SMB code,
then in LOCORD.S, which is one of the first files that actually booted by the kernel,
therefore, in SMB. I implemented more of the members of this struct HVM starting for,
namely the modules. So instead of simply copying the command line in memory,
at the end of the zone where the kernel can start, I also implemented the modules,
so just getting the address of the modules, putting them in memory after the kernel,
then following up with the command line as usual. And basically, when you do that, you can also
patch X86 machine depth. It's in this part of the kernel, because it's still in 32 bits
mode at this point, which is why the code is shared between I3D6 and AMD64, in that
base D that's in the generic X86 folder, and basically, because this is just a bunch of data in
memory areas, the code actually checks the magic for whatever is being loaded. There is a check
for the alpha magic, so loading kernel modules, there is a check for PNG and JPEG files,
because in that base D, we also support or support it splash images. So actually, right now,
I couldn't really test it actually works. And then the code for a box to run this,
to file system images. So basically, just setting the kernel, okay, this is your root file system,
just boot it. And with email or over lunch, we were just thinking, oh, just change everything.
No, we were just thinking, let's maybe add support for device trees, and maybe then we can
have more flexibility in the way all of this is implemented. So with this, I can pass the mic
back to the postman, get in mind that, for example, with what Pierre did, you just have, you can
boot like a trashable virtual machine that boots in milliseconds, okay. So think about it,
for example, as an SSH, a temporary SSH server, or proxy, rebound, whatever. And the second thing I want to
add to what Pierre said is that we support, I mean, this code supports MD64, obviously,
but also 32 bits. We didn't trash 32 bits, we didn't. So you are seeing that small BSD and the
word that we are doing on the NIDSD kernel is going towards using the VM, just like an app,
just like an executable. But what do we need to actually use and make use of an executable
VM is at least variables. Right now, if you want to give an information to a virtual machine,
a variable file, while you have to or share a file system, put something online or have some
kind of trick that will fetch something from somewhere. And actually, I discovered that
commute in the one million, 232 pages of documentation, as a feature called with, you know, I love
just to be here. They just have a marketing problem. And for example, I discovered a
feature that's amazing, that's called FWCFG. This means translating to the guest or variables or files.
I mean, that rocks, okay, but the name did FWCFG. So the cool thing that is that you can just throw
to the VM variables or files. And into small BSD, I did this little snippet that actually permits
the following.
And now, let's see, same, but if we don't know that, I'm going to export a variable for
some food, which boy, okay. And now, oh, so, the variable from the host to the guest. Now,
same thing with, oh, yeah, I suppose, and here, you will have your file, I mean, that's,
the reason why the file is named like this is, that's what Qemun asks to name the files.
I mean, you could just name it like, like you want, but they want it like that. So yeah,
here, I have my HCOS shared on the guest. Now, think about it. You can pass files
and variable. So this could be a shell script, okay, that would act differently,
giving a variable, okay. You can think about many, many ways to use this kind of stuff
and put it together with the VATIO consulting. Okay, I'm good.
Okay, so that was the demo. And now, okay, I hope you are not going to hate me for that,
but so I recently implemented for small BSD. I mean, you know that people nowadays only
knows how to edit the demo and create Docker files. So I thought maybe if you are able to create
a small BSDVM with a Docker file that will trigger many people. And so you are now able to create
a small BSDR information using creating a Docker file, pretty straightforward, okay, you just
tried a bunch of well-known Docker files. I obviously do not support yet the multi-stage
Docker file. I'm thinking about how to do it, but basically you can take
playing Docker file, classical one and change a APT or with the other one.
APM, the Alpine one, an APK with Piccaging and you're set. Let's do a little demo on this one and
I'll stop or yeah, okay. Trust me on this one, it works.
No, it's just I see the timing and okay, so basically what I want to show here,
yeah, I don't know. What I want to show here is the difference, okay, one thing is the model.
This is a laptop, by the way, don't buy framework sucks.
Yeah, I'm sorry. Yeah, I have one, that's where I'm saying it.
What a second. Yeah, what I want to show, okay, so this is a laptop and obviously does a lot of things.
And the performances are not as good as a server or even machine that doesn't have
graphical stuff and so on. Normally what I'm going to show is that there's a huge difference
booting, huge. A difference, booting a micro VM, reading a file as a disk and using a
pairs in each other, they work. So let's see, so I have a tiny
of a term machine which is called risk queue and it's about 20 megabytes, which is already pretty big.
Okay, so this is the disk one, the disk version, okay, 20 milliseconds.
And now I'm going to go with the RAM disk version.
Yep, that fast. Take that, Linus. Okay, I think we are good and questions.
Question is, if it's based on netBestD11, what? Question, I'm repeating the question.
Okay, the features we did are merged into our own branch and in netBestD11, there is only the
say, the season one. Those features are not yet included. We are working on reviewing them and so on,
but we provide a small BestDK node, which is basically a BestDK node with our work and you can
download it online.
Because probably I didn't reduce it. I didn't reduce it, yeah, but you can.
I mean, honestly, this tool could be like two hours long because we have plenty of things to show,
but I have shown only the one. But there is a minimized option, which can minimize first,
only using what's on the disk and second, using another tool I would, I would rather go
sailor, which will only provide the binaries that you need.
Okay, could you repeat that? I'm not sure, I got you.
I have it, it sucks. I mean, there's a flag of small BestD of the start,
starting script, that as the dash W flag, which is actually 9p, it works, but it's really unstable.
It works. I mean, small BestD uses it to create the images, but.