From: Alexey Kardashevskiy <aik@ozlabs.ru>
To: David Gibson <david@gibson.dropbear.id.au>,
Andrea Bolognani <abologna@redhat.com>
Cc: paulus@ozlabs.org, qemu-ppc@nongnu.org, qemu-devel@nongnu.org,
Suraj Jitindar Singh <sjitindarsingh@gmail.com>
Subject: Re: [Qemu-devel] [Qemu-ppc] [QEMU-PPC] [PATCH V3 0/6] target/ppc: Rework spapr_caps
Date: Fri, 19 Jan 2018 14:59:45 +1100 [thread overview]
Message-ID: <7f785be9-5035-b04c-0569-56a1c5bb3618@ozlabs.ru> (raw)
In-Reply-To: <20180119022210.GC30352@umbus.fritz.box>
[-- Attachment #1: Type: text/plain, Size: 7780 bytes --]
On 19/01/18 13:22, David Gibson wrote:
> On Thu, Jan 18, 2018 at 04:55:39PM +0100, Andrea Bolognani wrote:
>> On Thu, 2018-01-18 at 15:27 +1100, David Gibson wrote:
>>>> I looked further and device-list-properties looks like it would
>>>> do the trick; however it doesn't seem to work for machines:
>>>>
>>>> {"execute": "device-list-properties",
>>>> "arguments": {"typename": "spapr-2.11-machine"}}
>>>> {"error": {"class": "GenericError",
>>>> "desc": "Parameter 'typename' expects device"}}
>>>>
>>>> It works fine for the likes of virtio-scsi-pci and even
>>>> power9_v2.0-powerpc64-cpu, though. Any ideas? :)
>>>
>>> I'm guessing it's because machines aren't descended from TYPE_DEVICE.
>>>
>>> Dammit. I really can't see a reasonable way of addressing this other
>>> than improving qapi in general to have a way of reporting machine
>>> class properties. Adding something ad-hoc for just these properties
>>> of this machine seems like madness.
>>>
>>> Nor can I think of a place to put these that would be both sensible
>>> and more discoverable with existing mechanisms.
>>
>> The relationship between QOM/QAPI/QMP is not very clear in my mind,
>
> You and me both :/
>
>> as you might have guessed from my messages, so I don't think I can
>> offer much useful input. But if the properties are registered using
>> the same mechanism both for devices and machines, then maybe there
>> should be a QMP command that can list them regardless of the parent
>> type? object-list-properties or something like that.
>
> So, it's a bit complicated. The underlying mechanism is QOM
> properties in all cases.
There are 2 types of properties really.
typedef struct DeviceClass {
[...]
Property *props;
These are printed by QMP's device-list-properties. Machine is not a device
so we do not see them.
struct ObjectClass
{
[...]
GHashTable *properties;
These are printed by qom-list/get but these QMP commands take path as an
argument and therefore require instances, not classes.
DeviceClass::props migrate to ObjectClass::properties in device_initfn.
So I guess we will either need to:
- merge all the properties to Object/ObjectClass or
- rename&teach device-list-properties to work with objects rather than
devices or
- add qom-list-properties which will only print QOM properties.
The latter is fairly simple, I'll post an rfc patch in few minutes, it will
do like this:
{"execute": "qom-list-properties", "arguments": {"typename":
"pseries-2.11-machine"}}
{ 'return': [ { 'description': 'Set on/off to enable/disable graphics '
'emulation',
'name': 'graphics',
'type': 'bool'},
{ 'description': 'The first phandle ID we may generate '
'dynamically',
'name': 'phandle-start',
'type': 'int'},
{ 'description': 'Include guest memory in a core dump',
'name': 'dump-guest-core',
'type': 'bool'},
{ 'description': 'Configure KVM in-kernel irqchip',
'name': 'kernel-irqchip',
'type': 'OnOffSplit'},
{ 'description': 'Accelerator list',
'name': 'accel',
'type': 'string'},
{ 'description': 'Linux kernel command line',
'name': 'append',
'type': 'string'},
{ 'description': 'Dump current dtb to a file and quit',
'name': 'dumpdtb',
'type': 'string'},
{ 'description': 'Set on/off to enable/disable igd '
'passthrou',
'name': 'igd-passthru',
'type': 'bool'},
{ 'description': 'Overrides the "compatible" property of '
'the dt root node',
'name': 'dt-compatible',
'type': 'string'},
{ 'description': 'Linux kernel image file',
'name': 'kernel',
'type': 'string'},
{ 'description': 'Set on/off to enable/disable usb',
'name': 'usb',
'type': 'bool'},
{ 'description': 'Set on to disable self-describing '
'migration',
'name': 'suppress-vmdesc',
'type': 'bool'},
{ 'description': 'Linux kernel device tree file',
'name': 'dtb',
'type': 'string'},
{ 'description': 'Firmware image',
'name': 'firmware',
'type': 'string'},
{ 'description': 'Enable/disable memory merge support',
'name': 'mem-merge',
'type': 'bool'},
{ 'description': 'Linux initial ramdisk file',
'name': 'initrd',
'type': 'string'},
{ 'description': 'Set on to enforce configuration section '
'migration',
'name': 'enforce-config-section',
'type': 'bool'},
{ 'description': 'KVM shadow MMU size',
'name': 'kvm-shadow-mem',
'type': 'int'},
{ 'description': 'Allow Decimal Floating Point (DFP)',
'name': 'cap-dfp',
'type': 'bool'},
{ 'description': 'Allow Hardware Transactional Memory '
'(HTM)',
'name': 'cap-htm',
'type': 'bool'},
{ 'description': 'Allow Vector Scalar Extensions (VSX)',
'name': 'cap-vsx',
'type': 'bool'},
{'name': 'type', 'type': 'string'},
{ 'description': 'Resizing of the Hash Page Table '
'(enabled, disabled, required)',
'name': 'resize-hpt',
'type': 'string'},
{ 'description': 'Maximum permitted CPU compatibility '
'mode. Valid values are power6, power7, '
'power7+, power8, power9.',
'name': 'max-cpu-compat',
'type': 'string'},
{ 'description': 'Use dedicated hotplug event mechanism
in '
'place of standard EPOW events when '
'possible (required for memory
hot-unplug '
'support)',
'name': 'modern-hotplug-events',
'type': 'bool'},
{ 'description': 'Virtual SMT: KVM behaves as if this
were '
"the host's SMT mode",
'name': 'vsmt',
'type': 'uint32'},
{ 'description': 'Specifies the KVM virtualization mode '
'(HV, PR)',
'name': 'kvm-type',
'type': 'string'},
{'name': 'vfio-no-msix-emulation', 'type': 'bool'}]}
--
Alexey
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 854 bytes --]
prev parent reply other threads:[~2018-01-19 3:59 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-15 6:32 [Qemu-devel] [QEMU-PPC] [PATCH V3 0/6] target/ppc: Rework spapr_caps Suraj Jitindar Singh
2018-01-15 6:32 ` [Qemu-devel] [QEMU-PPC] [PATCH V3 1/6] target/ppc/kvm: Add cap_ppc_safe_[cache/bounds_check/indirect_branch] Suraj Jitindar Singh
2018-01-15 6:58 ` [Qemu-devel] [QEMU-PPC] [PATCH V4 " Suraj Jitindar Singh
2018-01-18 5:06 ` David Gibson
2018-01-15 6:32 ` [Qemu-devel] [QEMU-PPC] [PATCH V3 2/6] target/ppc/spapr_caps: Add support for tristate spapr_capabilities Suraj Jitindar Singh
2018-01-18 5:07 ` David Gibson
2018-01-15 6:32 ` [Qemu-devel] [QEMU-PPC] [PATCH V3 3/6] target/ppc/spapr_caps: Add new tristate cap safe_cache Suraj Jitindar Singh
2018-01-18 5:10 ` David Gibson
2018-01-15 6:32 ` [Qemu-devel] [QEMU-PPC] [PATCH V3 4/6] target/ppc/spapr_caps: Add new tristate cap safe_bounds_check Suraj Jitindar Singh
2018-01-18 5:11 ` David Gibson
2018-01-15 6:32 ` [Qemu-devel] [QEMU-PPC] [PATCH V3 5/6] target/ppc/spapr_caps: Add new tristate cap safe_indirect_branch Suraj Jitindar Singh
2018-01-18 5:11 ` David Gibson
2018-01-15 6:32 ` [Qemu-devel] [QEMU-PPC] [PATCH V3 6/6] target/ppc/spapr: Add H-Call H_GET_CPU_CHARACTERISTICS Suraj Jitindar Singh
2018-01-18 5:20 ` David Gibson
2018-01-18 5:44 ` [Qemu-devel] [Qemu-ppc] " Alexey Kardashevskiy
2018-01-18 5:53 ` David Gibson
2018-01-18 8:11 ` Alexey Kardashevskiy
2018-01-18 20:30 ` Eric Blake
2018-01-18 23:35 ` David Gibson
2018-01-18 23:33 ` David Gibson
2018-01-16 13:47 ` [Qemu-devel] [Qemu-ppc] [QEMU-PPC] [PATCH V3 0/6] target/ppc: Rework spapr_caps Andrea Bolognani
2018-01-16 13:54 ` David Gibson
2018-01-16 14:46 ` Andrea Bolognani
2018-01-16 22:34 ` David Gibson
2018-01-16 23:26 ` Alexey Kardashevskiy
2018-01-16 23:30 ` David Gibson
2018-01-16 23:46 ` Alexey Kardashevskiy
2018-01-17 1:15 ` David Gibson
2018-01-17 8:54 ` Andrea Bolognani
2018-01-18 4:27 ` David Gibson
2018-01-18 15:55 ` Andrea Bolognani
2018-01-19 2:22 ` David Gibson
2018-01-19 3:59 ` Alexey Kardashevskiy [this message]
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=7f785be9-5035-b04c-0569-56a1c5bb3618@ozlabs.ru \
--to=aik@ozlabs.ru \
--cc=abologna@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=paulus@ozlabs.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=sjitindarsingh@gmail.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).