xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Don Slutz <dslutz@verizon.com>
To: "Andreas Färber" <afaerber@suse.de>, "Don Slutz" <dslutz@verizon.com>
Cc: xen-devel@lists.xensource.com,
	"Michael S. Tsirkin" <mst@redhat.com>,
	qemu-devel@nongnu.org, Anthony Liguori <aliguori@amazon.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [PATCH v3 2/4] GlobalProperty: Display warning about unused -global
Date: Tue, 22 Apr 2014 16:23:59 -0400	[thread overview]
Message-ID: <5356CFDF.7000303@terremark.com> (raw)
In-Reply-To: <53514312.5060705@suse.de>

On 04/18/14 11:21, Andreas Färber wrote:
> Hi Don,
>
> Am 25.03.2014 00:55, schrieb Don Slutz:
>> This can help a user understand why -global was ignored.
>>
>> For example: with "-vga cirrus"; "-global vga.vgamem_mb=16" is just
>> ignored when "-global cirrus-vga.vgamem_mb=16" is not.
>>
>> This is currently clear when the wrong property is provided:
>>
>> out/x86_64-softmmu/qemu-system-x86_64 -global cirrus-vga.vram_size_mb=16 -monitor pty -vga cirrus
>> char device redirected to /dev/pts/20 (label compat_monitor0)
>> qemu-system-x86_64: Property '.vram_size_mb' not found
>> Aborted (core dumped)
>>
>> vs
>>
>> out/x86_64-softmmu/qemu-system-x86_64 -global vga.vram_size_mb=16 -monitor pty -vga cirrus
>> char device redirected to /dev/pts/20 (label compat_monitor0)
>> VNC server running on `::1:5900'
>> ^Cqemu: terminating on signal 2
>>
>> Signed-off-by: Don Slutz <dslutz@verizon.com>
> Improving this is greatly appreciated, thanks.
>
> Now, I can see two ways things can go wrong: a) Mistyping or later
> refactoring devices, or b) user typos or thinkos.
> And four ways to set globals: -global, config file (I hope?), legacy
> command line options (vl.c) and machine .compat_props.
>
> If a property does not exist on the instance of an existing type,
> object_property_parse() will raise an Error and we will abort in
> device_post_init().
>
> What we are silently missing is if a type is misspelled; for that we can
> probably add an Error **errp to the two qdev_prop_register_global*()
> functions - assuming QOM types are already registered at that point.
> qom-test would help us catch any such mistake by instantiating each machine.

I assume you are talking about qdev_prop_register_global() and
qdev_prop_register_global_list().  In my testing I did not see
QOM types being registered at that point.  I may have not been
looking at the right thing.  What I am sure on is that the new
object pc-memory-layout (added in 2/4) is not there just like
TYPE_ICC_BRIDGE at the calls to qdev_prop_register_global*().

Currently I have issues running tests:

dcs-xen-50:~/qemu/out>make test
make -C tests/tcg test
make[1]: Entering directory `/home/don/qemu/out/tests/tcg'
cc -m32 -I/home/don/qemu/tcg -I/home/don/qemu/tcg/i386 -I/home/don/qemu/linux-headers -I/home/don/qemu/out/linux-headers -I. -I/home/don/qemu -I/home/don/qemu/include -I/home/don/qemu/libcacard -I/home/don/qemu/tests/tcg -I. -I../.. -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -Wall -O2 -g -fno-strict-aliasing -c -o test_path.o /home/don/qemu/tests/tcg/test_path.c
In file included from /home/don/qemu/util/cutils.c:25:0,
                  from /home/don/qemu/tests/tcg/test_path.c:4:
/home/don/qemu/include/qemu/host-utils.h: In function 'mulu64':
/home/don/qemu/include/qemu/host-utils.h:35:5: error: unknown type name '__uint128_t'
/home/don/qemu/include/qemu/host-utils.h:35:22: error: '__uint128_t' undeclared (first use in this function)
/home/don/qemu/include/qemu/host-utils.h:35:22: note: each undeclared identifier is reported only once for each function it appears in
...




