[Qemu-devel] [PATCH RFC] qmp, target-i386: device_list_properties for TYPE_CPU

2016-02-12 Thread Valentin Rakush 
This is RFC because there is another implementation option: it is
possible to implement this functionality in the object_finalize for
all available targets. All targets change will require more testing.
Please let me know if all targets should be changed at once.

This patch changes qmp_device_list_properties and only target-i386
to allow TYPE_CPU class properties to be quered with QMP interface and
with -device core2duo-x86_64-cpu,help command line.

Signed-off-by: Valentin Rakush <valentin.rak...@gmail.com>
Cc: Luiz Capitulino <lcapitul...@redhat.com>
Cc: Eric Blake <ebl...@redhat.com>
Cc: Markus Armbruster <arm...@redhat.com>
Cc: Andreas Färber <afaer...@suse.de>
Cc: Daniel P. Berrange <berra...@redhat.com>
Cc: Eduardo Habkost <ehabk...@redhat.com>
---
 qmp.c | 19 +++
 target-i386/cpu.c | 32 ++--
 2 files changed, 49 insertions(+), 2 deletions(-)

diff --git a/qmp.c b/qmp.c
index 6ae7230..2721f16 100644
--- a/qmp.c
+++ b/qmp.c
@@ -516,6 +516,7 @@ DevicePropertyInfoList *qmp_device_list_properties(const 
char *typename,
Error **errp)
 {
 ObjectClass *klass;
+ObjectClass *cpu_klass;
 Object *obj;
 ObjectProperty *prop;
 ObjectPropertyIterator iter;
@@ -580,6 +581,24 @@ DevicePropertyInfoList *qmp_device_list_properties(const 
char *typename,
 prop_list = entry;
 }
 
+cpu_klass = object_class_dynamic_cast(klass, TYPE_CPU);
+if (cpu_klass) {
+CPUState *tmp_cpu = CPU(obj);
+CPUState *cs = first_cpu;
+
+CPU_FOREACH(cs) {
+if (tmp_cpu->cpu_index == cs->cpu_index) {
+#if defined(CONFIG_USER_ONLY)
+cpu_list_lock();
+#endif
+QTAILQ_REMOVE(, cs, node);
+#if defined(CONFIG_USER_ONLY)
+cpu_list_unlock();
+#endif
+}
+}
+}
+
 object_unref(obj);
 
 return prop_list;
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 3fa14bf..8c32794 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -1479,7 +1479,7 @@ static void host_x86_cpu_class_init(ObjectClass *oc, void 
*data)
 
 dc->props = host_x86_cpu_properties;
 /* Reason: host_x86_cpu_initfn() dies when !kvm_enabled() */
-dc->cannot_destroy_with_object_finalize_yet = true;
+dc->cannot_destroy_with_object_finalize_yet = false;
 }
 
 static void host_x86_cpu_initfn(Object *obj)
@@ -3225,11 +3225,39 @@ static void x86_cpu_common_class_init(ObjectClass *oc, 
void *data)
 cc->cpu_exec_enter = x86_cpu_exec_enter;
 cc->cpu_exec_exit = x86_cpu_exec_exit;
 
+object_class_property_add(oc, "family", "int",
+x86_cpuid_version_get_family,
+x86_cpuid_version_set_family, NULL, NULL, NULL);
+object_class_property_add(oc, "model", "int",
+x86_cpuid_version_get_model,
+x86_cpuid_version_set_model, NULL, NULL, NULL);
+object_class_property_add(oc, "stepping", "int",
+x86_cpuid_version_get_stepping,
+x86_cpuid_version_set_stepping, NULL, NULL, NULL);
+object_class_property_add_str(oc, "vendor",
+x86_cpuid_get_vendor,
+x86_cpuid_set_vendor, NULL);
+object_class_property_add_str(oc, "model-id",
+x86_cpuid_get_model_id,
+x86_cpuid_set_model_id, NULL);
+object_class_property_add(oc, "tsc-frequency", "int",
+x86_cpuid_get_tsc_freq,
+x86_cpuid_set_tsc_freq, NULL, NULL, NULL);
+object_class_property_add(oc, "apic-id", "int",
+x86_cpuid_get_apic_id,
+x86_cpuid_set_apic_id, NULL, NULL, NULL);
+object_class_property_add(oc, "feature-words", "X86CPUFeatureWordInfo",
+x86_cpu_get_feature_words,
+NULL, NULL, NULL, NULL);
+object_class_property_add(oc, "filtered-features", "X86CPUFeatureWordInfo",
+x86_cpu_get_feature_words,
+NULL, NULL, NULL, NULL);
+
 /*
  * Reason: x86_cpu_initfn() calls cpu_exec_init(), which saves the
  * object in cpus -> dangling pointer after final object_unref().
  */
