5 ms·

So a fork of Qemu that makes no promises to keep AMD support, and uses words like "leverages". Its not clear why this needs to exist, as opposed to working wit

by _wmd 7y ago

So a fork of Qemu that makes no promises to keep AMD support, and uses words like "leverages". Its not clear why this needs to exist, as opposed to working with upstream to produce a single tree that can be built with a slimline profile enabled

jarym 7y ago
Maybe they want to add experimental ideas as a testing ground? I'm sure anything worthwhile could later be upstreamed if necessary?
eatonphil 7y ago
Sounds like what OpenBSD has done with LibreSSL as a slimmed down fork of OpenSSL. Or even OpenBSD itself as a slimmed down fork of NetBSD. Makes sense to me.
- MuffinFlavored 7y ago
  But now you have a more fragmented BSD market.
  - eatonphil 7y ago
    Kinda. Work is frequently shared between the big ones (video and network drivers for instance).
    - MuffinFlavored 7y ago
      but like, how much further along would hard things like video/network drivers be if instead of managing 3 separate "everything else", it was just 1? think of the time and effort in documenting all of their code, compiling, getting hosting set up. bootloaders, different filesystems, different libc implementations, different command line tool implementations. all to have an opinion?
      - ansible 7y ago
        Eh, there are a number of strong personalities involved in all three projects, and they all have their own priorities. So some kind of split was a natural outcome. As a consequence, all three projects have their own focus (formed in part by the existence of the other projects), and that's good too.
      - aquabeagle 7y ago
        all to have an opinion? One could say that about any industry/market. Differences of opinions and beliefs and interests are what create choice and drive innovation.
        MuffinFlavored 7y ago
        but in the open source software industry, where most people are volunteering, it makes sense to try to be more efficient and not have 100 Linux distributions and 5 BSD flavors or at least, it makes sense to me but I guess contributors are free to spend their time however they please
        yellowapple 7y ago
        OpenBSD and NetBSD have different priorities; NetBSD wants to run on every device possible, while OpenBSD wants to be simple and secure. It'd be more efficient to fork off and let them focus on those priorities (and cross-pollinate where it actually makes sense to cross-pollinate) than to expect those often-conflicting priorities to always have to be balanced throughout the entirety of development. Same goes for Linux distros (albeit to a lesser extent, since "compatibility with software written for bigger distros" tends to be an implicit design goal for smaller distros), or for illumos distros (OpenIndiana is very different from SmartOS).
pm215 7y ago
The NEMU folks did a talk at KVM Forum last year -- the impression I got was that their intent was to use NEMU as a testbed and demo platform of what you could do to produce a slimmed-down version of QEMU, and then as they established workable approaches to then propose/submit them upstream to QEMU piecemeal. On the upstream end, one of the features that landed in 4.0 was a 'Kconfig' system that hopefully will make it easier to build slimline versions of QEMU which don't compile in the kitchen sink.
- swiley 7y ago
  If you want slimed down qemu on x86 only we already have temu.
  - geofft 7y ago
    Can you provide a link to it? Google found http://bitblaze.cs.berkeley.edu/temu.html http://bitblaze.cs.berkeley.edu/temu.html which seems like the wrong thing (it's stuff added to qemu, and it's from 2008). Maybe https://bellard.org/tinyemu/ https://bellard.org/tinyemu/ ? Seems like the right thing but it's not based on qemu I think. Anyone tried it with production workloads? It does seem like it should work - it does KVM and has virtio devices. Although at first glance I don't see either multiple CPU support or live migration support - not having multiple CPU support would basically rule it out for real workloads.
- Izmaki 7y ago
  I enjoyed that talk a lot. Great speaker and impressive work!
GNOMES 7y ago
I question if this optimized to be ran on top of ClearOS. I agree the RnD would be better for all if they worked with Upstream.
jvanderbot 7y ago
Well, according to them: > Modern guest operating systems that host cloud workloads run on virtual hardware platforms that do not require any legacy hardware. Additonally modern CPUs used in data centers have advanced virtualization features that have eliminated the need for most CPU emulation. > There currently is no open source hypervisor solutions with a clear and narrow focus on running cloud specific workloads on modern CPUs. All available solutions have evolved over time and try to be fairly generic. They attempt to support a wide range of virtual hardware architectures and run on hardware that has varying degree of hardware virtualization support. This results in a need to provide a large set of legacy platforms and device models requiring CPU, device and platform emulation. As a consequence they are built on top of large and complex code bases. > NEMU on the other hand aims to leverage KVM, be narrow focused on exclusively running modern, cloud native workloads, on top of a limited set of hardware architectures and platforms. It assumes fairly recent CPUs and KVM allowing for the the elimination of most emulation logic. > This will allow for smaller code base, lower complexity and a reduced attack surface compared to existing solutions. It also gives more space for providing cloud specific optimizations and building a more performant hypervisor for the cloud. Reducing the size and complexity of the code allows for easier review, fuzz testing, modularization and future innovation.

