 Thank you folks for coming. This presentation will be my first presentation in open source summit, like ever, that got accepted. So it's good. Yeah, thank you for the clap. And yeah, it's good to be here. Thank you for lending me your eyeballs for the next 30 minutes. I'll make good use of it. We're going to have some good laughs. And basically, when I started making this presentation, I gave this topic, but I didn't like it. So I'm just putting this up for the camera crew so they can put it as thumbnail. But the actual topic is like this one. And basically, I wanted to see QMU as a way to, you know, sort of sidestep chip shortage in general. We used it for that matter, and I'm pretty sure a lot of people use QMU for different reasons. It's a great tool, a great piece of kit. And that's what we are going to be talking about today. How do we use it for this one specific reason? As an emulation. But this is going to be more of a refresher. I didn't make it as a one-on-one guide. So hopefully I can, you know, help everyone along as we go on this journey. But yeah, for Introduction Sick, I am Vipul. And I work as a product owner and a documentation lead at Bellina. You might have heard of Etcher. You use it for flashing, Ubuntu, or whatever distro you want on your friend drives. And it has been around for quite a bit of time. A lot of the community loves us. So Bellina does Etcher and a lot of other things. And I also write documentation for startups, mostly open source. I contribute to multiple organizations, online and offline. And I'm organizing recently, PyCon India, as well as Sustain OSS India back home. And my pronouns are he, him, and this is the best pronunciation for my name. It's Vipul. And we'll be pulling quite a bit of concepts today. It's KVM. It's QMU. It's virtualization. It's TCG. What is this? So we'll start with something familiar. This is Rajuri Pai. Everyone has seen this green board. Really, the defining piece of small scale computing. It has everything. And it turns out it ain't much. But it packs quite a punch in terms of doing its use case wherever it's applied, right? But it's a very useful device. And it powers most of the world that we are living in. Satellites, underwater drones, smart dustbins, your talking speaker at home. And so does the company's Berlina works for. We do management for Dyson backpacks. We do underwater drones. We do satellites. Basically, we do management of IoT devices. We don't build these solutions. People come to us for management. But, yeah, as I said, embedded is everywhere. And so is Rajuri Pai, so is Enternoaks, Jetsons. So when one person parks their ship wrong in a Swiss canal, we get a problem, like all of us together. We get a problem which we can't fix. It's a chip shortage. It's the supply chain issue. People can't get what they want. You and I want a screen to build the hobby project next day. And it's not coming next day. It's not coming next month. It's not coming this year. What do we do? How we mitigate that? How we mitigate this thing when a major company shuts down a very popular board? I know what has happened, like ASUS is building it next. But these things do happen. Uncertainty still exists here. And how do we have solutions for that when things are not even in stock? I'm pretty sure, in some of the countries, at least back home, things are recovering. But it's still very costly. And that's what we are living in the world. What's the solution? Is it a bird? It's a Pokemon? No, it's Kimu. Wait, I'm not full screen. One second. Where's my mouse? Come on. It just doesn't want to go full screen. No worries. Linux, am I right? So Kimu, right? Everyone knows this. And a generic open source emulator virtualizer has been around for two decades. People use it. People love it. People hate it. Has been released like the first patch I found out, like the first patch is 0.10 in 2009. But actually, Fabrice released the first one, like not open source, but just released it in 2003 actually. So it has been 20 years exact. And it's supported in multiple architectures everywhere. Every architecture that we work on or will be working on in the future, RISC-5 included, has support for Kimu. We are at least on to. You can see the second green column there where you can see TCG support for almost every architecture. And then you have hardware virtualization support for some of the popular ones. And this is good to see because when you're using Kimu as a tool, you can better believe you will get the support you need from the community, from stacker flow when you need it, and sometimes from your friends who already know the store. So what really is Kimu? Like, sure, we gave out a definition. And the definition I like from Wikipedia is Kimu is a generally accurate, generally accurate, wait, I have written it down because I knew I'd forget. Functionally accurate virtual cum emulation platform, that's Kimu. But what does that mean, right? I'm doing an open-ramp conversation here with people. I'll start with a very good example. I love to cook. Meat, Chef Kimu. Chef Kimu has been preparing dishes all the time. It's its job. And here, the kitchen is your computer. Chef Kimu is the chef, yeah, yeah, sure. Customers are operating systems or applications that you're going to run in your kitchen, that you're going to serve food to. They're extremely picky. They're like the worst customers. Someone wants pasta, someone wants sushi, someone wants Indian food. How does Kimu serve everyone? The best part, Kimu has a special recipe book called Hypervisor. What is a hypervisor? A hypervisor is something that it allows it to cook multiple dishes without having the actual hardware for it. Everyone wants different dishes, different hardware being used to present those dishes. But Kimu has something that, you know, that it can cook maybe Chinese food without a wok, pasta without olive oil, sorry, Italians. And like anything, it can magically transform to suit the eater's preference, the emulated hardware. So it can serve whatever dish you want. And picky eaters will be amazed because Kimu can satisfy anyone's cravings without even helping them realize they are going to have the hardware. No one in the restaurant knows Kimu is doing this. They are all oblivious of the fact, getting the food they need, getting the resources they need, in the hardware they need, emulated. In the kitchen, that is your laptop. So in essence, Kimu is the master chef that makes your computer a versatile kitchen, capable of satisfying the most diverse and demanding software taste buds, all without require any specialized hardware. They never have to leave their native environment because they know they are never, they always knew they are in the native environment. But your kitchen is the native environment here. So hopefully this example helps. I don't know. I should have done it before lunch though. Everyone feels hungry now. But with the kitchen thing, Kimu is overwhelming, man. It's like, it's tough. It's tough to get into. You know this place. What is this place? Can someone tell this? What is this? It's this conference hall. I was thinking of going to the fifth floor. I can't. It's a chamber of secrets here. You have to figure out which ladder to cross and which place to go. And that's what Kimu is. I was thinking all night about this, this example and this. I'm so proud. I came up. But yeah, Kimu is like overwhelming for people who are starting up. It's tough to get in. It has a steep learning curve. But I can tell you after this talk, hopefully it will be good for you. It will be smooth sailing. You can have a refresher about what Kimu is, how to use it beyond the GUI that you have been using and we'll make something out of it. The fun is over. Or sorry, the boring slides are over now. The fun actually begins. How does it work? So when I learned Kimu six years ago, I saw AMDs. There's a link I've posted here. I'll share you the slides. AMD did a thing about how does Kimu work? And I have been reusing this all the time. It's screenshots literally from the video. So Kimu works in a way where think about us building for an ARM device, right? So when we are writing code, we are writing for that ARM device, that code. We write for the target platform. We are using libraries for the target platform. We are using SDKs. We are using tool chains. We are using libraries for the target platform. Once all that happens, once all that happens, you get into Kimu and you run the software as the target platform. But what changed? You are in Kimu now. So the target platform is here. And that's where the magic happens where when you are executing software, you're executing as you are in the target platform. How does that happen? Let's see. So when Kimu is like the official translator here, when we are running in the ARM world and we are executing our code here, we are giving ARM instruction set to the x86 host and saying like, hey, can you solve this for me? I don't have the compute power enough to do it. So the instruction set goes to x86, translated by Kimu, facilitated and the x86 machine being more bulky or more resource heavy can do it faster than ARM and also give back the results in no time. So it feels just like just in time translation. That's what Kimu does for you. It gives you back the response and the output comes back to you and says like, this is the output of your code. And that's what Kimu does like in a very simplified way. I like this because it's very simplified. It doesn't go into the conversation part, which is the extreme tough. How does the translations happen? How do each architecture talks to each other? And I feel like this way, Kimu is able to have multiple machines working together on the same system within isolation. No one has to know where the code is coming from. Everyone get their answers and quite fast as well because of the dynamic translations Kimu support. Looking at a diagram, we can see the hardware, which is your machine or their laptop and the host to this kernel, this could be your windows, your Linux, your macOS and that's running Kimu on top with a guest application, whatever that is. And then Kimu here is what we call a type one emulation platform. A type one emulation, sorry, it's a type two emulation platform KVN is the type. Kimu is the type two emulation platform which doesn't work on the OS layer. It talks to the OS layer in terms of getting the resources needs. It creates virtual devices. Whereas if you think about on the left side with KVM, KVM is a Linux kernel module. So it does virtualization right on the kernel layer. It doesn't need software emulation. It directly talks to the hardware and it gives you near native performance being a type one emulation platform. So once you use Kimu and KVM together, you can get quite good performance and that's why everyone recommends just use Kimu and KVM. But I wanted to have these slides together to sort of show like why are we trying to say like, okay, just use Kimu with KVM. And that way it helps around. The software runs natively. No one knows what's happening and it also is very cheap to do because you don't have to ship the entire company, thousands of Raspberry Pi's. Everyone can run their own Kimu devices. They can bring back up and the best of all, it's all performance. Like you're not losing, you're losing a bit of performance but it's better than thousands of dollars in hardware that you can't even buy. Let's come out for our actual task which is building this virtual Raspberry Pi. So this is my machine right here. It's a x86 i7 computer with 16 gigs of RAM. This is going to be our host computer today where we are going to spin up a virtual Raspberry Pi and here's how our Raspberry Pi looks like. It's all the specs. But with Kimu, the limitation is, and this is the obvious con, is like you can't emulate everything. If that's the case, why would we need hardware at all, right? So Kimu's limitations are very rapidly decreasing. A lot of the hardware that we couldn't emulate five years ago is now emulated. You can even do kernel Linux modules. You can talk to the HDMI, CSI ports with your laptop or whatever system you're using and you can actually do the work. So thinking about this, this is what our actual list looks like. When you are trying to run it with Kimu, you need four cores of compute with one gigs of RAM. You need Wi-Fi pass through or basically any internet pass through because Kimu doesn't have Bluetooth and it can't have that. You can do video, you can do audio pass through as well and then for storage, you can do whatever you want. And that's what we are going to be building our virtual Raspberry Pi on. Some steps to go before you're building and I'm trying to go with the CLI way this time because I think I heard feedback like a lot of people are familiar with the GUI way. So I like the CLI way because of the sheer flexibility it offers. So right now we are just checking if your system can support virtualization. So if it has VTX or AMDV cores then can support virtualization if this value is more than zero, then you can be sure that you can actually do run Kimu. And the second thing is like, let's also check our KVM see if this machine supports that and then install the dependencies. That's quite nice. So once you have all this in place, you can start running and I wanted to put this disclaimer in as well. So if you are new to Kimu and you're just learning, don't go the CLI way because it's like the Linux way, right? The Linux administrative way. We always want to do the CLI way but it's overwhelming. It's too many configuration options. You can get lost in it a little bit. At least with the GUI, you can gain your first step. I feel like the first step is really important in Kimu and the exploration of it because once you start breaking the system then you will learn even better. Like, okay, what failed last time over? Because the commands look like this. It's not our fault. It's like how Kimu is where a lot of flexibility has been offered where lots of arguments are being used and we will go through in this presentation like what these arguments are and how this actually turns up into an RPI machine but I just want to start a terminal. So this is the command. I'll leave it running and we'll go back to our presentation. So this will start the Kimu machine starting our Raspberry Pi. I already downloaded the Raspberry Pi machine and we can talk about what the commands are. There you go. We are back. So starting from the top, we are first figuring out what is KVM. We didn't touch a lot about it. KVM is kernel virtual machine and it's a kernel module baked right into the Linux kernel. So you don't actually need Kimu. If you want, you can even run virtual machines or emulate using KVM right in the Linux kernel. And sure, it all quite a bit will depend on hardware emulation, like what hardware you're going to support and what use cases will come out of it. But having Kimu plus KVM will get the job done in most of the use cases. So definitely, definitely have KVM enabled. You never know where ever the hardware gets accelerated and you can now directly talk to the hardware instead of Kimu, where it's more of a translation basis. We'll go with an example where I am setting up a network and we'll see how Kimu does it and how KVM will do it. So next thing is machine and CPU. On the second and third line, we are specifying machine templates as well. I think it was Kimu 6, if I'm not wrong, where they added, you can have machine templates in. So now you can specify machine and your CPU, like what CPU you have, and then it will sort of govern you. Because if I specify here that I need only two cores, it won't let me. The Cortex A53 only comes with four. So that sort of thing, that sort of reliability as well as compatibility can be now guaranteed with Kimu. When you're giving it to colleagues, they want to tinker with the commands, but Kimu won't let them. So it's good where you can specify a lot more options and a lot more options for the machine as well. The memory, you can specify whatever memory you want, but right now, since we are completely focused on doing a Raspberry Pi emulation, we are going with one gig and four cores. Next, we come up with very important for the Raspberry Pi architecture, which is device tree or device tree overlays. And I have extracted mine, but you can also use init ramfs if you want, or use your own kernel image to boot up whatever you want. So I like to always extract the image from where I downloaded and then pull out things I want. It is much cleaner that way. Because that way I can use this device tree overlay in multiple times. I mess up and I mess up quite a bit. So it's good when you can do like reproducible builds. And I feel like this part of Kimu is what I like is very similar to how Docker is. You can have reproducible builds even with Kimu, if you want. And the SD card that we are using as the base media is the Raspberry Pi or Raspberry Pi I just downloaded, which is running in the background now. Next bunch of options is network, which is what I wanted to explain a little bit more. When we are doing network configuration with KVM, you can use something called bridge... What is the package? Bridge utils? I think so, yeah. And bridge utils, you can create bridge connections between multiple Kimu machines. You can also use NAT, which is like... If a lot of people do Docker here, so it's like host networking, basically your machine's network connection will be what Kimu uses. Same everything. And then you can define also. So on line 10 I've decided a port for TCP, which is where I can SSH into my Kimu machine if I wanted. And that way I can have remote access to my machine as well if my system says on. And you can specify on line nine what devices you want to connect. So let's say you want a mouse, you want a keyboard connected to your device. So you can specify it here. And that's the flexibility I've been saying, which the CLI gets you. And on line 11, I like to have a no reboot because Kimu machines are sort of not persistent, but they can be if you want them. So if they shut down, they'll just come back up again. In Docker, as you specify restart policies, you can specify it here as well. No graphic is basically, I just don't want to see Raspbian. Bit of a personal preference. And yeah, this is a very nice thing I found out when I was looking through it, where now Kimu supports quite a bit of Raspberry Pi's. And you can just select one. And you don't even have to now specify memory and cores anymore. I didn't know that. So that was a complete TIL. I thought like I'll post it in. And you got a lot of hardware that Raspberry Pi already has. GPIO, SDMMC, the thermal sensor is also involved. I don't know if that was there. Serial ports were always there for Kimu, but they never, they have been quite janky. So it's good that the community is working on it. And it's an open source project. We all contribute to it as well. So it's good that Kimu is really advancing into Raspberry Pi boards, but I hope to see like more boards come up as well. So we can emulate and play around with it as well. But that's the command. That's how you run. And on the background, we must have the machine on. So I'll just zoom in so you can see. And I trust you folks. The password shouldn't be shown. No worries. It's Raspberry Pi, no worries. Raspbian is not the most secure. But yeah, here you go. In one minute, we are inside a complete Raspberry Pi device. You can use this device as a build machine, as a dev machine to build your software, to use it as your CICD environment. But I understand like there are better tools for it. I would say you can use it with Docker, as Marcus was telling me. A lot of things involved, but I wanted to sort of take one single example here, what Kimu can do to sort of help you around just starting as an on-ramp topic. And we are barely scratching the surface here. Like there's a lot of things to go around. Let me bring back the presentation. Other. Kimu can do lots of things now. I'm really exciting because I have been using Kimu for our own personal thing. But I've been looking in the new version. You can do something called, I think this has been around quite a bit, but I didn't know it was called Spice out of all things. You can just copy and paste things from your guest ecosystem to the host. You can do USB pass through, you can mount the file systems as well. Snapshots has been always around, but I think they're also improving it to support better compression. So you can have like way more snapshots than you were in the past. And lots more things to experiment with Kimu these days. So something I hope like with this introduction, you can actually go into your own use case and start up your own machine. Like the first time you start up the machine, it's really nice. It's like starting up your own Docker container, but you don't get the feel because it's like one command. This is actually makes you work for it. So this is the session, right? But this is my favorite thing to do on every talk. How do I use it at work? A lot of people, I see like, they don't cover the practical bits. And I like to really think about like, hey, how do I use Kimu, right? So very good question, whoever asked that. We use it for this example of me just doing like silly drawings is why I like this slides the most. So basically you do like resource segmentation if you're working in a data center job or you are with Google Azure, AWS, any one of the big cloud companies, you already know virtual machines are everywhere where they're segmenting off like big processors to sell off the compute capacity to different people. Someone needs a lot of storage. So they get two cores, a lot of storage. If they need more GPU, ooh, that's also very nice, we'll come back to it. GPU emulation has become really good. I actually saw some videos where someone, four people were playing on the single 490, 4090. I don't know how they did it, but it was really bad five years ago. So it was something that cloud companies also do where they divide the what H100s between a lot of customers and they give the compute capacity to the people who buy it. You can use it for disaster recovery as well, quite nice. When you mess up data migration or maybe you are looking for some new, maybe you're upgrading your Kubernetes version, right? You might want to check or your OS for your devices. You might want to check like if it all works correctly. Training in a search and employee desktop virtualization is quite big in enterprises where a lot of the employees get like part of the compute, but they're not hooked up to like their own computers. It's like one central server in the entire building, running it and that's all virtualization. That's all chemo. Using processors like these and just cutting off cores to whoever needs it. If someone needs more cores, there you go. Oh, I think I did some animation. Like add more virtual machines. But the next example is my favorite. How QMU can be used for CI CD pipelines, which is a lot of people have been using when they want to build and test their software. So it's like, let's say you, let's say we want to do VS code for Raspbian. How do we know it really works? It's all good in paper. When I say in the AMD presentation, it was you write your code for the target platform. You choose the libraries for the target platform, but humans can't be trusted. We have to have test. We have to have code, you know, sort of tell us like, okay, it actually works on the platform. So at Balina, we solve this problem in a different way with hardware in the loop. But if you don't have hardware on hand, you can obviously use chemo. And it's like really effective because you're not losing any bit of performance and you're also gaining test advantage where you're not releasing as fast as possible, but as confidently as possible. And IOT, that means like, that really means a thing because if you ship a bad release, you're like stranding hundreds of raspberry pies in the desert somewhere, it's as easy. So we have a responsibility and I feel like testing could be nice. Hardware prototyping is also a very nice one where let's say your team, you are working a hard tech project and your hardware team is deciding on a hardware piece, but the requirements are clear. You can use chemo to emulate that particular architecture and at least start building the software. Start building tests, maybe help them around. And then, because hardware is like so tough to iterate on and it's so expensive as well, it might change, but at least you have chemo to be flexible on. As a software engineering team working with a hardware team at Balina, flexibility is everything in this game. So I really like how chemo can actually help you emulate complete machines nowadays and use all of it. So your code is like almost 99% there and then when the hardware comes, you can do the final touches. You can solve the race conditions. You can figure out, yeah, there you go. The race conditions have been quite bad. But yeah, lots of things when the hardware comes, it messes up. Chemo is not the silver bullet, right? I hope everyone can get that from the presentation. It's like the best effort, but it's better than the company going bankrupt because you didn't have raspberry pies. Next, the potato computer. I like this. So yeah, you can play, I always love chemo or just KVM for emulation, but I use it at my home KVM switches. Has anyone ever tried like using two, like bridging two computers together using a KVM switch? Pretty cool, pretty nice thing to have. Like if you have two laptops, you can have a KVM switch in between and both machines will share data, peripherals, connected devices, everything because of hardware virtualization. Once you figure out what KVM is, what chemo is, then you can actually start seeing use cases everywhere. More than I would hear. It has been really nice building this presentation because I've been looking into it and then penetration testing, malware testing as well, closed box, so that your computer stays, like your host system stays separate in an isolated environment. You can also do stress testing, which we do quite a bit at Bellino because you can really push chemo machines and see when the host OS will give a risk condition in a completely isolated environment because you're also winning a silicon lottery when you're getting a Raspberry Pi. It's a small chance, right? So some Raspberry Pi will be better than some other Raspberry Pi, just a little bit and that creates problems. You have to account for that in IoT. So we do a lot of stress testing as well, fun stuff. And then the last one is like, you can now, you know, you start using your legacy systems quite a bit, which is what Linux offers, but now you can use virtualization for it as well. And just as a last slide, I've been mentioning Bellino quite a bit. This is basically the product I work on. We use QMU, that last thing is QMU basically, just think about it. I didn't change the diagram, but we basically have a hardware in the loop testing policy at Bellino. So every operating system that gets built, we tested on actual hardware. But imagine, you know, like you're in 2021, IoT company doesn't have hardware. So we built our own QMU worker and that's why I'm here giving this talk. We experimented quite a bit and we settled on QMU to fulfill our testing needs. And I think that's like very helpful for anyone who's into development or testing of their devices on a cross-platform requirement, where you can actually include real test pieces into E2E for creating like a software in the loop. So your feedback process is as good as possible. You know, you're as close as possible to the truth. Nothing goes by you. And once you're in the hardware place, sure, contact me, I'm happy to help. We are doing something open source in this thing, but hardware in the loop also gets you as close as possible to the truth, where you don't want to have devices failing in the field, right? This is what protects you against it. Quick summary, QMU is not a Pokemon. It requires things to break, to learn. You can near natively emulate hardware and you can do it very well with the advancements that happen in QMU. Definitely go back and try it. I'm going back and trying it. Like I have been doing Docker for now three years, nonstop. So I'm really looking forward to like just going back into QMU and like changing some things up because before Docker, it was QMU for all of us. And then Docker came and then a lot of other things also came. So it's good that it's coming back and it's also very nice. Quite extensive features, quite extensive use cases that it can have, as I told you. And yeah, you can also be a master chef. There you go, that's the talk. One last thing. The cheesecake thing is there. So if someone is from Bilbao and can recommend a cheesecake, that's open. But what I do for every talk of mine is I, like slides are here, scan this, but it also has a feedback form. Completely optional. If you don't want to fail it, just press submit and you can get the slides because I wanted to create the slides in a way where it can actually help me out. I self-document quite a bit. So next time I want to run QMU, I'm looking at my slides and I hope that helps you as well. I'm actually updating these slides all today because as I'm learning new things, I have to update it for snapshotting as well, which is something I wanted to cover, but right now I'm already six minutes late, I think. So yeah, that's the presentation. I'll open it to questions now. How are the jokes? Good, good. I didn't sleep today. One question would be, do you have any experience with actually adding custom peripherals to the QMU? Because I mean, I really would be curious if you have any experience in that, how hard is it to actually get some additional like simple hardware added there, which is not yet supported of the shelf from QMU? For me it's like the question comes up as hardware is rarely simple. Like even the simplest thing, right? So we have had to add a custom piece of board, like get supported on QMU. The team worked on it, but I didn't personally look into it. So yeah, we can get in touch and I can definitely help because Bellina is like quite open in that regard. Happy to help out the community, but it is hard because once you're talking on the layers of translating between OSS and between architectures, it becomes a bit too in the segment of like I don't know what's going on. Like how are they talking? And sure it's all open source, it's all out there, but once we get into device support or peripheral support into QMU, like by default, like how QMU has done it for Raspberry Pi, I'm not really sure. Because even I was surprised like that list has grown. It didn't exist when I last used it. So I'm also looking forward to seeing like if you can get some of our devices supported as well, Bellina used to do some devices. So we are looking forward to seeing if we can also use QMU and our devices can be natively supported. Yeah, thanks. That's a great question. No worries. This is better, you can get free for break, perfect. Hope that's it. Thank you.