-dc->cannot_destroy_with_object_finalize_yet = true;
+dc->cannot_destroy_with_object_finalize_yet = false;
 }
 
 static const TypeInfo x86_cpu_type_info = {
-- 
1.8.3.1

Re: [Qemu-devel] [PATCH v5] qom, qmp, hmp, qapi: create qom-type-prop-list for class properties

2016-02-07 Thread Valentin Rakush 
Hi Eduardo,

thank you for your explanations.

> You don't have to, if you just do object_new() like
> qmp_device_list_properties() does. Both ObjectClass::properties
> and DeviceClas::props are translated to object instance
> properties (Object::properties).

I should foresee these. Qemu has the object oriented approach implemented
in C.
I missed this point. Thank you for explanation.

I did the following changes in the target-i386/cpu.c

 dc->props = host_x86_cpu_properties;
 /* Reason: host_x86_cpu_initfn() dies when !kvm_enabled() */
-dc->cannot_destroy_with_object_finalize_yet = true;
+dc->cannot_destroy_with_object_finalize_yet = false;

and

 /*
  * Reason: x86_cpu_initfn() calls cpu_exec_init(), which saves the
  * object in cpus -> dangling pointer after final object_unref().
  */
-dc->cannot_destroy_with_object_finalize_yet = true;
+dc->cannot_destroy_with_object_finalize_yet = false;

and now I can add class properties to the target-i386/cpu.c from this patch
http://lists.nongnu.org/archive/html/qemu-devel/2015-08/msg03117.html
and then command "qemu-system-x86_64 -device core2duo-x86_64-cpu,help"
will show me the class properties.

However according to this patch
http://lists.nongnu.org/archive/html/qemu-devel/2015-10/msg05013.html
I am checking how to make cpu class not to fail in device-list-properties
call
throught QMP interface.

Basically my goal is to put class properties into the target-i386/cpu.c and
print them when necessary. And after our discussion
qmp_device_list_properties
is a already available for this but cannot_destroy_with_object_finalize_yet
flag should be set to false.

Please let me know if this is wrong approach.

Thank you,
Valentin

On Tue, Feb 2, 2016 at 6:55 PM, Eduardo Habkost <ehabk...@redhat.com> wrote:

> On Sun, Jan 31, 2016 at 04:40:54PM +0300, Valentin Rakush wrote:
> > Hi Eduardo,
> >
> > I will try to answer some of your questions at this email and will answer
> > other questions later.
> >
> > > Can you clarify what you mean by "TYPE_DEVICE has its own
> > > properties"? TYPE_DEVICE properties are registered as normal QOM
> > > properties.
> >
> > It is possible that I do not understand object model correctly
> >
> > This commit 16bf7f522a2f adds GHashTable *properties; to the ObjectClass
> > struct in the include/qom/object.h
> > The typedef struct DeviceClass from include/hw/qdev-core.h is inherited
> > from ObjectClass. Also DeviceClass has it own properties
> > Property *props.
> >
> > In the device_list_properties we call
> >
> > static DevicePropertyInfo *make_device_property_info
> >
> > Which tries to downcast class to DEVICE_CLASS
> >
> > for (prop = DEVICE_CLASS(klass)->props; prop && prop->name; prop++) {
> >
> > So we are using Property *props, defined in the DeviceClass, but we do
> not
> > use GHashTable * properties, defined in the ObjectClass. Here I mean that
> > DeviceClass has its own properties.
>
> Oh, I misunderstood you. I was talking about object properties,
> the ones at Object::properties. Yes, in this case we have
> duplication between DeviceClass::props and
> ObjectClass::properties.
>
> >
> > > I don't understand what you mean, here. GlobalProperties are not
> > > machine properties, they are just property=value pairs to be
> > > registered as global properties. They are unrelated to the
> > > properties TYPE_MACHINE actually has.
> >
> > Same here. The struct MachineClass is defined in the include/hw/boards.h
> It
> > has a member GlobalProperty *compat_props;
> > But after commit 16bf7f522a2f it would be better to use ObjectClass
> > properties. IMHO. I did not check how compat_props are used in the code
> yet.
>
> In this case it's different: ObjectClass::compat_props are not
> machine properties. They are just property=value pairs to be
> registered as global properties when running the machine. They
> will never appear in qom-type-prop-list because they are a
> completely different thing.
>
> >
> > > Could you clarify what you mean by "process different classes
> > > differently"?
> >
> > In the list_device_properties function we should have several conditional
> > statements like
> >
> > if (machine = object_class_dynamic_cast(class, TYPE_MACHINE)) {
> > /* process machine properties using MachineClass GlobalProperty
> > *compat_props; */
> > }
> > else if (machine = object_class_dynamic_cast(class, TYPE_DEVICE)) {
> > /* process device class properties, using DeviceClass Property *props; */
> > }
> > else if

Re: [Qemu-devel] [PATCH v5] qom, qmp, hmp, qapi: create qom-type-prop-list for class properties

2016-01-31 Thread Valentin Rakush 
Hi Eduardo,

I will try to answer some of your questions at this email and will answer
other questions later.

> Can you clarify what you mean by "TYPE_DEVICE has its own
> properties"? TYPE_DEVICE properties are registered as normal QOM
> properties.

It is possible that I do not understand object model correctly

This commit 16bf7f522a2f adds GHashTable *properties; to the ObjectClass
struct in the include/qom/object.h
The typedef struct DeviceClass from include/hw/qdev-core.h is inherited
from ObjectClass. Also DeviceClass has it own properties
Property *props.

In the device_list_properties we call

static DevicePropertyInfo *make_device_property_info

Which tries to downcast class to DEVICE_CLASS

for (prop = DEVICE_CLASS(klass)->props; prop && prop->name; prop++) {

So we are using Property *props, defined in the DeviceClass, but we do not
use GHashTable * properties, defined in the ObjectClass. Here I mean that
DeviceClass has its own properties.

> I don't understand what you mean, here. GlobalProperties are not
> machine properties, they are just property=value pairs to be
> registered as global properties. They are unrelated to the
> properties TYPE_MACHINE actually has.

Same here. The struct MachineClass is defined in the include/hw/boards.h It
has a member GlobalProperty *compat_props;
But after commit 16bf7f522a2f it would be better to use ObjectClass
properties. IMHO. I did not check how compat_props are used in the code yet.

> Could you clarify what you mean by "process different classes
> differently"?

In the list_device_properties function we should have several conditional
statements like

if (machine = object_class_dynamic_cast(class, TYPE_MACHINE)) {
/* process machine properties using MachineClass GlobalProperty
*compat_props; */
}
else if (machine = object_class_dynamic_cast(class, TYPE_DEVICE)) {
/* process device class properties, using DeviceClass Property *props; */
}
else if (machine = object_class_dynamic_cast(class, TYPE_CPU)) {
/* process CPU, using ObjectClass GHashTable *properties; */
}

> 5) -cpu options:
>
> Ditto. the list will be incomplete unless all CPU subclasses are
> converted to use only class-properties, or the new command uses
> object_new().

This is a use case that I initially tried to implement.

Regards,
Valentin

On Fri, Jan 29, 2016 at 6:28 PM, Eduardo Habkost <ehabk...@redhat.com>
wrote:

> On Fri, Jan 29, 2016 at 01:03:38PM +0300, Valentin Rakush wrote:
> > Hi Eduardo, hi Daniel,
> >
> > I checked most of the classes that are used for x86_64 qemu simulation
> with
> > this command line:
> > x86_64-softmmu/qemu-system-x86_64 -qmp tcp:localhost:,server,nowait
> > -machine pc -cpu core2duo
> >
> > Here are some of the classes that cannot provide properties with
> > device_list_properties call:
> > /object/machine/generic-pc-machine/pc-0.13-machine
> > /object/bus/i2c-bus
> > /interface/user-creatable
> > /object/tls-creds/tls-creds-anon
> > /object/memory-backend/memory-backend-file
> > /object/qemu:memory-region
> > /object/rng-backend/rng-random
> > /object/tpm-backend/tpm-passthrough
> > /object/tls-creds/tls-creds-x509
> > /object/secret
> >
> > They cannot provide properties because these classes cannot be casted to
> > TYPE_DEVICE. This is done intentionally because TYPE_DEVICE has its own
> > properties.
>
> Can you clarify what you mean by "TYPE_DEVICE has its own
> properties"? TYPE_DEVICE properties are registered as normal QOM
> properties.
>
> We can still add a new command that's not specific for
> TYPE_DEVICE (if necessary). The point is that it shouldn't return
> arbitrarily different (and incomplete) data from the existing
> mechanism to list properties.
>
> In other words, I don't see why the output of "qom-type-prop-list
> " can't be as good as the output of "device-list-properties
> ". If we make return only class-properties, it will be less
> complete and less useful.
>
>
> > Also TYPE_MACHINE has own properties of type GlobalProperty.
>
> I don't understand what you mean, here. GlobalProperties are not
> machine properties, they are just property=value pairs to be
> registered as global properties. They are unrelated to the
> properties TYPE_MACHINE actually has.
>
> > Here are two ways (AFAICS):
> > - we refactor TYPE_DEVICE and TYPE_MACHINE so they store their properties
> > in the ObjectClass properties.
>
> Too many classes need to be converted. We would still need
> something to use during the transiation.
>
> > - we change device_list_properties so it process different classes
> > differently.
>
> Could you clarify what you mean by "process dif

Re: [Qemu-devel] [PATCH v5] qom, qmp, hmp, qapi: create qom-type-prop-list for class properties

2016-01-29 Thread Valentin Rakush 
Hi Eduardo, hi Daniel,

I checked most of the classes that are used for x86_64 qemu simulation with
this command line:
x86_64-softmmu/qemu-system-x86_64 -qmp tcp:localhost:,server,nowait
-machine pc -cpu core2duo

Here are some of the classes that cannot provide properties with
device_list_properties call:
/object/machine/generic-pc-machine/pc-0.13-machine
/object/bus/i2c-bus
/interface/user-creatable
/object/tls-creds/tls-creds-anon
/object/memory-backend/memory-backend-file
/object/qemu:memory-region
/object/rng-backend/rng-random
/object/tpm-backend/tpm-passthrough
/object/tls-creds/tls-creds-x509
/object/secret

They cannot provide properties because these classes cannot be casted to
TYPE_DEVICE. This is done intentionally because TYPE_DEVICE has its own
properties. Also TYPE_MACHINE has own properties of type GlobalProperty.
Here are two ways (AFAICS):
- we refactor TYPE_DEVICE and TYPE_MACHINE so they store their properties
in the ObjectClass properties.
- we change device_list_properties so it process different classes
differently.

The disadvantage of the second approach, is that it is complicating code in
favor of simplifying qapi interface. I like first approach with
refactoring, although it is more complex. The first approach should put all
properties in the base classes and then use this properties everywhere
(command line help, qmp etc.) The simplest way the refactoring can be done,
is by moving TYPE_DEVICE properties to ObjectClass and merging them somehow
with TYPE_MACHINE GlobalProperty. Then we will use these properties for all
other types of classes.

Of course, we can leave device_list_properties as it is and use
qom-type-prop-list instead.

What do you think? Does these design options make sense for you?


Thank you,
Valentin






On Wed, Jan 27, 2016 at 6:23 PM, Daniel P. Berrange <berra...@redhat.com>
wrote:

> On Wed, Jan 27, 2016 at 01:09:37PM -0200, Eduardo Habkost wrote:
> > On Tue, Jan 26, 2016 at 10:19:13PM +, Daniel P. Berrange wrote:
> > > On Tue, Jan 26, 2016 at 03:26:35PM -0200, Eduardo Habkost wrote:
> > > > On Tue, Jan 26, 2016 at 03:51:21PM +, Daniel P. Berrange wrote:
> > > > > On Tue, Jan 26, 2016 at 01:35:38PM -0200, Eduardo Habkost wrote:
> > > > > > On Mon, Jan 25, 2016 at 11:24:47AM +0300, Valentin Rakush wrote:
> > > > > > > This patch adds support for qom-type-prop-list command to list
> object
> > > > > > > class properties. A later patch will use this functionality to
> > > > > > > implement x86_64-cpu properties.
> > > > > > >
> > > > > > > Signed-off-by: Valentin Rakush <valentin.rak...@gmail.com>
> > > > > > > Cc: Luiz Capitulino <lcapitul...@redhat.com>
> > > > > > > Cc: Eric Blake <ebl...@redhat.com>
> > > > > > > Cc: Markus Armbruster <arm...@redhat.com>
> > > > > > > Cc: Andreas Färber <afaer...@suse.de>
> > > > > > > Cc: Daniel P. Berrange <berra...@redhat.com>
> > > > > > > Cc: Eduardo Habkost <ehabk...@redhat.com>
> > > > > > > ---
> > > > > > [...]
> > > > > > > diff --git a/qmp.c b/qmp.c
> > > > > > > index 53affe2..baf25c0 100644
> > > > > > > --- a/qmp.c
> > > > > > > +++ b/qmp.c
> > > > > > > @@ -460,6 +460,37 @@ ObjectTypeInfoList
> *qmp_qom_list_types(bool has_implements,
> > > > > > >  return ret;
> > > > > > >  }
> > > > > > >
> > > > > > > +ObjectPropertyInfoList *qmp_qom_type_prop_list(const char
> *typename, Error **errp)
> > > > > > > +{
> > > > > > > +ObjectClass *klass;
> > > > > > > +ObjectPropertyInfoList *props = NULL;
> > > > > > > +ObjectProperty *prop;
> > > > > > > +ObjectPropertyIterator iter;
> > > > > > > +
> > > > > > > +klass = object_class_by_name(typename);
> > > > > > > +if (!klass) {
> > > > > > > +error_set(errp, ERROR_CLASS_DEVICE_NOT_FOUND,
> > > > > > > +  "Object class '%s' not found", typename);
> > > > > > > +return NULL;
> > > > > > > +}
> > > > > > > +
> > > > > > > +object_class_property_iter_init(, klass);
> > > > > > > +while ((prop = object_property_iter_next())) {
> > > > > > > +ObjectPropertyInfoList *entry

Re: [Qemu-devel] [PATCH v5] qom, qmp, hmp, qapi: create qom-type-prop-list for class properties

2016-01-27 Thread Valentin Rakush 
Hi all,

My five cents... I am checking for possible problems in case we want to
use qmp_device_list_properties() for listing all class properties. Here are
couple concerns:

- for example, we want to list class properties for "pc-q35-2.4-machine"
typename. This is not DeviceClass, therefore we have to change
qmp_device_list_properties to accept all classes. From another side,
qmp_device_list_properties is used for "-device FOO,help" (as far as I
understand from comments in qdev-core.h). Then use case "-device FOO,help"
will lose typecheck for DeviceClass. We will probably need a separate
implementation of '-device FOO,help' to check/assert command parameters.

- if we willl use qmp_device_list_properties to list properties of all
classes, then perhaps we should rename this function to something like
qmp_type_list_properties. In this case we should refactor source code that
already uses qmp_device_list_properties. For example, libvirt is already
uses device-list-properties command.

I will do more research.

Regards,
Valentin

On Wed, Jan 27, 2016 at 1:19 AM, Daniel P. Berrange <berra...@redhat.com>
wrote:

> On Tue, Jan 26, 2016 at 03:26:35PM -0200, Eduardo Habkost wrote:
> > On Tue, Jan 26, 2016 at 03:51:21PM +, Daniel P. Berrange wrote:
> > > On Tue, Jan 26, 2016 at 01:35:38PM -0200, Eduardo Habkost wrote:
> > > > On Mon, Jan 25, 2016 at 11:24:47AM +0300, Valentin Rakush wrote:
> > > > > This patch adds support for qom-type-prop-list command to list
> object
> > > > > class properties. A later patch will use this functionality to
> > > > > implement x86_64-cpu properties.
> > > > >
> > > > > Signed-off-by: Valentin Rakush <valentin.rak...@gmail.com>
> > > > > Cc: Luiz Capitulino <lcapitul...@redhat.com>
> > > > > Cc: Eric Blake <ebl...@redhat.com>
> > > > > Cc: Markus Armbruster <arm...@redhat.com>
> > > > > Cc: Andreas Färber <afaer...@suse.de>
> > > > > Cc: Daniel P. Berrange <berra...@redhat.com>
> > > > > Cc: Eduardo Habkost <ehabk...@redhat.com>
> > > > > ---
> > > > [...]
> > > > > diff --git a/qmp.c b/qmp.c
> > > > > index 53affe2..baf25c0 100644
> > > > > --- a/qmp.c
> > > > > +++ b/qmp.c
> > > > > @@ -460,6 +460,37 @@ ObjectTypeInfoList *qmp_qom_list_types(bool
> has_implements,
> > > > >  return ret;
> > > > >  }
> > > > >
> > > > > +ObjectPropertyInfoList *qmp_qom_type_prop_list(const char
> *typename, Error **errp)
> > > > > +{
> > > > > +ObjectClass *klass;
> > > > > +ObjectPropertyInfoList *props = NULL;
> > > > > +ObjectProperty *prop;
> > > > > +ObjectPropertyIterator iter;
> > > > > +
> > > > > +klass = object_class_by_name(typename);
> > > > > +if (!klass) {
> > > > > +error_set(errp, ERROR_CLASS_DEVICE_NOT_FOUND,
> > > > > +  "Object class '%s' not found", typename);
> > > > > +return NULL;
> > > > > +}
> > > > > +
> > > > > +object_class_property_iter_init(, klass);
> > > > > +while ((prop = object_property_iter_next())) {
> > > > > +ObjectPropertyInfoList *entry =
> g_new0(ObjectPropertyInfoList, 1);
> > > > > +
> > > > > +if (entry) {
> > > > > +entry->value = g_new0(ObjectPropertyInfo, 1);
> > > > > +entry->next = props;
> > > > > +props = entry;
> > > > > +
> > > > > +entry->value->name = g_strdup(prop->name);
> > > > > +entry->value->type = g_strdup(prop->type);
> > > > > +}
> > > > > +}
> > > > > +
> > > > > +return props;
> > > > > +}
> > > > > +
> > > >
> > > > We already have "-device ,help", and it uses a completely
> > > > different mechanism for listing properties. There's no reason for
> > > > having two arbitrarily different APIs for listing properties
> > > > returning different results.
> > > >
> > > > If qmp_device_list_properties() is not enough for you, please
> > > > clarify why, so we can consider improving it.
> > >
> > > qmp_device_list_properties() has t

Re: [Qemu-devel] [PATCH v4] qom, qmp, hmp, qapi: create qom-type-prop-list for class properties

2016-01-26 Thread Valentin Rakush 
Hi Eric,

On Mon, Jan 25, 2016 at 8:43 PM, Eric Blake <ebl...@redhat.com> wrote:

> On 01/22/2016 01:20 PM, Valentin Rakush wrote:
> > Hi Eric, hi Daniel,
> >
> > Re dashes in the command name
> >
> > AFAICC, the QOM related command in HMP use dash "-". For example,
> qom-list
> > and qom-set. If we will change dash "-" to underscore "_" then
> > qom_type_prop_list will be consistent with old HMP commands (created
> before
> > year 2013), but will _not_ be consistent with QOM commands created after
> > 2013. Which is not nice and may be misleading.
>
> Well, HMP is not set in stone. We can rename the HMP command to qom_list
> and qom_set, if we want consistency so that _all_ HMP commands prefer _.
>
> >
> > If we want to have consistent naming of all HMP commands, then we should
> > rename all QOM commands to replace "-" to "_". But in this case we can
> > brake compatibility in possible scripts that already use these commands.
> > For example, scripts/qmp/qom-fuse
>
> Any script using HMP is already broken, because HMP is not designed for
> scriptability.  Scripts should be using QMP, and QMP has stricter rules
> about not arbitrarily changing names.
>
>
The HMP and QMP has same command qom-list. When I searched for this command
then I found that it is used in scripts (QMP only) and did not look
further. My fault.
Thank you for explanations.


> >
> > I would leave name qom-type-prop-list with dashes, so it will be
> consistent
> > with other two QOM commands and would refactor all QOM commands names if
> > possible.
>
> I'm not asking you to change the QMP name, just the HMP name.
>
> >
> > Re subcommand of the info command
> >
> > Also from hmp-command.hx I can see that info command shows various
> > information about the _system_state_ The qom-type-prop-list shows
> > properties of the class type. They can be changed during runtime, but I
> am
> > not sure if they can be referred as a system state. From another side
> > command like "info class x86_64-cpu" could take less typing, but this
> will
> > be inconsistent with QMP version of the command.
>
> We aren't aiming for equivalence between QMP and HMP.  It's fine for the
> HMP command to be higher-level, have more smarts, and have more
> consistency with other HMP commands.
>
> >
> > For this reasons I would leave qom-type-prop-list as it is right now.
>
> Since HMP is not scriptable, I am not going to hold up the patch on
> bikeshedding how the HMP command is spelled.  I just wanted to point out
> the difference in conventions, and that you are adding an exception to
> the conventions.
>

The qom-list breaks this conventions and this is why I did mistake when
implemented qom-type-prop-list.


> >
> > Daniel have reviewed this patch already but found my error in the
> > parameters of the HMP command. I have fixed this error and tested command
> > with monitor.  But would it be ok to add QMP and HMP tests to this patch?
> > Or may be submit tests with another patch, because this one is already
> > reviewed? I do not see much QMP/HMP tests so I am hesitating if this is a
> > good idea.
>
> Another idea is to add ONLY a QMP command, and omit the functionality
> from HMP altogether.  If someone finds the HMP interface important, they
> can submit a later patch to add it on top of the QMP command.
>

There were no requirements to add HMP command, but I was implementing
qom-type-prop-list based on the qom-list (as an example). The qom-list
command
has QMP and HMP commands which spells similar and this is a reason why
I implemented HMP version of the qom-type-prop-list.

Because there were no such requirement to add HMP qom-type-prop-list
command
I think it would be better to remove HMP version of qom-type-prop-list. I
will do this in
next version of this patch.

Thank you.


> --
> Eric Blake   eblake redhat com+1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>
>


-- 
Best Regards,
Valentin Rakush.

[Qemu-devel] [PATCH v5] qom, qmp, hmp, qapi: create qom-type-prop-list for class properties

2016-01-25 Thread Valentin Rakush 
This patch adds support for qom-type-prop-list command to list object
class properties. A later patch will use this functionality to
implement x86_64-cpu properties.

Signed-off-by: Valentin Rakush <valentin.rak...@gmail.com>
Cc: Luiz Capitulino <lcapitul...@redhat.com>
Cc: Eric Blake <ebl...@redhat.com>
Cc: Markus Armbruster <arm...@redhat.com>
Cc: Andreas Färber <afaer...@suse.de>
Cc: Daniel P. Berrange <berra...@redhat.com>
Cc: Eduardo Habkost <ehabk...@redhat.com>
---
V5: fixes after scripts/checkpatch.pl
V4: review fixes
 - the typename argument in the hmp command changed to be mandatory
V3: commit message fix
 - commit message changed to reflect actual command name
V2: Fixes after first review
 - changed command name from qom-type-list to qom-type-prop-list
 - changed memory allocation from g_malloc0 to g_new0
 - changed parameter name from path to typename
 - fixed wordings and comments
 - fixed source code formatting
 - registered the command in monitor

 hmp-commands.hx  | 13 +
 hmp.c| 21 +
 hmp.h|  1 +
 include/qom/object.h | 31 +++
 qapi-schema.json | 19 +++
 qmp-commands.hx  |  6 ++
 qmp.c| 31 +++
 qom/object.c |  7 +++
 8 files changed, 129 insertions(+)

diff --git a/hmp-commands.hx b/hmp-commands.hx
index bb52e4d..ee4d1e2 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1734,6 +1734,19 @@ Print QOM properties of object at location @var{path}
 ETEXI
 
 {
+.name   = "qom-type-prop-list",
+.args_type  = "typename:s",
+.params = "typename",
+.help   = "list QOM class properties",
+.mhandler.cmd  = hmp_qom_type_prop_list,
+},
+
+STEXI
+@item qom-type-prop-list [@var{typename}]
+Print QOM properties of the type @var{typename}
+ETEXI
+
+{
 .name   = "qom-set",
 .args_type  = "path:s,property:s,value:s",
 .params = "path property value",
diff --git a/hmp.c b/hmp.c
index 54f2620..6de9bf0 100644
--- a/hmp.c
+++ b/hmp.c
@@ -2052,6 +2052,27 @@ void hmp_qom_list(Monitor *mon, const QDict *qdict)
 hmp_handle_error(mon, );
 }
 
+void hmp_qom_type_prop_list(Monitor *mon, const QDict *qdict)
+{
+const char *typename = qdict_get_try_str(qdict, "typename");
+ObjectPropertyInfoList *list;
+Error *err = NULL;
+
+list = qmp_qom_type_prop_list(typename, );
+if (!err) {
+ObjectPropertyInfoList *start = list;
+while (list) {
+ObjectPropertyInfo *value = list->value;
+
+monitor_printf(mon, "%s (%s)\n",
+   value->name, value->type);
+list = list->next;
+}
+qapi_free_ObjectPropertyInfoList(start);
+}
+hmp_handle_error(mon, );
+}
+
 void hmp_qom_set(Monitor *mon, const QDict *qdict)
 {
 const char *path = qdict_get_str(qdict, "path");
diff --git a/hmp.h b/hmp.h
index a8c5b5a..8c12ebe 100644
--- a/hmp.h
+++ b/hmp.h
@@ -103,6 +103,7 @@ void hmp_object_del(Monitor *mon, const QDict *qdict);
 void hmp_info_memdev(Monitor *mon, const QDict *qdict);
 void hmp_info_memory_devices(Monitor *mon, const QDict *qdict);
 void hmp_qom_list(Monitor *mon, const QDict *qdict);
+void hmp_qom_type_prop_list(Monitor *mon, const QDict *qdict);
 void hmp_qom_set(Monitor *mon, const QDict *qdict);
 void object_add_completion(ReadLineState *rs, int nb_args, const char *str);
 void object_del_completion(ReadLineState *rs, int nb_args, const char *str);
diff --git a/include/qom/object.h b/include/qom/object.h
index d0dafe9..0c8379d 100644
--- a/include/qom/object.h
+++ b/include/qom/object.h
@@ -1013,6 +1013,37 @@ void object_property_iter_init(ObjectPropertyIterator 
*iter,
  */
 ObjectProperty *object_property_iter_next(ObjectPropertyIterator *iter);
 
+/**
+ * object_class_property_iter_init:
+ * @klass: the class owning the properties to be iterated over
+ *
+ * Initializes an iterator for traversing all properties
+ * registered against a class type and all parent classes.
+ *
+ * It is forbidden to modify the property list while iterating,
+ * whether removing or adding properties.
+ *
+ * NB For getting next property in the list the object related
+ * function object_property_iter_next is still used.
+ *
+ * Typical usage pattern would be
+ *
+ * 
+ *   Using object class property iterators
+ *   
+ *   ObjectProperty *prop;
+ *   ObjectPropertyIterator iter;
+ *
+ *   object_class property_iter_init(, obj);
+ *   while ((prop = object_property_iter_next())) {
+ * ... do something with prop ...
+ *   }
+ *   
+ * 
+ */
+void object_class_property_iter_init(ObjectPropertyIterator *iter,
+ ObjectClass *klass);
+
 void object_unparent(Object *obj

Re: [Qemu-devel] [RFC] target-i386: Display i386 CPUID properties

2016-01-25 Thread Valentin Rakush 
Hi Eduardo,

I was not able to list cpu class properties with this command, but it might
be that I am missing something. Daniel proposed the following patch for cpu
class properties some time ago:
http://lists.gnu.org/archive/html/qemu-devel/2015-08/msg03117.html And my
patch just implements a command that will return properties for any class,
but not only for devices. There is another related thread
http://lists.nongnu.org/archive/html/qemu-devel/2016-01/msg04348.html

If there are any additional requirements or concerns, please let me know,
and I will change the patch.

Regards,
Valentin


On Sat, Jan 23, 2016 at 5:01 PM, Eduardo Habkost <ehabk...@redhat.com>
wrote:

> On Tue, Jan 12, 2016 at 02:50:20PM +, Daniel P. Berrange wrote:
> > On Tue, Jan 12, 2016 at 05:36:27PM +0300, Valentin Rakush wrote:
> > > This is RFC because implementation depends on the upcoming class
> > > properties
> > > http://lists.nongnu.org/archive/html/qemu-devel/2015-08/msg03115.html
> > > and also because this patch does not handle all x86_64 properties.
> > >
> > > This RFC is in response to concerns pointed in this review but with
> changed
> > > subject line as recommended.
> > > http://lists.nongnu.org/archive/html/qemu-devel/2016-01/msg00053.html
> > >
> > > This RFC demonstrates the way for displaying cpu properties using -cpu
> > > help option.
> >
> > The point of doing this with QOM class properties, is such that we can
> > create a facility to query class properties for any QOM type in a
> > consistent manner.  I was expecting this would take the form of a
> > QMP monitor command 'qom-type-properties' or something along those
> > lines.
>
> Also, note that qmp_device_list_properties() already does what
> you want to do, without requiring class-properties.
>
> This means you can implement the new interfaces (help output, QMP
> changes) without any new QOM core code. You can also propose QOM
> class-properties, if it helps making code simpler, but it's not a
> requirement for returning QOM properties on QMP/help output.
>
> --
> Eduardo
>



-- 
Best Regards,
Valentin Rakush.

Re: [Qemu-devel] [PATCH v4] qom, qmp, hmp, qapi: create qom-type-prop-list for class properties

2016-01-22 Thread Valentin Rakush 
Hi Eric, hi Daniel,

Re dashes in the command name

AFAICC, the QOM related command in HMP use dash "-". For example, qom-list
and qom-set. If we will change dash "-" to underscore "_" then
qom_type_prop_list will be consistent with old HMP commands (created before
year 2013), but will _not_ be consistent with QOM commands created after
2013. Which is not nice and may be misleading.

If we want to have consistent naming of all HMP commands, then we should
rename all QOM commands to replace "-" to "_". But in this case we can
brake compatibility in possible scripts that already use these commands.
For example, scripts/qmp/qom-fuse

I would leave name qom-type-prop-list with dashes, so it will be consistent
with other two QOM commands and would refactor all QOM commands names if
possible.

Re subcommand of the info command

Also from hmp-command.hx I can see that info command shows various
information about the _system_state_ The qom-type-prop-list shows
properties of the class type. They can be changed during runtime, but I am
not sure if they can be referred as a system state. From another side
command like "info class x86_64-cpu" could take less typing, but this will
be inconsistent with QMP version of the command.

For this reasons I would leave qom-type-prop-list as it is right now.

Daniel have reviewed this patch already but found my error in the
parameters of the HMP command. I have fixed this error and tested command
with monitor.  But would it be ok to add QMP and HMP tests to this patch?
Or may be submit tests with another patch, because this one is already
reviewed? I do not see much QMP/HMP tests so I am hesitating if this is a
good idea.

Thank you,
Valentin






On Fri, Jan 22, 2016 at 10:02 PM, Eric Blake <ebl...@redhat.com> wrote:

> On 01/22/2016 05:15 AM, Valentin Rakush wrote:
> > This patch adds support for qom-type-prop-list command to list object
> > class properties. A later patch will use this functionality to
> > implement x86_64-cpu properties.
> >
> > Signed-off-by: Valentin Rakush <valentin.rak...@gmail.com>
> > Cc: Luiz Capitulino <lcapitul...@redhat.com>
> > Cc: Eric Blake <ebl...@redhat.com>
> > Cc: Markus Armbruster <arm...@redhat.com>
> > Cc: Andreas Färber <afaer...@suse.de>
> > Cc: Daniel P. Berrange <berra...@redhat.com>
> > ---
>
> > +++ b/hmp-commands.hx
> > @@ -1734,6 +1734,19 @@ Print QOM properties of object at location
> @var{path}
> >  ETEXI
> >
> >  {
> > +.name   = "qom-type-prop-list",
>
> To be consistent with most existing HMP commands, this should use
> qmp_type_prop_list (only the QMP version should use '-').
>
> For that matter, should this really be a new top-level command, or
> should it be a subcommand of the 'info' command?
>
> The QMP command looks fine, though.
>
> --
> Eric Blake   eblake redhat com+1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>
>


-- 
Best Regards,
Valentin Rakush.

[Qemu-devel] [PATCH v2] qom, qmp, hmp, qapi: create qom-type-list for class properties

2016-01-22 Thread Valentin Rakush 
This patch adds support for qom-type-prop-list command to list object 
class properties. A later patch will use this functionality to 
implement x86_64-cpu properties.

Signed-off-by: Valentin Rakush <valentin.rak...@gmail.com>
Cc: Luiz Capitulino <lcapitul...@redhat.com>
Cc: Eric Blake <ebl...@redhat.com>
Cc: Markus Armbruster <arm...@redhat.com>
Cc: Andreas Färber <afaer...@suse.de>
Cc: Daniel P. Berrange <berra...@redhat.com>
---
V2: Fixes after first review
 - changed command name from qom-type-list to qom-type-prop-list
 - changed memory allocation from g_malloc0 to g_new0
 - changed parameter name from path to typename
 - fixed wordings and comments
 - fixed source code formatting
 - registered the command in monitor
   
 hmp-commands.hx  | 13 +
 hmp.c| 26 ++
 hmp.h|  1 +
 include/qom/object.h | 31 +++
 qapi-schema.json | 19 +++
 qmp-commands.hx  |  6 ++
 qmp.c| 32 
 qom/object.c |  7 +++
 8 files changed, 135 insertions(+)

diff --git a/hmp-commands.hx b/hmp-commands.hx
index bb52e4d..0aca653 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1734,6 +1734,19 @@ Print QOM properties of object at location @var{path}
 ETEXI
 
 {
+.name   = "qom-type-prop-list",
+.args_type  = "typename:s?",
+.params = "typename",
+.help   = "list QOM class properties",
+.mhandler.cmd  = hmp_qom_type_prop_list,
+},
+
+STEXI
+@item qom-type-prop-list [@var{typename}]
+Print QOM properties of the type @var{typename}
+ETEXI
+
+{
 .name   = "qom-set",
 .args_type  = "path:s,property:s,value:s",
 .params = "path property value",
diff --git a/hmp.c b/hmp.c
index 54f2620..4bad6a1 100644
--- a/hmp.c
+++ b/hmp.c
@@ -2052,6 +2052,32 @@ void hmp_qom_list(Monitor *mon, const QDict *qdict)
 hmp_handle_error(mon, );
 }
 
+void hmp_qom_type_prop_list(Monitor *mon, const QDict *qdict)
+{
+const char *path = qdict_get_try_str(qdict, "path");
+ObjectPropertyInfoList *list;
+Error *err = NULL;
+
+if (!path) {
+monitor_printf(mon, "/\n");
+return;
+}
+
+list = qmp_qom_type_prop_list(path, );
+if (!err) {
+ObjectPropertyInfoList *start = list;
+while (list) {
+ObjectPropertyInfo *value = list->value;
+
+monitor_printf(mon, "%s (%s)\n",
+   value->name, value->type);
+list = list->next;
+}
+qapi_free_ObjectPropertyInfoList(start);
+}
+hmp_handle_error(mon, );
+}
+
 void hmp_qom_set(Monitor *mon, const QDict *qdict)
 {
 const char *path = qdict_get_str(qdict, "path");
diff --git a/hmp.h b/hmp.h
index a8c5b5a..8c12ebe 100644
--- a/hmp.h
+++ b/hmp.h
@@ -103,6 +103,7 @@ void hmp_object_del(Monitor *mon, const QDict *qdict);
 void hmp_info_memdev(Monitor *mon, const QDict *qdict);
 void hmp_info_memory_devices(Monitor *mon, const QDict *qdict);
 void hmp_qom_list(Monitor *mon, const QDict *qdict);
+void hmp_qom_type_prop_list(Monitor *mon, const QDict *qdict);
 void hmp_qom_set(Monitor *mon, const QDict *qdict);
 void object_add_completion(ReadLineState *rs, int nb_args, const char *str);
 void object_del_completion(ReadLineState *rs, int nb_args, const char *str);
diff --git a/include/qom/object.h b/include/qom/object.h
index d0dafe9..0c8379d 100644
--- a/include/qom/object.h
+++ b/include/qom/object.h
@@ -1013,6 +1013,37 @@ void object_property_iter_init(ObjectPropertyIterator 
*iter,
  */
 ObjectProperty *object_property_iter_next(ObjectPropertyIterator *iter);
 
+/**
+ * object_class_property_iter_init:
+ * @klass: the class owning the properties to be iterated over
+ *
+ * Initializes an iterator for traversing all properties
+ * registered against a class type and all parent classes.
+ *
+ * It is forbidden to modify the property list while iterating,
+ * whether removing or adding properties.
+ *
+ * NB For getting next property in the list the object related
+ * function object_property_iter_next is still used.
+ *
+ * Typical usage pattern would be
+ *
+ * 
+ *   Using object class property iterators
+ *   
+ *   ObjectProperty *prop;
+ *   ObjectPropertyIterator iter;
+ *
+ *   object_class property_iter_init(, obj);
+ *   while ((prop = object_property_iter_next())) {
+ * ... do something with prop ...
+ *   }
+ *   
+ * 
+ */
+void object_class_property_iter_init(ObjectPropertyIterator *iter,
+ ObjectClass *klass);
+
 void object_unparent(Object *obj);
 
 /**
diff --git a/qapi-schema.json b/qapi-schema.json
index b3038b2..2e960db 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -4081,3 +4081,22 @@

[Qemu-devel] [PATCH v3] qom, qmp, hmp, qapi: create qom-type-prop-list for class properties

2016-01-22 Thread Valentin Rakush 
This patch adds support for qom-type-prop-list command to list object
class properties. A later patch will use this functionality to
implement x86_64-cpu properties.

Signed-off-by: Valentin Rakush <valentin.rak...@gmail.com>
Cc: Luiz Capitulino <lcapitul...@redhat.com>
Cc: Eric Blake <ebl...@redhat.com>
Cc: Markus Armbruster <arm...@redhat.com>
Cc: Andreas Färber <afaer...@suse.de>
Cc: Daniel P. Berrange <berra...@redhat.com>
---
V2: Fixes after first review
 - changed command name from qom-type-list to qom-type-prop-list
 - changed memory allocation from g_malloc0 to g_new0
 - changed parameter name from path to typename
 - fixed wordings and comments
 - fixed source code formatting
 - registered the command in monitor
V3: commit message fix 
 - commit message changed to reflect actual command name


 hmp-commands.hx  | 13 +
 hmp.c| 26 ++
 hmp.h|  1 +
 include/qom/object.h | 31 +++
 qapi-schema.json | 19 +++
 qmp-commands.hx  |  6 ++
 qmp.c| 32 
 qom/object.c |  7 +++
 8 files changed, 135 insertions(+)

diff --git a/hmp-commands.hx b/hmp-commands.hx
index bb52e4d..0aca653 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1734,6 +1734,19 @@ Print QOM properties of object at location @var{path}
 ETEXI
 
 {
+.name   = "qom-type-prop-list",
+.args_type  = "typename:s?",
+.params = "typename",
+.help   = "list QOM class properties",
+.mhandler.cmd  = hmp_qom_type_prop_list,
+},
+
+STEXI
+@item qom-type-prop-list [@var{typename}]
+Print QOM properties of the type @var{typename}
+ETEXI
+
+{
 .name   = "qom-set",
 .args_type  = "path:s,property:s,value:s",
 .params = "path property value",
diff --git a/hmp.c b/hmp.c
index 54f2620..4bad6a1 100644
--- a/hmp.c
+++ b/hmp.c
@@ -2052,6 +2052,32 @@ void hmp_qom_list(Monitor *mon, const QDict *qdict)
 hmp_handle_error(mon, );
 }
 
+void hmp_qom_type_prop_list(Monitor *mon, const QDict *qdict)
+{
+const char *path = qdict_get_try_str(qdict, "path");
+ObjectPropertyInfoList *list;
+Error *err = NULL;
+
+if (!path) {
+monitor_printf(mon, "/\n");
+return;
+}
+
+list = qmp_qom_type_prop_list(path, );
+if (!err) {
+ObjectPropertyInfoList *start = list;
+while (list) {
+ObjectPropertyInfo *value = list->value;
+
+monitor_printf(mon, "%s (%s)\n",
+   value->name, value->type);
+list = list->next;
+}
+qapi_free_ObjectPropertyInfoList(start);
+}
+hmp_handle_error(mon, );
+}
+
 void hmp_qom_set(Monitor *mon, const QDict *qdict)
 {
 const char *path = qdict_get_str(qdict, "path");
diff --git a/hmp.h b/hmp.h
index a8c5b5a..8c12ebe 100644
--- a/hmp.h
+++ b/hmp.h
@@ -103,6 +103,7 @@ void hmp_object_del(Monitor *mon, const QDict *qdict);
 void hmp_info_memdev(Monitor *mon, const QDict *qdict);
 void hmp_info_memory_devices(Monitor *mon, const QDict *qdict);
 void hmp_qom_list(Monitor *mon, const QDict *qdict);
+void hmp_qom_type_prop_list(Monitor *mon, const QDict *qdict);
 void hmp_qom_set(Monitor *mon, const QDict *qdict);
 void object_add_completion(ReadLineState *rs, int nb_args, const char *str);
 void object_del_completion(ReadLineState *rs, int nb_args, const char *str);
diff --git a/include/qom/object.h b/include/qom/object.h
index d0dafe9..0c8379d 100644
--- a/include/qom/object.h
+++ b/include/qom/object.h
@@ -1013,6 +1013,37 @@ void object_property_iter_init(ObjectPropertyIterator 
*iter,
  */
 ObjectProperty *object_property_iter_next(ObjectPropertyIterator *iter);
 
+/**
+ * object_class_property_iter_init:
+ * @klass: the class owning the properties to be iterated over
+ *
+ * Initializes an iterator for traversing all properties
+ * registered against a class type and all parent classes.
+ *
+ * It is forbidden to modify the property list while iterating,
+ * whether removing or adding properties.
+ *
+ * NB For getting next property in the list the object related
+ * function object_property_iter_next is still used.
+ *
+ * Typical usage pattern would be
+ *
+ * 
+ *   Using object class property iterators
+ *   
+ *   ObjectProperty *prop;
+ *   ObjectPropertyIterator iter;
+ *
+ *   object_class property_iter_init(, obj);
+ *   while ((prop = object_property_iter_next())) {
+ * ... do something with prop ...
+ *   }
+ *   
+ * 
+ */
+void object_class_property_iter_init(ObjectPropertyIterator *iter,
+ ObjectClass *klass);
+
 void object_unparent(Object *obj);
 
 /**
diff --git a/qapi-schema.json b/qapi-schema.json
index b3038b2..2e960db 10

[Qemu-devel] [PATCH v4] qom, qmp, hmp, qapi: create qom-type-prop-list for class properties

2016-01-22 Thread Valentin Rakush 
This patch adds support for qom-type-prop-list command to list object
class properties. A later patch will use this functionality to
implement x86_64-cpu properties.

Signed-off-by: Valentin Rakush <valentin.rak...@gmail.com>
Cc: Luiz Capitulino <lcapitul...@redhat.com>
Cc: Eric Blake <ebl...@redhat.com>
Cc: Markus Armbruster <arm...@redhat.com>
Cc: Andreas Färber <afaer...@suse.de>
Cc: Daniel P. Berrange <berra...@redhat.com>
---
V4: review fixes
 - the typename argument in the hmp command changed to be mandatory
V3: commit message fix
 - commit message changed to reflect actual command name
V2: Fixes after first review
 - changed command name from qom-type-list to qom-type-prop-list
 - changed memory allocation from g_malloc0 to g_new0
 - changed parameter name from path to typename
 - fixed wordings and comments
 - fixed source code formatting
 - registered the command in monitor

 hmp-commands.hx  | 13 +
 hmp.c| 21 +
 hmp.h|  1 +
 include/qom/object.h | 31 +++
 qapi-schema.json | 19 +++
 qmp-commands.hx  |  6 ++
 qmp.c| 32 
 qom/object.c |  7 +++
 8 files changed, 130 insertions(+)

diff --git a/hmp-commands.hx b/hmp-commands.hx
index bb52e4d..ee4d1e2 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1734,6 +1734,19 @@ Print QOM properties of object at location @var{path}
 ETEXI
 
 {
+.name   = "qom-type-prop-list",
+.args_type  = "typename:s",
+.params = "typename",
+.help   = "list QOM class properties",
+.mhandler.cmd  = hmp_qom_type_prop_list,
+},
+
+STEXI
+@item qom-type-prop-list [@var{typename}]
+Print QOM properties of the type @var{typename}
+ETEXI
+
+{
 .name   = "qom-set",
 .args_type  = "path:s,property:s,value:s",
 .params = "path property value",
diff --git a/hmp.c b/hmp.c
index 54f2620..6de9bf0 100644
--- a/hmp.c
+++ b/hmp.c
@@ -2052,6 +2052,27 @@ void hmp_qom_list(Monitor *mon, const QDict *qdict)
 hmp_handle_error(mon, );
 }
 
+void hmp_qom_type_prop_list(Monitor *mon, const QDict *qdict)
+{
+const char *typename = qdict_get_try_str(qdict, "typename");
+ObjectPropertyInfoList *list;
+Error *err = NULL;
+
+list = qmp_qom_type_prop_list(typename, );
+if (!err) {
+ObjectPropertyInfoList *start = list;
+while (list) {
+ObjectPropertyInfo *value = list->value;
+
+monitor_printf(mon, "%s (%s)\n",
+   value->name, value->type);
+list = list->next;
+}
+qapi_free_ObjectPropertyInfoList(start);
+}
+hmp_handle_error(mon, );
+}
+
 void hmp_qom_set(Monitor *mon, const QDict *qdict)
 {
 const char *path = qdict_get_str(qdict, "path");
diff --git a/hmp.h b/hmp.h
index a8c5b5a..8c12ebe 100644
--- a/hmp.h
+++ b/hmp.h
@@ -103,6 +103,7 @@ void hmp_object_del(Monitor *mon, const QDict *qdict);
 void hmp_info_memdev(Monitor *mon, const QDict *qdict);
 void hmp_info_memory_devices(Monitor *mon, const QDict *qdict);
 void hmp_qom_list(Monitor *mon, const QDict *qdict);
+void hmp_qom_type_prop_list(Monitor *mon, const QDict *qdict);
 void hmp_qom_set(Monitor *mon, const QDict *qdict);
 void object_add_completion(ReadLineState *rs, int nb_args, const char *str);
 void object_del_completion(ReadLineState *rs, int nb_args, const char *str);
diff --git a/include/qom/object.h b/include/qom/object.h
index d0dafe9..0c8379d 100644
--- a/include/qom/object.h
+++ b/include/qom/object.h
@@ -1013,6 +1013,37 @@ void object_property_iter_init(ObjectPropertyIterator 
*iter,
  */
 ObjectProperty *object_property_iter_next(ObjectPropertyIterator *iter);
 
+/**
+ * object_class_property_iter_init:
+ * @klass: the class owning the properties to be iterated over
+ *
+ * Initializes an iterator for traversing all properties
+ * registered against a class type and all parent classes.
+ *
+ * It is forbidden to modify the property list while iterating,
+ * whether removing or adding properties.
+ *
+ * NB For getting next property in the list the object related
+ * function object_property_iter_next is still used.
+ *
+ * Typical usage pattern would be
+ *
+ * 
+ *   Using object class property iterators
+ *   
+ *   ObjectProperty *prop;
+ *   ObjectPropertyIterator iter;
+ *
+ *   object_class property_iter_init(, obj);
+ *   while ((prop = object_property_iter_next())) {
+ * ... do something with prop ...
+ *   }
+ *   
+ * 
+ */
+void object_class_property_iter_init(ObjectPropertyIterator *iter,
+ ObjectClass *klass);
+
 void object_unparent(Object *obj);
 
 /**
diff --git a/qapi-schema.json b/qapi-schema.json
index b3038b2..2

[Qemu-devel] [PATCH] qom, qmp, hmp, qapi: create qom-type-list for class properties

2016-01-20 Thread Valentin Rakush 
This patch adds support for qom-type-list command that supposed to list object 
class properties. Will use this functionality further to implement x86_64 cpu 
properties.

Additionally object_class_property_iterator_init function is implemented for 
consistency.


Signed-off-by: Valentin Rakush <valentin.rak...@gmail.com>
Cc: Luiz Capitulino <lcapitul...@redhat.com>
Cc: Eric Blake <ebl...@redhat.com>
Cc: Markus Armbruster <arm...@redhat.com>
Cc: Andreas Färber <afaer...@suse.de>
Cc: Daniel P. Berrange <berra...@redhat.com>
---
 hmp.c| 26 ++
 hmp.h|  1 +
 include/qom/object.h | 31 +++
 qapi-schema.json | 19 +++
 qmp-commands.hx  |  6 ++
 qmp.c| 29 +
 qom/object.c |  8 
 7 files changed, 120 insertions(+)

diff --git a/hmp.c b/hmp.c
index 54f2620..64aa991 100644
--- a/hmp.c
+++ b/hmp.c
@@ -2052,6 +2052,32 @@ void hmp_qom_list(Monitor *mon, const QDict *qdict)
 hmp_handle_error(mon, );
 }
 
+void hmp_qom_type_list(Monitor *mon, const QDict *qdict)
+{
+const char *path = qdict_get_try_str(qdict, "path");
+ObjectPropertyInfoList *list;
+Error *err = NULL;
+
+if (path == NULL) {
+monitor_printf(mon, "/\n");
+return;
+}
+
+list = qmp_qom_type_list(path, );
+if (err == NULL) {
+ObjectPropertyInfoList *start = list;
+while (list != NULL) {
+ObjectPropertyInfo *value = list->value;
+
+monitor_printf(mon, "%s (%s)\n",
+   value->name, value->type);
+list = list->next;
+}
+qapi_free_ObjectPropertyInfoList(start);
+}
+hmp_handle_error(mon, );
+}
+
 void hmp_qom_set(Monitor *mon, const QDict *qdict)
 {
 const char *path = qdict_get_str(qdict, "path");
diff --git a/hmp.h b/hmp.h
index a8c5b5a..d81cd4c 100644
--- a/hmp.h
+++ b/hmp.h
@@ -103,6 +103,7 @@ void hmp_object_del(Monitor *mon, const QDict *qdict);
 void hmp_info_memdev(Monitor *mon, const QDict *qdict);
 void hmp_info_memory_devices(Monitor *mon, const QDict *qdict);
 void hmp_qom_list(Monitor *mon, const QDict *qdict);
+void hmp_qom_type_list(Monitor *mon, const QDict *qdict);
 void hmp_qom_set(Monitor *mon, const QDict *qdict);
 void object_add_completion(ReadLineState *rs, int nb_args, const char *str);
 void object_del_completion(ReadLineState *rs, int nb_args, const char *str);
diff --git a/include/qom/object.h b/include/qom/object.h
index d0dafe9..f8ca725 100644
--- a/include/qom/object.h
+++ b/include/qom/object.h
@@ -1013,6 +1013,37 @@ void object_property_iter_init(ObjectPropertyIterator 
*iter,
  */
 ObjectProperty *object_property_iter_next(ObjectPropertyIterator *iter);
 
+/**
+ * object_class_property_iter_init:
+ * @klass: the klass to iter properties for
+ *
+ * Initializes an iterator for traversing all properties
+ * registered against a klass type and all parent classes.
+ *
+ * It is forbidden to modify the property list while iterating,
+ * whether removing or adding properties.
+ *
+ * NB For getting next property in the list the object related
+ * function object_property_iter_next is still used.
+ *
+ * Typical usage pattern would be
+ *
+ * 
+ *   Using object class property iterators
+ *   
+ *   ObjectProperty *prop;
+ *   ObjectPropertyIterator iter;
+ *
+ *   object_class property_iter_init(, obj);
+ *   while ((prop = object_property_iter_next())) {
+ * ... do something with prop ...
+ *   }
+ *   
+ * 
+ */
+void object_class_property_iter_init(ObjectPropertyIterator *iter,
+   ObjectClass *klass);
+
 void object_unparent(Object *obj);
 
 /**
diff --git a/qapi-schema.json b/qapi-schema.json
index b3038b2..c50d24c 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -4081,3 +4081,22 @@
 ##
 { 'enum': 'ReplayMode',
   'data': [ 'none', 'record', 'play' ] }
+
+##
+# @qom-type-list:
+#
+# This command will list any properties of a object class
+# given a path in the object class model.
+#
+# @path: the path within the object class model. See @qom-list-types
+#to check available object class names.
+#
+# Returns: a list of @ObjectPropertyInfo that describe the properties of the
+#  object class.
+#
+# Since: 2.6
+##
+{ 'command': 'qom-type-list',
+  'data': { 'path': 'str' },
+  'returns': [ 'ObjectPropertyInfo' ] }
+
diff --git a/qmp-commands.hx b/qmp-commands.hx
index db072a6..4e5dd48 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -3789,6 +3789,12 @@ EQMP
 },
 
 {
+.name   = "qom-type-list",
+.args_type  = "path:s",
+.mhandler.cmd_new = qmp_marshal_qom_type_list,
+},
+
+{
 .name   = "qom-set",
.args_type  = "path:s,property:s,value:q",
 .mhandler.c

Re: [Qemu-devel] [RFC] target-i386: Display i386 CPUID properties

2016-01-14 Thread Valentin Rakush 
On Tue, Jan 12, 2016 at 5:50 PM, Daniel P. Berrange <berra...@redhat.com>
wrote:

> On Tue, Jan 12, 2016 at 05:36:27PM +0300, Valentin Rakush wrote:
> > This is RFC because implementation depends on the upcoming class
> > properties
> > http://lists.nongnu.org/archive/html/qemu-devel/2015-08/msg03115.html
> > and also because this patch does not handle all x86_64 properties.
> >
> > This RFC is in response to concerns pointed in this review but with
> changed
> > subject line as recommended.
> > http://lists.nongnu.org/archive/html/qemu-devel/2016-01/msg00053.html
> >
> > This RFC demonstrates the way for displaying cpu properties using -cpu
> > help option.
>
> The point of doing this with QOM class properties, is such that we can
> create a facility to query class properties for any QOM type in a
> consistent manner.  I was expecting this would take the form of a
> QMP monitor command 'qom-type-properties' or something along those
> lines.
>

Hi Daniel,

thank you for comments. I will add and implement the following qmp command.
This is approximate sketch.

##
# @qom-type-list:
#
# This command will list any properties of a object class
# given a path in the object model.
#
# @path: the path within the object model.  See @qom-get for a description
of
#this parameter.
#
# Returns: a list of @ObjectPropertyInfo that describe the properties of the
#  object.
#
# Since: 2.6
##
{ 'command': 'qom-type-list',
  'data': { 'path': 'str' },
  'returns': [ 'ObjectPropertyInfo' ] }   |



Existing ObjectPropertyInfoList type will be reused for the returning
value. I am not
going to create new ObjectClassPropertyInfoList type.

There are not much specs on the topic, so please let me know if something
different
is expected.

-- 
Regards,
Valentin

[Qemu-devel] [RFC] target-i386: Display i386 CPUID properties

2016-01-12 Thread Valentin Rakush 
This is RFC because implementation depends on the upcoming class
properties  
http://lists.nongnu.org/archive/html/qemu-devel/2015-08/msg03115.html
and also because this patch does not handle all x86_64 properties.

This RFC is in response to concerns pointed in this review but with changed 
subject line as recommended. 
http://lists.nongnu.org/archive/html/qemu-devel/2016-01/msg00053.html

This RFC demonstrates the way for displaying cpu properties using -cpu
help option. 

Advantages:
- It is flexible and could be extended to all targets. 
- With object class properties it would be possible to display cpu properties
from the single place with better granularity.
- displaying actual/default values for properties

There are things left TODO:
1. The patch from Daniel P. Berrange should be submitted.
   - object properties now stored in hash table an dperhaps object class
 properties should be stored in hash table as well
   - add more functions for object class properties like getters, 
 iterators etc.
2. The code duplication in cpu_* functions should be refactored in final patch.
3. All target-i386 cpu properties should be reviewed and set during class
initialization.
4. Output formatting:
   - list cpu properties per CPUID
   - list cpu properties along with values
5. and more ...

Signed-off-by: Valentin Rakush <valentin.rak...@gmail.com>
---
 include/qom/cpu.h|   2 +
 include/qom/object.h |  46 +++
 qom/cpu.c|  50 
 qom/object.c | 220 +++
 target-i386/cpu.c|  29 +++
 vl.c |   2 +
 6 files changed, 349 insertions(+)

diff --git a/include/qom/cpu.h b/include/qom/cpu.h
index 51a1323..4ec07ce 100644
--- a/include/qom/cpu.h
+++ b/include/qom/cpu.h
@@ -761,6 +761,8 @@ void QEMU_NORETURN cpu_abort(CPUState *cpu, const char 
*fmt, ...)
 GCC_FMT_ATTR(2, 3);
 void cpu_exec_exit(CPUState *cpu);
 
+void cpu_properties_list(FILE *f, fprintf_function cpu_fprintf);
+
 #ifdef CONFIG_SOFTMMU
 extern const struct VMStateDescription vmstate_cpu_common;
 #else
diff --git a/include/qom/object.h b/include/qom/object.h
index 4509166..9777565 100644
--- a/include/qom/object.h
+++ b/include/qom/object.h
@@ -344,6 +344,8 @@ typedef struct ObjectProperty
 ObjectPropertyResolve *resolve;
 ObjectPropertyRelease *release;
 void *opaque;
+
+QTAILQ_ENTRY(ObjectProperty) node;
 } ObjectProperty;
 
 /**
@@ -381,6 +383,8 @@ struct ObjectClass
 const char *class_cast_cache[OBJECT_CLASS_CAST_CACHE];
 
 ObjectUnparent *unparent;
+
+QTAILQ_HEAD(, ObjectProperty) properties;
 };
 
 /**
@@ -944,6 +948,13 @@ ObjectProperty *object_property_add(Object *obj, const 
char *name,
 
 void object_property_del(Object *obj, const char *name, Error **errp);
 
+ObjectProperty *object_class_property_add(ObjectClass *klass, const char *name,
+  const char *type,
+  ObjectPropertyAccessor *get,
+  ObjectPropertyAccessor *set,
+  ObjectPropertyRelease *release,
+  void *opaque, Error **errp);
+
 /**
  * object_property_find:
  * @obj: the object
@@ -954,6 +965,8 @@ void object_property_del(Object *obj, const char *name, 
Error **errp);
  */
 ObjectProperty *object_property_find(Object *obj, const char *name,
  Error **errp);
+ObjectProperty *object_class_property_find(ObjectClass *klass, const char 
*name,
+   Error **errp);
 
 typedef struct ObjectPropertyIterator ObjectPropertyIterator;
 
@@ -1371,6 +1384,12 @@ void object_property_add_str(Object *obj, const char 
*name,
  void (*set)(Object *, const char *, Error **),
  Error **errp);
 
+void object_class_property_add_str(ObjectClass *klass, const char *name,
+   char *(*get)(Object *, Error **),
+   void (*set)(Object *, const char *,
+   Error **),
+   Error **errp);
+
 /**
  * object_property_add_bool:
  * @obj: the object to add a property to
@@ -1387,6 +1406,11 @@ void object_property_add_bool(Object *obj, const char 
*name,
   void (*set)(Object *, bool, Error **),
   Error **errp);
 
+void object_class_property_add_bool(ObjectClass *klass, const char *name,
+bool (*get)(Object *, Error **),
+void (*set)(Object *, bool, Error **),
+Error **errp);
+
 /**
  * object_property_add_enum:
  * @obj: the object to add a property to
@@ -1406,6 +1430,13 @@ void object_property_add_enum(Object *obj, const char