diff mbox series

[v5,3/8] qapi: Restrict balloon-related commands to machine code

Message ID 20200913195348.1064154-4-philmd@redhat.com (mailing list archive)
State New, archived
Headers show
Series user-mode: Prune build dependencies (part 2) | expand

Commit Message

Philippe Mathieu-Daudé Sept. 13, 2020, 7:53 p.m. UTC
Only qemu-system-FOO and qemu-storage-daemon provide QMP
monitors, therefore such declarations and definitions are
irrelevant for user-mode emulation.

Restricting the balloon-related commands to machine.json
allows pulling less declarations/definitions to user-mode.

Reviewed-by: David Hildenbrand <david@redhat.com>
Acked-by: Markus Armbruster <armbru@redhat.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
---
 qapi/machine.json          | 90 ++++++++++++++++++++++++++++++++++++++
 qapi/misc.json             | 90 --------------------------------------
 include/sysemu/balloon.h   |  2 +-
 hw/virtio/virtio-balloon.c |  2 +-
 monitor/hmp-cmds.c         |  1 +
 softmmu/balloon.c          |  2 +-
 6 files changed, 94 insertions(+), 93 deletions(-)

Comments

Markus Armbruster Sept. 14, 2020, 9:16 a.m. UTC | #1
Philippe Mathieu-Daudé <philmd@redhat.com> writes:

> Only qemu-system-FOO and qemu-storage-daemon provide QMP
> monitors, therefore such declarations and definitions are
> irrelevant for user-mode emulation.
>
> Restricting the balloon-related commands to machine.json
> allows pulling less declarations/definitions to user-mode.

How this affects user mode is not obvious to (ignorant) me.  Can you
provide a clue?

[...]
Philippe Mathieu-Daudé Sept. 14, 2020, 9:42 a.m. UTC | #2
+Laurent and David

On 9/14/20 11:16 AM, Markus Armbruster wrote:
> Philippe Mathieu-Daudé <philmd@redhat.com> writes:
> 
>> Only qemu-system-FOO and qemu-storage-daemon provide QMP
>> monitors, therefore such declarations and definitions are
>> irrelevant for user-mode emulation.
>>
>> Restricting the balloon-related commands to machine.json
>> allows pulling less declarations/definitions to user-mode.
> 
> How this affects user mode is not obvious to (ignorant) me.  Can you
> provide a clue?

I guess this was discussed with David at some point.

Maybe the QMP commands are not exposed via HMP, making this
code unreachable?

Anyhow user-mode binaries don't use the memory ballooning feature,
this is specific to system-mode emulation.

Laurent/David, do you have some more trivial explanation?

Thanks,

Phil.
David Hildenbrand Sept. 14, 2020, 9:48 a.m. UTC | #3
> Am 14.09.2020 um 11:42 schrieb Philippe Mathieu-Daudé <philmd@redhat.com>:
> 
> +Laurent and David
> 
>> On 9/14/20 11:16 AM, Markus Armbruster wrote:
>> Philippe Mathieu-Daudé <philmd@redhat.com> writes:
>> 
>>> Only qemu-system-FOO and qemu-storage-daemon provide QMP
>>> monitors, therefore such declarations and definitions are
>>> irrelevant for user-mode emulation.
>>> 
>>> Restricting the balloon-related commands to machine.json
>>> allows pulling less declarations/definitions to user-mode.
>> 
>> How this affects user mode is not obvious to (ignorant) me.  Can you
>> provide a clue?
> 
> I guess this was discussed with David at some point.
> 
> Maybe the QMP commands are not exposed via HMP, making this
> code unreachable?
> 
> Anyhow user-mode binaries don't use the memory ballooning feature,
> this is specific to system-mode emulation.
> 
> Laurent/David, do you have some more trivial explanation?

Agreed.

No memory ballooning device -> no memory ballooning :)

> 
> Thanks,
> 
> Phil.
>
Markus Armbruster Sept. 14, 2020, 11:21 a.m. UTC | #4
David Hildenbrand <david@redhat.com> writes:

>> Am 14.09.2020 um 11:42 schrieb Philippe Mathieu-Daudé <philmd@redhat.com>:
>> 
>> +Laurent and David
>> 
>>> On 9/14/20 11:16 AM, Markus Armbruster wrote:
>>> Philippe Mathieu-Daudé <philmd@redhat.com> writes:
>>> 
>>>> Only qemu-system-FOO and qemu-storage-daemon provide QMP
>>>> monitors, therefore such declarations and definitions are
>>>> irrelevant for user-mode emulation.
>>>> 
>>>> Restricting the balloon-related commands to machine.json
>>>> allows pulling less declarations/definitions to user-mode.
>>> 
>>> How this affects user mode is not obvious to (ignorant) me.  Can you
>>> provide a clue?
>> 
>> I guess this was discussed with David at some point.
>> 
>> Maybe the QMP commands are not exposed via HMP, making this
>> code unreachable?
>> 
>> Anyhow user-mode binaries don't use the memory ballooning feature,
>> this is specific to system-mode emulation.
>> 
>> Laurent/David, do you have some more trivial explanation?
>
> Agreed.
>
> No memory ballooning device -> no memory ballooning :)

