[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: |
Andrea Bolognani |
Subject: |
Re: [Qemu-ppc] [QEMU-PPC] [PATCH V3 0/6] target/ppc: Rework spapr_caps |
Date: |
Wed, 17 Jan 2018 09:54:57 +0100 |
On Wed, 2018-01-17 at 10:26 +1100, Alexey Kardashevskiy wrote:
> On 17/01/18 09:34, David Gibson wrote:
> > On Tue, Jan 16, 2018 at 03:46:20PM +0100, Andrea Bolognani wrote:
> > > On Wed, 2018-01-17 at 00:54 +1100, David Gibson wrote:
> > > > > Correct me if I'm wrong, but it seems to me like there's no way
> > > > > to figure out through QMP whether these new machine options can be
> > > > > used for a given QEMU binary.
> > > >
> > > > Uh, I don't think so. These are machine options like any other (just
> > > > constructed a bit differently). So they'll appear in qemu -machine
> > > > pseries,? and I believe that info can also be retrieved with QMP.
> > >
> > > Yes, they will indeed show up in the output of -machine pseries,?
> > > but there's AFAICT no way to retrieve them via QMP.
> >
> > Really!? I thought introspecting object properties was QMP's bread
> > and butter.
>
> On a guest started with '-S':
> {"execute": "qom-list", "arguments": {"path": "/machine"}}
>
> returns:
> { 'return': [ {'name': 'graphics', 'type': 'bool'},
[...]
> {'name': 'cap-dfp', 'type': 'bool'},
> {'name': 'cap-htm', 'type': 'bool'},
> {'name': 'cap-vsx', 'type': 'bool'},
> {'name': 'vfio-no-msix-emulation', 'type': 'bool'},
> {'name': 'kvm-type', 'type': 'string'},
> {'name': 'max-cpu-compat', 'type': 'string'},
[...]
> {'name': 'resize-hpt', 'type': 'string'}]}
>
> but still requires a running qemu, yes.
That's not a problem in itself; however, AFAICT the guest in
question also needs to be started with -machine pseries in order
for the above to work, which means it's not usable due to the
scalability issues mentioned earlier in the thread. We run QEMU
with -machine none, a single time, to probe for capabilities.
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? :)
--
Andrea Bolognani / Red Hat / Virtualization
- Re: [Qemu-ppc] [Qemu-devel] [QEMU-PPC] [PATCH V3 6/6] target/ppc/spapr: Add H-Call H_GET_CPU_CHARACTERISTICS, (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, 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 <=
- 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, 2018/01/18