QEMU 8.0 Released with More ARM and RISC-V Emulation (9to5linux.com) 23
There's a major new update of QEMU, the open-source machine emulator, reports 9to5Linux:
Coming a year after QEMU 7.0, the QEMU 8.0 release is here to improve support for ARM and RISC-V architectures.
- For ARM, it adds emulation support for FEAT_EVT, FEAT_FGT, and AArch32 ARMv8-R, CPU emulation for Cortex-A55 and Cortex-R52, support for a new Olimex STM32 H405 machine type, as well as gdbstub support for M-profile system registers.
- For the RISC-V architecture, QEMU 8.0 brings updated machine support for OpenTitan, PolarFire, and OpenSBI, additional ISA and Extension support for smstateen, native debug icount trigger, cache-related PMU events in virtual mode, Zawrs/Svadu/T-Head/Zicond extensions, and ACPI support. Moreover, RISC-V received multiple fixes covering PMP propagation for TLB, mret exceptions, uncompressed instructions, and other emulation/virtualization improvements.
Improvements were also made for the s390x (IBM Z) platform, the HP Precision Architecture (HPPA) platform, and x86.
- For ARM, it adds emulation support for FEAT_EVT, FEAT_FGT, and AArch32 ARMv8-R, CPU emulation for Cortex-A55 and Cortex-R52, support for a new Olimex STM32 H405 machine type, as well as gdbstub support for M-profile system registers.
- For the RISC-V architecture, QEMU 8.0 brings updated machine support for OpenTitan, PolarFire, and OpenSBI, additional ISA and Extension support for smstateen, native debug icount trigger, cache-related PMU events in virtual mode, Zawrs/Svadu/T-Head/Zicond extensions, and ACPI support. Moreover, RISC-V received multiple fixes covering PMP propagation for TLB, mret exceptions, uncompressed instructions, and other emulation/virtualization improvements.
Improvements were also made for the s390x (IBM Z) platform, the HP Precision Architecture (HPPA) platform, and x86.
First post! Go QEMU, go! (Score:2)
Not "go", no. (Score:1, Interesting)
Ha ha, parity. Maybe, at that. But in the bad way. As in needless hassle because the developers lacked a clue or two. (vboxmanage, I'm looking at you.)
Looking through the changelog, there's this little gem:
Looking at that page, we see:
Re: (Score:3)
You mean, they wrote a low-level, security-sensitive daemon that also needs high performance... in a language appropriate for that, instead of an inappropriate one? That's somehow a bad decision?
So to get similar functionality back I have to install (and maintain) two libraries in addition to this thing, and oh, also install and maintain a complete toolchain for a language that only just now learns to not include all debug information by default
The C implementation also depended on libcap-ng and libseccomp, so no. You only need the Rust toolchain to compile virtiofsd, not to install a built package, so also no.
Re: (Score:1)
You mean, they wrote a low-level, security-sensitive daemon that also needs high performance... in a language appropriate for that, instead of an inappropriate one? That's somehow a bad decision?
That's you putting words into GP's mouth. I have it on good authority he ment exactly what he said.
The C implementation also depended on libcap-ng and libseccomp, so no.
Okay. But that means the low-level stuff is done in C, which you just called an inappropriate language for this stuff (I beg to differ, but I'll ignore that for the sake of argument), so... the benefit of externalising and switching languages was what again?
I'm still seeing a switch from shipping something you'd really only use with the software, with the software, to externalising it, switching to another la
Re: (Score:2)
The benefit was better security and performance, like I said.
Those libraries are only used for dropping caps and setting up syscall restrictions, things which are only done once during startup. The parts that are exposed to untrusted inputs (the virtio interface with the VM) and the parts that need higher performance (also the virtio interface, plus the file I/O) are done in Rust.
Re: (Score:2)
The appropriate language for that could only be C.
Immature fad languages have no place.
Re: (Score:1)
Re: (Score:2)
C needs to die a death on everything except the embedded space.
Nope, that's Rust again.
Rust is a Trojan Horse hailed by idiots as a "secure" programming language because it doesn't make them think about memory allocations and pointers. A.K.A. For hand holding them through performing their literal jobs. By that logic BASIC is even more secure than Rust because some versions don't allow dynamic native code, and the most secure system is "Computer, coffee. Black." Because there is no human programmer at all. (*In most use cases.)
Of course that is bullshit. Starfleet
Re: (Score:2)
A.K.A. For hand holding them through performing their literal jobs.
Then stop parading around a compiled language. You need to write the opcodes by hand in assembly or you're just being lazy. Wait, why do you need the crutch of a written interpretation? Just stick with 1s and 0s.
Re: (Score:2)
Only a Rust coder would think opcode programming would have more security and safeguards than anything else, when the opposite is true.
Re: (Score:2)
I'll prove you wrong. When I do any coding, it's usually PHP. I live in insecurity. I might have been making a point with my earlier comment but it was also sort of a joke on this:
because it doesn't make them think about memory allocations and pointers
So just taking this to its logical extreme and saying that any abstraction at all can lead to more insecure code. When really, you have to do so much more handling at lower levels of abstraction that you're more prone to errors.
Re:First post! Go QEMU, go! (Score:4, Informative)
Maybe we can get parity with some of the commercial competitors.
Don't hold your breath. To this day, after many years of trying, I have still not gotten QEMU/KVM to bridge a network, either through the GUI, command-line, or configuration files. In VirtualBox, it's a single mouse click.
I had great hopes for KVM when it was first released, but its usability is absolutely revolting compared to VirtualBox. I'm more than willing to accept VirtualBox's lower performance in exchange for its drop-dead simple usability.
QEMU/KVM is still a non-starter after 17 years! Literally everything else is better.
Re: (Score:2)
To this day, after many years of trying, I have still not gotten QEMU/KVM to bridge a network
Can't speak for you but what happened to me was that netfilter was blocking my packets. I just disabled it for bridges since I'm not using bridging firewalling on the host in question, but a more secure thing to do would be to actually set some of that up.
Re: (Score:2)
It sounds like you don't have the bridge device set up on the host,
Wrong. The internet connected side of my PC uses a bridge interface which I already had working fine before setting up KVM.
telling a guest to use a bridge device is very easy.
Yes, and yet, totally worthless if your packets are stepped on by netfilter [linuxconfig.org].
Re: First post! Go QEMU, go! (Score:5, Interesting)
Re: (Score:2)
Usability matters, and most of the time is more important than performance.
I planned on testing out QEMU not for virtualization, but for emulation purposes (running really old software). I downloaded a Windows-native build of QEMU and found out that each emulated platform has two executables. Nowhere in the installation directions does it say what the difference are between the two, and I couldn't find any info from various forums, either. It's like it's some kind of club secret or something. I mean, co
Re: (Score:2)
Usability matters, and most of the time is more important than performance.
This, oh so much.
Try setting up a VM to use the host's network address without root / admin privileges. It can't be done without major hacks using the command line tools outside of KVM / libvirt. (Even then you still need root to run those commands and doing so confuses the heck out of network manager.) Under Virtualbox it's as simple as the end user clicking an option on a drop down menu.
Need to set up a Win7 VM? Under KVM / libvirt you need to disable all CPU cores / threads except one, and then set
Re: (Score:2)
Hmm.. i'm a happy user.!
Have running qemu without major problems from early 2000 (when Linux-KVM was a seperated module).
From version 2.6.0 have a binarie for Windows on laptop and a self build on Linux PC (slackware) both using the same images.
Biggest archivement: Fast bootup for Windows and for stop just "kill -9" a kill / restart takes only 4 seconds.
Re: (Score:2)
That's odd. I just installed libvirt and virt-manager on CentOS, used virt-manager to set up the VM with bridged networking and it just works. Like you say, single mouse click. In fact it's worked for over 10 years. In fact I've used it with KVM since the very beginning, back when I moved from Xen to libvirt and KVM. I can't explain why you're having those issues. Any distro that ships virt-manager and libvirt will set up the bridge automatically.
Re: (Score:2)
I said I "just installed" I mean I simply installed libvirt and virt-manager. I've not done it in the last year or two, so may be some weird firewall issue is causing you problems. But I've certainly not heard or seen any widespead problems with folks bringing up VMs with bridged networking.
Re: (Score:1)
Try Proxmox.
We replaced HyperV with proxmox for about 50vms over 3 severs.
Proxmox backup server is a treat to.