I understand why user mode doesn't need device models.  What I don't
understand offhand is how balloon-related stuff in misc.json ends up
pulling "declarations/definitions to user-mode".  What exactly is being
pulled where before the series, and no more afterwards?

Is it just the code generated for the QAPI stuff you move, or is it
more?
Philippe Mathieu-Daudé Sept. 14, 2020, 12:15 p.m. UTC | #5
On 9/14/20 1:21 PM, Markus Armbruster wrote:
> David Hildenbrand <david@redhat.com> writes:
> 
>>> Am 14.09.2020 um 11:42 schrieb Philippe Mathieu-Daudé <philmd@redhat.com>:
>>>
>>> +Laurent and David
>>>
>>>> On 9/14/20 11:16 AM, Markus Armbruster wrote:
>>>> Philippe Mathieu-Daudé <philmd@redhat.com> writes:
>>>>
>>>>> Only qemu-system-FOO and qemu-storage-daemon provide QMP
>>>>> monitors, therefore such declarations and definitions are
>>>>> irrelevant for user-mode emulation.
>>>>>
>>>>> Restricting the balloon-related commands to machine.json
>>>>> allows pulling less declarations/definitions to user-mode.
>>>>
>>>> How this affects user mode is not obvious to (ignorant) me.  Can you
>>>> provide a clue?
>>>
>>> I guess this was discussed with David at some point.
>>>
>>> Maybe the QMP commands are not exposed via HMP, making this
>>> code unreachable?
>>>
>>> Anyhow user-mode binaries don't use the memory ballooning feature,
>>> this is specific to system-mode emulation.
>>>
>>> Laurent/David, do you have some more trivial explanation?
>>
>> Agreed.
>>
>> No memory ballooning device -> no memory ballooning :)
> 
> I understand why user mode doesn't need device models.  What I don't
> understand offhand is how balloon-related stuff in misc.json ends up
> pulling "declarations/definitions to user-mode".  What exactly is being
> pulled where before the series, and no more afterwards?
> 
> Is it just the code generated for the QAPI stuff you move, or is it
> more?

As of this series, this is only QAPI generated code.
(code which pulls in unwanted declarations/definitions
that should be poisoned, but we can't because of this).

I didn't feel the need to enumerate what is removed from
user-mode, because from the diff (and no link failure)
I thought it was obvious. I can do, but that would be
simply copy/pasting the QAPI changes.

Part 3 start to remove things, but I kept that separated.
Markus Armbruster Sept. 15, 2020, 6:24 a.m. UTC | #6
Philippe Mathieu-Daudé <philmd@redhat.com> writes:

> On 9/14/20 1:21 PM, Markus Armbruster wrote:
>> David Hildenbrand <david@redhat.com> writes:
>> 
>>>> Am 14.09.2020 um 11:42 schrieb Philippe Mathieu-Daudé <philmd@redhat.com>:
>>>>
>>>> +Laurent and David
>>>>
>>>>> On 9/14/20 11:16 AM, Markus Armbruster wrote:
>>>>> Philippe Mathieu-Daudé <philmd@redhat.com> writes:
>>>>>
>>>>>> Only qemu-system-FOO and qemu-storage-daemon provide QMP
>>>>>> monitors, therefore such declarations and definitions are
>>>>>> irrelevant for user-mode emulation.
>>>>>>
>>>>>> Restricting the balloon-related commands to machine.json
>>>>>> allows pulling less declarations/definitions to user-mode.
>>>>>
>>>>> How this affects user mode is not obvious to (ignorant) me.  Can you
>>>>> provide a clue?
>>>>
>>>> I guess this was discussed with David at some point.
>>>>
>>>> Maybe the QMP commands are not exposed via HMP, making this
>>>> code unreachable?
>>>>
>>>> Anyhow user-mode binaries don't use the memory ballooning feature,
>>>> this is specific to system-mode emulation.
>>>>
>>>> Laurent/David, do you have some more trivial explanation?
>>>
>>> Agreed.
>>>
>>> No memory ballooning device -> no memory ballooning :)
>> 
>> I understand why user mode doesn't need device models.  What I don't
>> understand offhand is how balloon-related stuff in misc.json ends up
>> pulling "declarations/definitions to user-mode".  What exactly is being
>> pulled where before the series, and no more afterwards?
>> 
>> Is it just the code generated for the QAPI stuff you move, or is it
>> more?
>
> As of this series, this is only QAPI generated code.
> (code which pulls in unwanted declarations/definitions
> that should be poisoned, but we can't because of this).
>
> I didn't feel the need to enumerate what is removed from
> user-mode, because from the diff (and no link failure)
> I thought it was obvious. I can do, but that would be
> simply copy/pasting the QAPI changes.

Suggest to replace "pulling less declarations/definitions to user-mode"
by "pulling less QAPI-generated code into user-mode" in all the commit
messages.

> Part 3 start to remove things, but I kept that separated.

That's okay.
diff mbox series

Patch

diff --git a/qapi/machine.json b/qapi/machine.json
index b6396aa3fea..04f0a907c75 100644
--- a/qapi/machine.json
+++ b/qapi/machine.json
@@ -969,3 +969,93 @@ 
   'data': 'NumaOptions',
   'allow-preconfig': true
 }
