[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v7 1/3] qmp: adding 'wakeup-suspend-support' in
From: |
Eduardo Habkost |
Subject: |
Re: [Qemu-devel] [PATCH v7 1/3] qmp: adding 'wakeup-suspend-support' in query-target |
Date: |
Wed, 23 May 2018 09:27:49 -0300 |
User-agent: |
Mutt/1.9.2 (2017-12-15) |
On Wed, May 23, 2018 at 11:17:55AM +0200, Markus Armbruster wrote:
> Eduardo Habkost <address@hidden> writes:
> > On Mon, May 21, 2018 at 04:46:36PM -0300, Daniel Henrique Barboza wrote:
[...]
> >> Since no objection was made back then, this logic was put into query-target
> >> starting
> >> in v2. Still, I don't have any favorites though: query-target looks ok,
> >> query-machine
> >> looks ok and a new API looks ok too. It's all about what makes (more) sense
> >> in the
> >> management level, I think.
> >
> > I understand the original objection from Eric: having to add a
> > new command for every runtime flag we want to expose to the user
> > looks wrong to me.
>
> Agreed.
>
> > However, extending query-machines and query-target looks wrong
> > too, however. query-target looks wrong because this not a
> > property of the target. query-machines is wrong because this is
> > not a static property of the machine-type, but of the running
> > machine instance.
>
> Of the two, query-machines looks less wrong.
>
> Arguably, -no-acpi should not exist. It's an ad hoc flag that sneakily
> splits a few machine types into two variants, with and without ACPI.
> It's silently ignored for other machine types, even APCI-capable ones.
>
> If the machine type variants with and without ACPI were separate types,
> wakeup-suspend-support would be a static property of the machine type.
>
> However, "separate types" probably doesn't scale: I'm afraid we'd end up
> with an undesirable number of machine types. Avoiding that is exactly
> why we have machine types with configurable options. I suspect that's
> how ACPI should be configured (if at all).
>
> So, should we make -no-acpi sugar for a machine type parameter? And
> then deprecate -no-acpi for good measure?
I think we should.
>
> > Can we have a new query command that could be an obvious
> > container for simple machine capabilities that are not static? A
> > name like "query-machine" would be generic enough for that, I
> > guess.
>
> Having command names differ only in a single letter is awkward, but
> let's focus on things other than naming now, and use
> query-current-machine like a working title.
>
> query-machines is wrong because wakeup-suspend-support isn't static for
> some machine types.
>
> query-current-machine is also kind of wrong because
> wakeup-suspend-support *is* static for most machine types.
>
The most appropriate solution depends a lot on how/when
management software needs to query this.
If they only need to query it at runtime for a running VM,
there's no reason for us to go of our way and add complexity just
to make it look like static data in query-machines.
On the other hand, if they really need to query it before
configuring/starting a VM, it won't be useful at all to make it
available only at runtime.
Daniel, when/how exactly software would need to query the new
flag?
> Worse, a machine type property that is static for all machine types now
> could conceivably become dynamic when we add a machine type
> configuration knob.
>
This isn't the first time a machine capability that seems static
actually depends on other configuration arguments. We will
probably need to address this eventually.
> Would a way to tie the property to the configuration knob help?
> Something like wakeup-suspend-support taking values true (supported),
> false (not supported), and "acpi" (supported if machine type
> configuration knob "acpi" is switched on).
>
I would prefer a more generic mechanism. Maybe make
'query-machines' accept a 'machine-options' argument?
--
Eduardo
- [Qemu-devel] [PATCH v7 0/3] wakeup-from-suspend and system_wakeup changes, Daniel Henrique Barboza, 2018/05/17
- [Qemu-devel] [PATCH v7 1/3] qmp: adding 'wakeup-suspend-support' in query-target, Daniel Henrique Barboza, 2018/05/17
- Re: [Qemu-devel] [PATCH v7 1/3] qmp: adding 'wakeup-suspend-support' in query-target, Markus Armbruster, 2018/05/18
- Re: [Qemu-devel] [PATCH v7 1/3] qmp: adding 'wakeup-suspend-support' in query-target, Eduardo Habkost, 2018/05/21
- Re: [Qemu-devel] [PATCH v7 1/3] qmp: adding 'wakeup-suspend-support' in query-target, Daniel Henrique Barboza, 2018/05/21
- Re: [Qemu-devel] [PATCH v7 1/3] qmp: adding 'wakeup-suspend-support' in query-target, Eduardo Habkost, 2018/05/21
- Re: [Qemu-devel] [PATCH v7 1/3] qmp: adding 'wakeup-suspend-support' in query-target, Markus Armbruster, 2018/05/23
- Re: [Qemu-devel] [PATCH v7 1/3] qmp: adding 'wakeup-suspend-support' in query-target,
Eduardo Habkost <=
- Re: [Qemu-devel] [PATCH v7 1/3] qmp: adding 'wakeup-suspend-support' in query-target, Daniel Henrique Barboza, 2018/05/23
- Re: [Qemu-devel] [PATCH v7 1/3] qmp: adding 'wakeup-suspend-support' in query-target, Markus Armbruster, 2018/05/23
- Re: [Qemu-devel] [PATCH v7 1/3] qmp: adding 'wakeup-suspend-support' in query-target, Eduardo Habkost, 2018/05/24
- Re: [Qemu-devel] [PATCH v7 1/3] qmp: adding 'wakeup-suspend-support' in query-target, Markus Armbruster, 2018/05/25
- Re: [Qemu-devel] [PATCH v7 1/3] qmp: adding 'wakeup-suspend-support' in query-target, Eduardo Habkost, 2018/05/25
- Re: [Qemu-devel] [PATCH v7 1/3] qmp: adding 'wakeup-suspend-support' in query-target, Markus Armbruster, 2018/05/28
- Re: [Qemu-devel] [PATCH v7 1/3] qmp: adding 'wakeup-suspend-support' in query-target, Eduardo Habkost, 2018/05/29
[Qemu-devel] [PATCH v7 2/3] qga: update guest-suspend-ram and guest-suspend-hybrid descriptions, Daniel Henrique Barboza, 2018/05/17
[Qemu-devel] [PATCH v7 3/3] qmp.c: system_wakeup: runstate and wake-up support check, Daniel Henrique Barboza, 2018/05/17