qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Gleb Natapov
Subject: Re: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt
Date: Mon, 26 Mar 2012 11:53:38 +0200

On Mon, Mar 26, 2012 at 11:08:16AM +0200, Avi Kivity wrote:
> >> 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.
> 
Modularised minimal QEMU may be a good thing, but how -nodefconfig helps
here? Won't you have the same effect if QEMU will load modules on demand,
only when they are actually needed (regardless of -nodefconfig). i.e
virtio-blk is loaded only if there is -device virtio-blk somewhere in
configuration.

> > 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).
> 
What is the reason libvirt uses -nodefconfig instead of -nodefaults now?
What the former does for them that the later doesn't?

--
                        Gleb.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]