[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [QEMU-PPC] [PATCH V3 0/6] target/ppc: Rework spapr_caps
From: |
Alexey Kardashevskiy |
Subject: |
Re: [Qemu-ppc] [QEMU-PPC] [PATCH V3 0/6] target/ppc: Rework spapr_caps |
Date: |
Fri, 19 Jan 2018 14:59:45 +1100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 |
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
signature.asc
Description: OpenPGP digital signature
- Re: [Qemu-ppc] [QEMU-PPC] [PATCH V3 0/6] target/ppc: Rework spapr_caps, (continued)
- Re: [Qemu-ppc] [QEMU-PPC] [PATCH V3 0/6] target/ppc: Rework spapr_caps, Andrea Bolognani, 2018/01/16
- Re: [Qemu-ppc] [QEMU-PPC] [PATCH V3 0/6] target/ppc: Rework spapr_caps, David Gibson, 2018/01/16
- Re: [Qemu-ppc] [QEMU-PPC] [PATCH V3 0/6] target/ppc: Rework spapr_caps, Alexey Kardashevskiy, 2018/01/16
- Re: [Qemu-ppc] [QEMU-PPC] [PATCH V3 0/6] target/ppc: Rework spapr_caps, David Gibson, 2018/01/16
- Re: [Qemu-ppc] [QEMU-PPC] [PATCH V3 0/6] target/ppc: Rework spapr_caps, Alexey Kardashevskiy, 2018/01/16
- Re: [Qemu-ppc] [QEMU-PPC] [PATCH V3 0/6] target/ppc: Rework spapr_caps, David Gibson, 2018/01/16
- Re: [Qemu-ppc] [QEMU-PPC] [PATCH V3 0/6] target/ppc: Rework spapr_caps, Andrea Bolognani, 2018/01/17
- Re: [Qemu-ppc] [QEMU-PPC] [PATCH V3 0/6] target/ppc: Rework spapr_caps, David Gibson, 2018/01/17
- Re: [Qemu-ppc] [QEMU-PPC] [PATCH V3 0/6] target/ppc: Rework spapr_caps, Andrea Bolognani, 2018/01/18
- Re: [Qemu-ppc] [QEMU-PPC] [PATCH V3 0/6] target/ppc: Rework spapr_caps, David Gibson, 2018/01/18
- Re: [Qemu-ppc] [QEMU-PPC] [PATCH V3 0/6] target/ppc: Rework spapr_caps,
Alexey Kardashevskiy <=