Announcement

Collapse
No announcement yet.

QEMU 6.0 On The Way With LTO Support, AMD SEV-ES Guests, Multi-Process Experiment

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • QEMU 6.0 On The Way With LTO Support, AMD SEV-ES Guests, Multi-Process Experiment

    Phoronix: QEMU 6.0 On The Way With LTO Support, AMD SEV-ES Guests, Multi-Process Experiment

    This week marked the hard feature freeze for QEMU 6.0 along with the tagging of QEMU 6.0-rc0. The QEMU 6.0 release should happen around the end of April for this important piece of the open-source Linux virtualization stack...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    It's a shame SME/SEV-ES is only available on EPYC. I'd love to explore it on smaller CPUs.

    Comment


    • #3

      "- Support for QEMU to emulate Qualcomm Hexagon DSP units."

      That's actually kinda big news ! Along with ARM 8.1 support, yeah that's big news !

      Comment


      • #4
        Nice nice. With all these improvements, shouldn't qemu perform better than virtualbox for desktop virtualization?

        Comment


        • #5
          Originally posted by milkylainen View Post
          It's a shame SME/SEV-ES is only available on EPYC. I'd love to explore it on smaller CPUs.
          Tell me about it. I have a Ryzen Pro with some SEV-ES settings in the BIOS, enabled them all, and got nuthin in the /proc/cpuinfo flags so I have no idea if I have it or not or if there's some BIOS setting I need to tweak, if I need a different microcode with SEV-ES support, both or ???. I've read that Ryzen Pros have support in the CPU and all the right internals for SEV-ES and SME only that they aren't enabled in the microcode or that it can be limited by the motherboard and its BIOS.

          bridgman Do you know anything about that and/or can you comment on it?

          Comment


          • #6
            Originally posted by caligula View Post
            Nice nice. With all these improvements, shouldn't qemu perform better than virtualbox for desktop virtualization?
            ?did virtualbox ever close the (rather big) gap?

            Comment


            • #7
              I was just browsing through QEMU and virt-manager repos and a thought came to me... Is there some strategic risk of all these things being on GTK 2? I know the last stable release of GTK 3 was supposed to ease transition to GTK 4, but what about the stuff that stayed at 2? Do we need supported backports of GTK 4.x runtimes for long-lived systems like RHEL and Ubuntu LTS so developers can avoid getting politically-mired in a transition from GTK 2 to 4?

              Comment


              • #8
                Originally posted by mppix View Post

                ?did virtualbox ever close the (rather big) gap?
                My experience is that VirtualBox is definitely slower in headless mode, but for a desktop virtual machine, VirtualBox feels faster thanks to the guest additions and smoother mouse integration. Not to mention setting up a full desktop experience is still easier with VirtualBox than QEMU + virt-manager, especially if you want shared folders and stuff like that.

                Comment


                • #9
                  Originally posted by Calinou View Post
                  My experience is that VirtualBox is definitely slower in headless mode, but for a desktop virtual machine, VirtualBox feels faster thanks to the guest additions and smoother mouse integration. Not to mention setting up a full desktop experience is still easier with VirtualBox than QEMU + virt-manager, especially if you want shared folders and stuff like that.
                  Agree 100%. On my workstation, I use both. VirtualBox for Windows VM's, and virt-manager for Linux and FreeBSD VM's.

                  One annoying thing about VirtualBox though is that it doesn't support hot add/remove storage, you have to power off the VM to make disk changes. Virt-manager will let you hot-plug and hot-remove.

                  Comment


                  • #10
                    Originally posted by Calinou View Post

                    My experience is that VirtualBox is definitely slower in headless mode, but for a desktop virtual machine, VirtualBox feels faster thanks to the guest additions and smoother mouse integration. Not to mention setting up a full desktop experience is still easier with VirtualBox than QEMU + virt-manager, especially if you want shared folders and stuff like that.
                    This. I don't know what's wrong with my libvirt config but I just can't install any version of Fedora on KVM. Anaconda just got segfaults. Installed VirtualBox and now I'm having fun "emulating" an old PC (installed Fedora 15 to know what was there on the GNOME 3 early days)

                    Comment

                    Working...
                    X