>
> I note that your proposed check is not failing, but still, with hot-add
> of e.g. PCI devices we might well get a global property default for a
> type that is not instantiated immediately but possibly used later on.

This looks correct to me.  I do not know enough in the area, but
at a quick look, type_register_static() could look at .hotpluggable
and .props.  and maybe do some checking.

>> ---
>>   hw/core/qdev-properties-system.c |  1 +
>>   hw/core/qdev-properties.c        | 15 +++++++++++++++
>>   include/hw/qdev-core.h           |  1 +
>>   include/hw/qdev-properties.h     |  1 +
>>   vl.c                             |  2 ++
>>   5 files changed, 20 insertions(+)
> FWIW I'd prefer "qdev:" for consistency (and yes, it's ambiguous), since
> there are no "GlobalProperty" files or directory.
>

Ok, Will change.

>> diff --git a/hw/core/qdev-properties-system.c b/hw/core/qdev-properties-system.c
>> index de83561..9c742ca 100644
>> --- a/hw/core/qdev-properties-system.c
>> +++ b/hw/core/qdev-properties-system.c
>> @@ -444,6 +444,7 @@ static int qdev_add_one_global(QemuOpts *opts, void *opaque)
>>       g->driver   = qemu_opt_get(opts, "driver");
>>       g->property = qemu_opt_get(opts, "property");
>>       g->value    = qemu_opt_get(opts, "value");
>> +    g->not_used = true;
>>       qdev_prop_register_global(g);
>>       return 0;
>>   }
> IIUC your patch relies on not_used being false in the non-QemuOpts case
> to avoid noise when using -nodefaults or pc*-x.y. Still, the C99 struct
> initializations elsewhere get that field as well, hmm. An alternative
> would be a separate linked list for user-supplied globals.
>

Yes, a separate linked list could be used.  Did not look at
doing this.  Mostly since struct init will always set not_used to false.


