qemu/qapi/meson.build

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

149 lines
3.3 KiB
Meson
Raw Normal View History

util_ss.add(files(
'opts-visitor.c',
'qapi-clone-visitor.c',
'qapi-dealloc-visitor.c',
'qapi-forward-visitor.c',
'qapi-util.c',
'qapi-visit-core.c',
'qobject-input-visitor.c',
'qobject-output-visitor.c',
'string-input-visitor.c',
'string-output-visitor.c',
))
if have_system
util_ss.add(files('qapi-type-helpers.c'))
endif
qga: Allow building of the guest agent without system emulators or tools If configuring with "--disable-system --disable-user --enable-guest-agent" the linking currently fails with: qga/qemu-ga.p/commands.c.o: In function `qmp_command_info': build/../../home/thuth/devel/qemu/qga/commands.c:70: undefined reference to `qmp_command_name' build/../../home/thuth/devel/qemu/qga/commands.c:71: undefined reference to `qmp_command_is_enabled' build/../../home/thuth/devel/qemu/qga/commands.c:72: undefined reference to `qmp_has_success_response' qga/qemu-ga.p/commands.c.o: In function `qmp_guest_info': build/../../home/thuth/devel/qemu/qga/commands.c:82: undefined reference to `qmp_for_each_command' qga/qemu-ga.p/commands.c.o: In function `qmp_guest_exec': build/../../home/thuth/devel/qemu/qga/commands.c:410: undefined reference to `qbase64_decode' qga/qemu-ga.p/channel-posix.c.o: In function `ga_channel_open': build/../../home/thuth/devel/qemu/qga/channel-posix.c:214: undefined reference to `unix_listen' build/../../home/thuth/devel/qemu/qga/channel-posix.c:228: undefined reference to `socket_parse' build/../../home/thuth/devel/qemu/qga/channel-posix.c:234: undefined reference to `socket_listen' qga/qemu-ga.p/commands-posix.c.o: In function `qmp_guest_file_write': build/../../home/thuth/devel/qemu/qga/commands-posix.c:527: undefined reference to `qbase64_decode' Let's make sure that we also compile and link the required files if the system emulators have not been enabled. Message-Id: <20221110083626.31899-1-thuth@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
2022-11-10 11:36:26 +03:00
if have_system or have_tools or have_ga
util_ss.add(files(
'qmp-dispatch.c',
'qmp-event.c',
'qmp-registry.c',
))
endif
qapi_all_modules = [
'authz',
'block',
'block-core',
'block-export',
'char',
'common',
'compat',
'control',
'crypto',
'cxl',
'dump',
qmp: Added new command to retrieve eBPF blob. Now, the binary objects may be retrieved by id. It would require for future qmp commands that may require specific eBPF blob. Added command "request-ebpf". This command returns eBPF program encoded base64. The program taken from the skeleton and essentially is an ELF object that can be loaded in the future with libbpf. The reason to use the command to provide the eBPF object instead of a separate artifact was to avoid issues related to finding the eBPF itself. eBPF object is an ELF binary that contains the eBPF program and eBPF map description(BTF). Overall, eBPF object should contain the program and enough metadata to create/load eBPF with libbpf. As the eBPF maps/program should correspond to QEMU, the eBPF can't be used from different QEMU build. The first solution was a helper that comes with QEMU and loads appropriate eBPF objects. And the issue is to find a proper helper if the system has several different QEMUs installed and/or built from the source, which helpers may not be compatible. Another issue is QEMU updating while there is a running QEMU instance. With an updated helper, it may not be possible to hotplug virtio-net device to the already running QEMU. Overall, requesting the eBPF object from QEMU itself solves possible failures with acceptable effort. Links: [PATCH 3/5] qmp: Added the helper stamp check. https://lore.kernel.org/all/20230219162100.174318-4-andrew@daynix.com/ Signed-off-by: Andrew Melnychenko <andrew@daynix.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2024-03-12 13:57:57 +03:00
'ebpf',
'error',
'introspect',
'job',
'machine-common',
'machine',
'machine-target',
'migration',
'misc',
'misc-target',
'net',
'pragma',
'qom',
'replay',
'run-state',
'sockets',
qmp: Support for querying stats Gathering statistics is important for development, for monitoring and for performance measurement. There are tools such as kvm_stat that do this and they rely on the _user_ knowing the interesting data points rather than the tool (which can treat them as opaque). The commands introduced in this commit introduce QMP support for querying stats; the goal is to take the capabilities of these tools and making them available throughout the whole virtualization stack, so that one can observe, monitor and measure virtual machines without having shell access + root on the host that runs them. query-stats returns a list of all stats per target type (only VM and vCPU to start); future commits add extra options for specifying stat names, vCPU qom paths, and providers. All these are used by the HMP command "info stats". Because of the development usecases around statistics, a good HMP interface is important. query-stats-schemas returns a list of stats included in each target type, with an option for specifying the provider. The concepts in the schema are based on the KVM binary stats' own introspection data, just translated to QAPI. There are two reasons to have a separate schema that is not tied to the QAPI schema. The first is the contents of the schemas: the new introspection data provides different information than the QAPI data, namely unit of measurement, how the numbers are gathered and change (peak/instant/cumulative/histogram), and histogram bucket sizes. There's really no reason to have this kind of metadata in the QAPI introspection schema (except possibly for the unit of measure, but there's a very weak justification). Another reason is the dynamicity of the schema. The QAPI introspection data is very much static; and while QOM is somewhat more dynamic, generally we consider that to be a bug rather than a feature these days. On the other hand, the statistics that are exposed by QEMU might be passed through from another source, such as KVM, and the disadvantages of manually updating the QAPI schema for outweight the benefits from vetting the statistics and filtering out anything that seems "too unstable". Running old QEMU with new kernel is a supported usecase; if old QEMU cannot expose statistics from a new kernel, or if a kernel developer needs to change QEMU before gathering new info from the new kernel, then that is a poor user interface. The framework provides a method to register callbacks for these QMP commands. Most of the work in fact is done by the callbacks, and a large majority of this patch is new QAPI structs and commands. Examples (with KVM stats): - Query all VM stats: { "execute": "query-stats", "arguments" : { "target": "vm" } } { "return": [ { "provider": "kvm", "stats": [ { "name": "max_mmu_page_hash_collisions", "value": 0 }, { "name": "max_mmu_rmap_size", "value": 0 }, { "name": "nx_lpage_splits", "value": 148 }, ... ] }, { "provider": "xyz", "stats": [ ... ] } ] } - Query all vCPU stats: { "execute": "query-stats", "arguments" : { "target": "vcpu" } } { "return": [ { "provider": "kvm", "qom_path": "/machine/unattached/device[0]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, { "provider": "kvm", "qom_path": "/machine/unattached/device[1]" "stats": [ { "name": "guest_mode", "value": 0 }, { "name": "directed_yield_successful", "value": 0 }, { "name": "directed_yield_attempted", "value": 106 }, ... ] }, ] } - Retrieve the schemas: { "execute": "query-stats-schemas" } { "return": [ { "provider": "kvm", "target": "vcpu", "stats": [ { "name": "guest_mode", "unit": "none", "base": 10, "exponent": 0, "type": "instant" }, { "name": "directed_yield_successful", "unit": "none", "base": 10, "exponent": 0, "type": "cumulative" }, ... ] }, { "provider": "kvm", "target": "vm", "stats": [ { "name": "max_mmu_page_hash_collisions", "unit": "none", "base": 10, "exponent": 0, "type": "peak" }, ... ] }, { "provider": "xyz", "target": "vm", "stats": [ ... ] } ] } Signed-off-by: Mark Kanda <mark.kanda@oracle.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-02-15 18:04:31 +03:00
'stats',
'trace',
'transaction',
'virtio',
'yank',
]
if have_system
qapi_all_modules += [
'acpi',
'audio',
'cryptodev',
'qdev',
'pci',
'rdma',
'rocker',
'tpm',
]
endif
if have_system or have_tools
qapi_all_modules += [
'ui',
]
endif
qapi_nonmodule_outputs = [
'qapi-introspect.c', 'qapi-introspect.h',
'qapi-types.c', 'qapi-types.h',
'qapi-visit.h', 'qapi-visit.c',
'qapi-commands.h', 'qapi-commands.c',
'qapi-init-commands.h', 'qapi-init-commands.c',
'qapi-events.h', 'qapi-events.c',
'qapi-emit-events.c', 'qapi-emit-events.h',
]
# First build all sources
qapi_util_outputs = [
'qapi-builtin-types.c', 'qapi-builtin-visit.c',
'qapi-builtin-types.h', 'qapi-builtin-visit.h',
]
qapi_inputs = []
qapi_specific_outputs = []
foreach module : qapi_all_modules
qapi_inputs += [ files(module + '.json') ]
qapi_module_outputs = [
'qapi-types-@0@.c'.format(module),
'qapi-types-@0@.h'.format(module),
'qapi-visit-@0@.c'.format(module),
'qapi-visit-@0@.h'.format(module),
]
if have_system or have_tools
qapi_module_outputs += [
'qapi-events-@0@.c'.format(module),
'qapi-events-@0@.h'.format(module),
'qapi-commands-@0@.c'.format(module),
'qapi-commands-@0@.h'.format(module),
'qapi-commands-@0@.trace-events'.format(module),
]
endif
if module.endswith('-target')
qapi_specific_outputs += qapi_module_outputs
else
qapi_util_outputs += qapi_module_outputs
endif
endforeach
qapi_files = custom_target('shared QAPI source files',
output: qapi_util_outputs + qapi_specific_outputs + qapi_nonmodule_outputs,
input: [ files('qapi-schema.json') ],
command: [ qapi_gen, '-o', 'qapi', '-b', '@INPUT0@' ],
depend_files: [ qapi_inputs, qapi_gen_depends ])
# Now go through all the outputs and add them to the right sourceset.
# These loops must be synchronized with the output of the above custom target.
i = 0
foreach output : qapi_util_outputs
if output.endswith('.h')
genh += qapi_files[i]
endif
if output.endswith('.trace-events')
qapi_trace_events += qapi_files[i]
endif
util_ss.add(qapi_files[i])
i = i + 1
endforeach
foreach output : qapi_specific_outputs + qapi_nonmodule_outputs
if output.endswith('.h')
genh += qapi_files[i]
endif
if output.endswith('.trace-events')
qapi_trace_events += qapi_files[i]
endif
specific_ss.add(when: 'CONFIG_SYSTEM_ONLY', if_true: qapi_files[i])
i = i + 1
endforeach