qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 3/3] qdev: Use qdev_device_add_get_class() for -


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH 3/3] qdev: Use qdev_device_add_get_class() for -device <type>, help
Date: Sat, 1 Nov 2014 14:45:45 -0200
User-agent: Mutt/1.5.23 (2014-03-12)

On Sat, Nov 01, 2014 at 05:40:20PM +0100, Andreas Färber wrote:
> Hi Eduardo,
> 
> Am 01.11.2014 um 16:56 schrieb Eduardo Habkost:
> > Make sure we try to list properties from classes that can be safely used 
> > with
> > "-device".
> > 
> > Fixes the following crashes:
> > 
> >   $ qemu-system-x86_64 -device x86_64-cpu,help
> >   **
> >   ERROR:qom/object.c:336:object_initialize_with_type: assertion failed: 
> > (type->abstract == false)
> >   Aborted (core dumped)
> >   $ qemu-system-x86_64 -device host-x86_64-cpu,help
> >   qemu-system-x86_64: [...]/target-i386/cpu.c:1329: host_x86_cpu_initfn: 
> > Assertion `(kvm_allowed)' failed.
> >   Aborted (core dumped)
> > 
> > After applying this patch:
> > 
> >   $ qemu-system-x86_64 -device x86_64-cpu,help
> >   Parameter 'driver' expects non-abstract device type
> >   $ qemu-system-x86_64 -device host-x86_64-cpu,help
> >   Parameter 'driver' expects pluggable device type
> > 
> > Signed-off-by: Eduardo Habkost <address@hidden>
> > ---
> >  qdev-monitor.c | 9 +++------
> >  1 file changed, 3 insertions(+), 6 deletions(-)
> > 
> > diff --git a/qdev-monitor.c b/qdev-monitor.c
> > index a9702d8..ebfa701 100644
> > --- a/qdev-monitor.c
> > +++ b/qdev-monitor.c
> > @@ -235,12 +235,9 @@ int qdev_device_help(QemuOpts *opts)
> >          return 0;
> >      }
> >  
> > -    if (!object_class_by_name(driver)) {
> > -        const char *typename = find_typename_by_alias(driver);
> > -
> > -        if (typename) {
> > -            driver = typename;
> > -        }
> > +    qdev_get_device_class(&driver, &local_err);
> > +    if (local_err) {
> > +        goto error;
> >      }
> >  
> >      prop_list = qmp_device_list_properties(driver, &local_err);
> 
> Is dc->cannot_instantiate_with_device_add_yet || (qdev_hotplug &&
> !dc->hotpluggable) really relevant here? Or should that rather remain
> outside the common function in 1/3?

cannot_instantiate_with_device_add_yet makes sure we won't try to
instantiate classes that are not device_add-safe yet (like X86CPU, that
has lots of assumptions and side-effects inside instance_init()).

-- 
Eduardo



reply via email to

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