>> diff --git a/hw/core/qdev-properties.c b/hw/core/qdev-properties.c
>> index c67acf5..437c008 100644
>> --- a/hw/core/qdev-properties.c
>> +++ b/hw/core/qdev-properties.c
>> @@ -951,6 +951,20 @@ void qdev_prop_register_global_list(GlobalProperty *props)
>>       }
>>   }
>>   
>> +void qdev_prop_check_global(void)
>> +{
>> +    GlobalProperty *prop;
>> +
>> +    QTAILQ_FOREACH(prop, &global_props, next) {
>> +        if (!prop->not_used) {
>> +            continue;
>> +        }
>> +        fprintf(stderr, "Warning: \"-global %s.%s=%s\" not used\n",
>> +                prop->driver, prop->property, prop->value);
>> +
>> +    }
>> +}
>> +
>>   void qdev_prop_set_globals_for_type(DeviceState *dev, const char *typename,
>>                                       Error **errp)
>>   {
>> @@ -962,6 +976,7 @@ void qdev_prop_set_globals_for_type(DeviceState *dev, const char *typename,
>>           if (strcmp(typename, prop->driver) != 0) {
>>               continue;
>>           }
>> +        prop->not_used = false;
>>           object_property_parse(OBJECT(dev), prop->value, prop->property, &err);
>>           if (err != NULL) {
>>               error_propagate(errp, err);
>> diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
>> index dbe473c..131fb49 100644
>> --- a/include/hw/qdev-core.h
>> +++ b/include/hw/qdev-core.h
>> @@ -235,6 +235,7 @@ typedef struct GlobalProperty {
>>       const char *driver;
>>       const char *property;
>>       const char *value;
>> +    bool not_used;
>>       QTAILQ_ENTRY(GlobalProperty) next;
>>   } GlobalProperty;
>>   
>> diff --git a/include/hw/qdev-properties.h b/include/hw/qdev-properties.h
>> index c46e908..fbca313 100644
>> --- a/include/hw/qdev-properties.h
>> +++ b/include/hw/qdev-properties.h
>> @@ -180,6 +180,7 @@ void qdev_prop_set_ptr(DeviceState *dev, const char *name, void *value);
>>   
>>   void qdev_prop_register_global(GlobalProperty *prop);
>>   void qdev_prop_register_global_list(GlobalProperty *props);
>> +void qdev_prop_check_global(void);
>>   void qdev_prop_set_globals(DeviceState *dev, Error **errp);
>>   void qdev_prop_set_globals_for_type(DeviceState *dev, const char *typename,
>>                                       Error **errp);
>> diff --git a/vl.c b/vl.c
>> index acd97a8..61fac1b 100644
>> --- a/vl.c
>> +++ b/vl.c
>> @@ -4490,6 +4490,8 @@ int main(int argc, char **argv, char **envp)
>>           }
>>       }
>>   
>> +    qdev_prop_check_global();
> I have some doubts about this placement. A machine init done notifier
> might avoid touching vl.c by leaving it in qdev-properties.c. It happens
> to be after that point as is, but later refactorings wrt QOM realize or
> unrelated issues might change that.

Yes,  This was the best place I found for it.  I am happy to move
if that makes sense.

    -Don Slutz

>> +
>>       if (incoming) {
>>           Error *local_err = NULL;
>>           qemu_start_incoming_migration(incoming, &local_err);
> Regards,
> Andreas
>

  parent reply	other threads:[~2014-04-22 20:23 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-24 23:55 [PATCH v3 0/4] Add max-ram-below-4g (was Add pci_hole_min_size machine option) Don Slutz
2014-03-24 23:55 ` [PATCH v3 1/4] xen-all: Fix xen_hvm_init() to adjust pc memory layout Don Slutz
2014-04-18 14:23   ` Andreas Färber
2014-04-22 16:29     ` Don Slutz
2014-03-24 23:55 ` [PATCH v3 2/4] GlobalProperty: Display warning about unused -global Don Slutz
2014-04-18 15:21   ` Andreas Färber
2014-04-18 15:36     ` [Xen-devel] " Fabio Fantoni
2014-04-18 15:59       ` Andreas Färber
2014-04-18 16:54         ` Fabio Fantoni
2014-04-19 10:56           ` Fabio Fantoni
2014-04-22 18:44             ` Don Slutz
2014-04-19 20:54     ` Paolo Bonzini
2014-04-22 23:13       ` Don Slutz
2014-04-23  0:28         ` Paolo Bonzini
2014-04-23 12:58           ` Don Slutz
2014-04-23 13:33         ` Andreas Färber
2014-04-22 20:23     ` Don Slutz [this message]
2014-04-23  0:28       ` Paolo Bonzini
2014-04-23 13:25         ` Don Slutz
2014-03-24 23:55 ` [PATCH v3 3/4] pc & q35: Add new object pc-memory-layout Don Slutz
2014-04-18 15:45   ` Andreas Färber
2014-04-22 23:54     ` Don Slutz
2014-04-21 12:27   ` Paolo Bonzini
2014-04-23  0:13     ` Don Slutz
2014-04-23  3:27       ` Paolo Bonzini
2014-04-23  6:51       ` Marcel Apfelbaum
2014-03-24 23:55 ` [PATCH v3 4/4] xen-all: Pass max_ram_below_4g to xen_hvm_init Don Slutz
2014-03-25 11:17   ` Stefano Stabellini
2014-04-18 16:19   ` Andreas Färber
2014-04-22 18:27     ` Don Slutz
2014-03-25  9:08 ` [PATCH v3 0/4] Add max-ram-below-4g (was Add pci_hole_min_size machine option) Michael S. Tsirkin
2014-04-17 18:27   ` PING " Don Slutz
2014-04-18 14:10   ` Andreas Färber
2014-04-22 16:31     ` Don Slutz
2014-05-05  8:12       ` [Qemu-devel] " Michael S. Tsirkin
2014-05-05 16:16         ` Don Slutz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5356CFDF.7000303@terremark.com \
    --to=dslutz@verizon.com \
    --cc=afaerber@suse.de \
    --cc=aliguori@amazon.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).