Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt

>> Exactly. The types are no different, so there's no reason to >> discriminate against types that happen to live in qemu-provided data >> files vs. qemu code. They aren't instantiated, so we lose nothing by >> creating the factories (just so long as the factories aren't >> mass-producing objects). > > > At some point, I'd like to have type modules that are shared objects. > I'd like QEMU to start with almost no builtin types and allow the user > to configure which modules get loaded. > > In the long term, I'd like QEMU to be a small, robust core with the > vast majority of code relegated to modules with the user ultimately in > control of module loading. > > Yes, I'd want some module autoloading system but there should always > be a way to launch QEMU without loading any modules and then load a > very specific set of modules (as defined by the user). > > You can imagine this being useful for something like Common Criteria > certifications. Okay.

> It's obviously defined for a given release, just not defined long term. > >> If I see something like -nodefconfig, I assume it will create a bare >> bones guest that will not depend on any qemu defaults and will be stable >> across releases. > > That's not even close to what -nodefconfig is. That's pretty much > what -nodefaults is but -nodefaults has also had a fluid definition > historically. Okay. Let's just make sure to document -nodefconfig as version specific and -nodefaults as the stable way to create a bare bones guest (and define exactly what that means).