+
+##
+# @balloon:
+#
+# Request the balloon driver to change its balloon size.
+#
+# @value: the target logical size of the VM in bytes
+#         We can deduce the size of the balloon using this formula:
+#            logical_vm_size = vm_ram_size - balloon_size
+#         From it we have: balloon_size = vm_ram_size - @value
+#
+# Returns: - Nothing on success
+#          - If the balloon driver is enabled but not functional because the KVM
+#            kernel module cannot support it, KvmMissingCap
+#          - If no balloon device is present, DeviceNotActive
+#
+# Notes: This command just issues a request to the guest.  When it returns,
+#        the balloon size may not have changed.  A guest can change the balloon
+#        size independent of this command.
+#
+# Since: 0.14.0
+#
+# Example:
+#
+# -> { "execute": "balloon", "arguments": { "value": 536870912 } }
+# <- { "return": {} }
+#
+# With a 2.5GiB guest this command inflated the ballon to 3GiB.
+#
+##
+{ 'command': 'balloon', 'data': {'value': 'int'} }
+
+##
+# @BalloonInfo:
+#
+# Information about the guest balloon device.
+#
+# @actual: the logical size of the VM in bytes
+#          Formula used: logical_vm_size = vm_ram_size - balloon_size
+#
+# Since: 0.14.0
+#
+##
+{ 'struct': 'BalloonInfo', 'data': {'actual': 'int' } }
+
+##
+# @query-balloon:
+#
+# Return information about the balloon device.
+#
+# Returns: - @BalloonInfo on success
+#          - If the balloon driver is enabled but not functional because the KVM
+#            kernel module cannot support it, KvmMissingCap
+#          - If no balloon device is present, DeviceNotActive
+#
+# Since: 0.14.0
+#
+# Example:
+#
+# -> { "execute": "query-balloon" }
+# <- { "return": {
+#          "actual": 1073741824,
+#       }
+#    }
+#
+##
+{ 'command': 'query-balloon', 'returns': 'BalloonInfo' }
+
+##
+# @BALLOON_CHANGE:
+#
+# Emitted when the guest changes the actual BALLOON level. This value is
+# equivalent to the @actual field return by the 'query-balloon' command
+#
+# @actual: the logical size of the VM in bytes
+#          Formula used: logical_vm_size = vm_ram_size - balloon_size
+#
+# Note: this event is rate-limited.
+#
+# Since: 1.2
+#
+# Example:
+#
+# <- { "event": "BALLOON_CHANGE",
+#      "data": { "actual": 944766976 },
+#      "timestamp": { "seconds": 1267020223, "microseconds": 435656 } }
+#
+##
+{ 'event': 'BALLOON_CHANGE',
+  'data': { 'actual': 'int' } }
diff --git a/qapi/misc.json b/qapi/misc.json
index a667fdf03e5..7a14c50094d 100644
--- a/qapi/misc.json
+++ b/qapi/misc.json
@@ -187,65 +187,6 @@ 
 { 'command': 'query-iothreads', 'returns': ['IOThreadInfo'],
   'allow-preconfig': true }
 
