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: Andreas Färber
Subject: Re: [Qemu-devel] [PATCH 3/3] qdev: Use qdev_device_add_get_class() for -device <type>, help
Date: Sat, 01 Nov 2014 17:48:19 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0

Am 01.11.2014 um 17:45 schrieb Eduardo Habkost:
> On Sat, Nov 01, 2014 at 05:40:20PM +0100, Andreas Färber wrote:
>> 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()).

Maybe I'm misunderstanding? Does this code path apply only to device_add
(then you are right) or does it also apply to -device?

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



reply via email to

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