by _wmd 7y ago

jarym 7y ago

Maybe they want to add experimental ideas as a testing ground? I'm sure anything worthwhile could later be upstreamed if necessary?

eatonphil 7y ago

Sounds like what OpenBSD has done with LibreSSL as a slimmed down fork of OpenSSL. Or even OpenBSD itself as a slimmed down fork of NetBSD. Makes sense to me.

MuffinFlavored 7y ago
But now you have a more fragmented BSD market.
- eatonphil 7y ago
  Kinda. Work is frequently shared between the big ones (video and network drivers for instance).
  - MuffinFlavored 7y ago
    but like, how much further along would hard things like video/network drivers be if instead of managing 3 separate "everything else", it was just 1? think of the time and effort in documenting all of their code, compiling, getting hosting set up. bootloaders, different filesystems, different libc implementations, different command line tool implementations. all to have an opinion?
    - ansible 7y ago
      Eh, there are a number of strong personalities involved in all three projects, and they all have their own priorities. So some kind of split was a natural outcome. As a consequence, all three projects have their own focus (formed in part by the existence of the other projects), and that's good too.
    - aquabeagle 7y ago
      all to have an opinion? One could say that about any industry/market. Differences of opinions and beliefs and interests are what create choice and drive innovation.
      - MuffinFlavored 7y ago
        but in the open source software industry, where most people are volunteering, it makes sense to try to be more efficient and not have 100 Linux distributions and 5 BSD flavors or at least, it makes sense to me but I guess contributors are free to spend their time however they please
        yellowapple 7y ago
        OpenBSD and NetBSD have different priorities; NetBSD wants to run on every device possible, while OpenBSD wants to be simple and secure. It'd be more efficient to fork off and let them focus on those priorities (and cross-pollinate where it actually makes sense to cross-pollinate) than to expect those often-conflicting priorities to always have to be balanced throughout the entirety of development. Same goes for Linux distros (albeit to a lesser extent, since "compatibility with software written for bigger distros" tends to be an implicit design goal for smaller distros), or for illumos distros (OpenIndiana is very different from SmartOS).

pm215 7y ago

The NEMU folks did a talk at KVM Forum last year -- the impression I got was that their intent was to use NEMU as a testbed and demo platform of what you could do to produce a slimmed-down version of QEMU, and then as they established workable approaches to then propose/submit them upstream to QEMU piecemeal. On the upstream end, one of the features that landed in 4.0 was a 'Kconfig' system that hopefully will make it easier to build slimline versions of QEMU which don't compile in the kitchen sink.

swiley 7y ago
If you want slimed down qemu on x86 only we already have temu.
- geofft 7y ago
  Can you provide a link to it? Google found http://bitblaze.cs.berkeley.edu/temu.html http://bitblaze.cs.berkeley.edu/temu.html which seems like the wrong thing (it's stuff added to qemu, and it's from 2008). Maybe https://bellard.org/tinyemu/ https://bellard.org/tinyemu/ ? Seems like the right thing but it's not based on qemu I think. Anyone tried it with production workloads? It does seem like it should work - it does KVM and has virtio devices. Although at first glance I don't see either multiple CPU support or live migration support - not having multiple CPU support would basically rule it out for real workloads.
Izmaki 7y ago
I enjoyed that talk a lot. Great speaker and impressive work!

GNOMES 7y ago

I question if this optimized to be ran on top of ClearOS. I agree the RnD would be better for all if they worked with Upstream.

jvanderbot 7y ago

Well, according to them: > Modern guest operating systems that host cloud workloads run on virtual hardware platforms that do not require any legacy hardware. Additonally modern CPUs used in data centers have advanced virtualization features that have eliminated the need for most CPU emulation. > There currently is no open source hypervisor solutions with a clear and narrow focus on running cloud specific workloads on modern CPUs. All available solutions have evolved over time and try to be fairly generic. They attempt to support a wide range of virtual hardware architectures and run on hardware that has varying degree of hardware virtualization support. This results in a need to provide a large set of legacy platforms and device models requiring CPU, device and platform emulation. As a consequence they are built on top of large and complex code bases. > NEMU on the other hand aims to leverage KVM, be narrow focused on exclusively running modern, cloud native workloads, on top of a limited set of hardware architectures and platforms. It assumes fairly recent CPUs and KVM allowing for the the elimination of most emulation logic. > This will allow for smaller code base, lower complexity and a reduced attack surface compared to existing solutions. It also gives more space for providing cloud specific optimizations and building a more performant hypervisor for the cloud. Reducing the size and complexity of the code allows for easier review, fuzz testing, modularization and future innovation.