-##
-# @BalloonInfo:
-#
-# Information about the guest balloon device.
-#
-# @actual: the logical size of the VM in bytes
-#          Formula used: logical_vm_size = vm_ram_size - balloon_size
-#
-# Since: 0.14.0
-#
-##
-{ 'struct': 'BalloonInfo', 'data': {'actual': 'int' } }
-
-##
-# @query-balloon:
-#
-# Return information about the balloon device.
-#
-# Returns: - @BalloonInfo on success
-#          - If the balloon driver is enabled but not functional because the KVM
-#            kernel module cannot support it, KvmMissingCap
-#          - If no balloon device is present, DeviceNotActive
-#
-# Since: 0.14.0
-#
-# Example:
-#
-# -> { "execute": "query-balloon" }
-# <- { "return": {
-#          "actual": 1073741824,
-#       }
-#    }
-#
-##
-{ 'command': 'query-balloon', 'returns': 'BalloonInfo' }
-
-##
-# @BALLOON_CHANGE:
-#
-# Emitted when the guest changes the actual BALLOON level. This value is
-# equivalent to the @actual field return by the 'query-balloon' command
-#
-# @actual: the logical size of the VM in bytes
-#          Formula used: logical_vm_size = vm_ram_size - balloon_size
-#
-# Note: this event is rate-limited.
-#
-# Since: 1.2
-#
-# Example:
-#
-# <- { "event": "BALLOON_CHANGE",
-#      "data": { "actual": 944766976 },
-#      "timestamp": { "seconds": 1267020223, "microseconds": 435656 } }
-#
-##
-{ 'event': 'BALLOON_CHANGE',
-  'data': { 'actual': 'int' } }
-
 ##
 # @PciMemoryRange:
 #
@@ -756,37 +697,6 @@ 
 ##
 { 'command': 'inject-nmi' }
 
-##
-# @balloon:
-#
-# Request the balloon driver to change its balloon size.
-#
-# @value: the target logical size of the VM in bytes
-#         We can deduce the size of the balloon using this formula:
-#            logical_vm_size = vm_ram_size - balloon_size
-#         From it we have: balloon_size = vm_ram_size - @value
-#
-# Returns: - Nothing on success
-#          - If the balloon driver is enabled but not functional because the KVM
-#            kernel module cannot support it, KvmMissingCap
-#          - If no balloon device is present, DeviceNotActive
-#
-# Notes: This command just issues a request to the guest.  When it returns,
-#        the balloon size may not have changed.  A guest can change the balloon
-#        size independent of this command.
-#
-# Since: 0.14.0
-#
-# Example:
-#
-# -> { "execute": "balloon", "arguments": { "value": 536870912 } }
-# <- { "return": {} }
-#
-# With a 2.5GiB guest this command inflated the balloon to 3GiB.
-#
-##
-{ 'command': 'balloon', 'data': {'value': 'int'} }
-
 ##
 # @human-monitor-command:
 #
diff --git a/include/sysemu/balloon.h b/include/sysemu/balloon.h
index 20a2defe3aa..867687b73ac 100644
--- a/include/sysemu/balloon.h
+++ b/include/sysemu/balloon.h
@@ -15,7 +15,7 @@ 
 #define QEMU_BALLOON_H
 
 #include "exec/cpu-common.h"
-#include "qapi/qapi-types-misc.h"
+#include "qapi/qapi-types-machine.h"
 
 typedef void (QEMUBalloonEvent)(void *opaque, ram_addr_t target);
 typedef void (QEMUBalloonStatus)(void *opaque, BalloonInfo *info);
diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
index 22cb5df717b..b22b5beda3c 100644
--- a/hw/virtio/virtio-balloon.c
+++ b/hw/virtio/virtio-balloon.c
@@ -24,7 +24,7 @@ 
 #include "hw/virtio/virtio-balloon.h"
 #include "exec/address-spaces.h"
 #include "qapi/error.h"
-#include "qapi/qapi-events-misc.h"
+#include "qapi/qapi-events-machine.h"
 #include "qapi/visitor.h"
 #include "trace.h"
 #include "qemu/error-report.h"
diff --git a/monitor/hmp-cmds.c b/monitor/hmp-cmds.c
index 7711726fd22..de01ba20845 100644
--- a/monitor/hmp-cmds.c
+++ b/monitor/hmp-cmds.c
@@ -32,6 +32,7 @@ 
 #include "qapi/qapi-commands-block.h"
 #include "qapi/qapi-commands-char.h"
 #include "qapi/qapi-commands-control.h"
+#include "qapi/qapi-commands-machine.h"
 #include "qapi/qapi-commands-migration.h"
 #include "qapi/qapi-commands-misc.h"
 #include "qapi/qapi-commands-net.h"
diff --git a/softmmu/balloon.c b/softmmu/balloon.c
index 23452295cd9..e0e8969a4b9 100644
--- a/softmmu/balloon.c
+++ b/softmmu/balloon.c
@@ -29,7 +29,7 @@ 
 #include "sysemu/kvm.h"
 #include "sysemu/balloon.h"
 #include "qapi/error.h"
-#include "qapi/qapi-commands-misc.h"
+#include "qapi/qapi-commands-machine.h"
 #include "qapi/qmp/qerror.h"
 #include "trace.h"