Announcement

Collapse
No announcement yet.

QEMU 0.15 Brings Several New Features

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

  • QEMU 0.15 Brings Several New Features

    Phoronix: QEMU 0.15 Brings Several New Features

    Replacing QEMU 0.14, which was released back in February, is now QEMU 0.15. This new major update to this open-source processor emulator that's commonly used with KVM (the Linux Kernel-based Virtual Machine) delivers on several prominent features...

    http://www.phoronix.com/vr.php?view=OTc3OQ

  • #2
    Mandatory glib dep? Ew.

    Comment


    • #3
      Originally posted by curaga View Post
      Mandatory glib dep? Ew.
      Why? If QEMU developers find it useful and take advantage of a library instead of reimplementing everything from scratch and invariably in a buggy way, everyone benefits from that. If the objection was anything technical, I guess we will hear about the specific details instead of this response

      Comment


      • #4
        Benchmarks

        With new releases from QEMU and VirtualBox, and Xen finally making it into the kernel, I think it's time for a virtualization comparison

        Comment


        • #5
          Originally posted by unrulycow View Post
          With new releases from QEMU and VirtualBox, and Xen finally making it into the kernel, I think it's time for a virtualization comparison
          QEMU doesn't have any kernel component. KVM and Xen kernel patches are all in the kernel as of 3.0 and VirtualBox modules haven't been submitted upstream at all afaik. It isn't likely to get merged in as it is.

          Comment


          • #6
            Thats not fully correct, it has one but it is optional:

            http://wiki.qemu.org/KQemu/Doc

            Comment


            • #7
              Originally posted by Kano View Post
              Thats not fully correct, it has one but it is optional:

              http://wiki.qemu.org/KQemu/Doc
              You should read the link you are pointing to

              "Current versions of qemu (0.11 and up) has no support for kqemu anymore, focusing on kvm instead"

              Comment


              • #8
                Originally posted by RahulSundaram View Post
                Why?
                Bloat.

                If the objection was anything technical, I guess we will hear about the specific details instead of this response
                You really should get off your high horse.

                Comment


                • #9
                  Originally posted by curaga View Post
                  Bloat.

                  You really should get off your high horse.
                  Reusing glib is the opposite of bloat. Rewriting each of the relevant functions would be much more bloat than reusing a well tested, mature and widely used library. I don't own a horse. I have a pony though :-)

                  Comment


                  • #10
                    The commit mentioned two things, tests and threading in virtio-p9. Why do you believe all users should be penalized for a developer use case (tests), or a small minority (plan 9)?

                    Comment


                    • #11
                      Originally posted by curaga View Post
                      The commit mentioned two things, tests and threading in virtio-p9. Why do you believe all users should be penalized for a developer use case (tests), or a small minority (plan 9)?
                      I trust QEMU developers to do their job since they have proven themselves over a number of years. I am sure they will accept patches if you want to help out though.

                      Comment


                      • #12
                        Originally posted by curaga View Post
                        The commit mentioned two things, tests and threading in virtio-p9. Why do you believe all users should be penalized for a developer use case (tests), or a small minority (plan 9)?
                        In the grand scheme of things, GLib is a pretty trivial dependency. QEMU supports tons of "bloat" that only small minorities will ever use (e.g. SPARC emulation), because it can. It's the nature of the beast. We're talking about a project founded by a guy who also wrote a PC emulator in JavaScript. If you want Bochs or Xen, you know where to find them.

                        Comment


                        • #13
                          Originally posted by Ex-Cyber View Post
                          In the grand scheme of things, GLib is a pretty trivial dependency. QEMU supports tons of "bloat" that only small minorities will ever use (e.g. SPARC emulation), because it can. It's the nature of the beast. We're talking about a project founded by a guy who also wrote a PC emulator in JavaScript. If you want Bochs or Xen, you know where to find them.
                          Yes, but those are _optional_, which is the point. If I do not need Sparc emu, I can disable it.

                          Comment


                          • #14
                            Does anyone in here happen to know if/how qemu or qemu-kvm can detect and verify the presence and proper functionality of an IOMMU on the AMD 890FX platform?

                            Comment


                            • #15
                              Originally posted by curaga View Post
                              Yes, but those are _optional_, which is the point. If I do not need Sparc emu, I can disable it.
                              Given the fact that qemu is open source, if glib bothers you so much, you shouldn't find it difficult you role you own, glibc-less fork, no?
                              OSS, after all, is meritocracy and -not- a democracy...

                              Back to the subject at hand, I'm one Xen aware release of the nVidia binary driver away from realizing my plan to use a stable base OS as host (used for network services and work) running a number high performance guests (both Linux and Windows) with full 3D support.

                              - Gilboa
                              DEV: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB + 2x3TB, GTX780, F21/x86_64, Dell U2711.
                              SRV: Intel S5520SC, 2xX5680, 36GB, 4x2TB, GTX550, F21/x86_64, Dell U2412..
                              BACK: Tyan Tempest i5400XT, 2xE5335, 8GB, 3x1.5TB, 9800GTX, F21/x86-64.
                              LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F21/x86_64.

                              Comment

                              Working...
                              X