 Hi, welcome to my talk. My name is Thomas Hood. I'm working for Red Hat. And I hope you basically all know what QMU is about. So who used QMU before? Just raise your hand. OK, who's just here because you were too lazy to leave? OK, at least two. That's great. OK, so QMU is basically an emulator. It emulates 21 different CPU architectures and has support for a couple of CPU virtualization frameworks like KVM, Hypervisor, Framework, or MacOS, and some others. QMU does three releases a year. And the major version is bumped at the beginning of each year. So QMU is not doing any semantic versioning or something like that. And this talk will cover the last year. So that means I will talk about QMU 7.1, 7.2, and 8.0. If you're interested, the schedules are available in a wiki. So if you are curious when the next version will be released, just have a look at this URL that I listed here. The next release will be QMU version 1. So let's jump into it. What's new in QMU 7.1? So I have to say QMU is a huge project. So each release contains a lot of new feature, a lot of new stuff. And of course, I cannot mention everything in a 10 or 15 minutes talk. So I have to pick some few, but that doesn't mean that the other features are less important. One of the big things that have been added in QMU 7.1 is the so-called Longarq 64 support. The Longarq 64 is a new risk CPU by the Longxin technology company. It's a Chinese company. And it's said to be a little bit a mixture of risk five and MIPS. And QMU now supports both full system emulation with the QMU system Longarq 64 command. It emulates a pyro virtualized machine there. And you can also run the Linux binaries for this architecture directly on a Linux host for example on your x86 Linux host with the user mode binary emulator that's the QMU-Longarq 64 command. I also got a quick example, but I'd like to do it at the end depending on how much time we will have left. Another great cool new feature in QMU 7.1 is the zero copy send migration feature. And this allows you when you migrate a guest in QMU from one QMU instance to the other, QMU normally has to copy the guest pages before sending them over. And with this feature, you can skip this copy step. So it reduces the CPU usage on the host quite a bit. Disadvantage, it needs support for locked memory on the host so it only works with Linux. And if you want to use it, you can use this, where's my moves? This HMP is for human monitor protocol so this is the built-in shell, you could say, of QMU. You can use it with this migrate set capability, zero copy send on command, or you can liberate, you'd say, vers migrate and then dash dash zero copy. Now, QMU does not only add stuff. We are also removing some older features since at one point in time the code desk would become unmaintainable otherwise. And one of the older things that were in QMU since quite a while already is the dash sound HV command line option. This was used to configure the sound hardware in the guest, but it was considered legacy didn't have the possibility to connect it to a back end on the host, for example. So it's no advice to use the dash device and dash audio dev command line options or if you want to do it in short, there's a new dash audio command line option where you can do both now in one command. So if you're using dash sound HV SB16, for example, in the past to configure the sound cluster 16 device in your guest, you would now do dash audio and then PA for pulse audio on the host side. So this is the host back end then comma model equals SB16 and this will configure sound cluster 16 in the guest. So this one command now wires up the guest side and the host side. QMU 7.2. So QMU has a bunch of network back ends that allow you to send a network traffic from the guest to another place and it had the possibility to tunnel the network traffic from the guest via a socket since quite a while already but this only supported internet sockets and a couple of people were asking about the possibility to use Unix sockets too. So QMU 7.2 introduced two new network back ends. There's a net dev stream for connection based protocols and you would say now dash net dev stream and then you say address type is a Unix socket now and you can configure the path on the client side. So the other QMU that you want to connect to it you do basically the same just say server equals off and you can also use a data grant based protocols like in the example here below depending on what you prefer. Another thing that has been changed in 7.2 is the user mode emulation binaries for x86. They now default to a different CPU type. So a couple of Linux distrust recently switched to a higher level of the x86 architecture you could say. So this is the x86 64 version two level which require, so these binaries for example require some SSE extensions or stuff like that which might not be available in all the CPU models. And so that you are able to run these binaries out of the box, QMU now defaults here to the maximum CPU model. So that gives you all the features that QMU supports. And again cleanups. In 7.2 we removed the so-called slurp sub module from the repository. This doesn't mean we removed the feature, it just means we removed the code. So for historical reasons QMU shipped the slurp code and its own repository and then the tour balls. But in recent years all Linux and other distributions brought up and supply this slurp code as a proper packaged library. So take away here is please install lip slurp devil before you compile new QMU versions if you still want to use the dash net diff user for configuring your network backend. Or there's another new alternative called past which you can use also instead. This is an external program. So you basically connect dash net diff socket that program and it will take care of handling the network packages. By the way there's a talk about pasta so that's the sister project of past tomorrow. If you're interested in that be sure not to miss it. QMU 8.0 so there were many improvements again. I just wanted to list a few risk five in support for ACPI. On x86 you can now pass a random seat to the Linux kernel when you use the, when you load the kernel with the dash kernel command of QMU. We've got no support for compact flash card emulation and there have been quite a bit of performance improvements in TCG so that's the tiny code generator the JIT engine of QMU. The back end node there supports a couple of CPU extensions if they are available. And as always we did also some cleanups here and this time we removed the VATR-IFS demon from the repository. Since there's now a new implementation that's, that has been rewritten in Rust and it has become quite mature in the last month. So the decision has been made to remove the old implementation that was written in plain C. Okay, I think I was fast enough so before we go to the questions I can show you the example. So this is my normal laptop, oh wait, this is useless. This is my normal laptop here so you can see it's x86 machine. And I cannot remember the options. So if I want to emulate this new system now I download a kernel so I mentioned in the slide where to get the kernel, the init-rd and the firmware for that you can start it like this. It runs through the firmware, it puts a system so it just drops into the init-rd shell here and if I know, can you see it? I hope so, great. And as you can see, I've got now an emulated long arc system here. Works, yeah, full software emulation of course. Okay, and that's pretty all from my side. So let me go back to the slides. Questions, yes please. I haven't looked at the socket implementation. I know that, oh, the question was whether there's, when using this new socket implementation for the back ends, whether there's a kind of multiplexing server in between when you can connect three or more, I guess. I'm not aware of multiplexing server in between or something like that. I know that at least the internet sockets are able to do multicast so you could multicast to multiple cumbers. I haven't looked that up in the new implementation but I guess they would be able to do that too, hopefully. So the answer is multicast. Any other questions? Okay, then thanks for your attention. Thank you.