- 18 2月, 2019 11 次提交
-
-
由 Marc-André Lureau 提交于
A few targets don't emit RTC_CHANGE, we could restrict the event to the tagets that do emit it. Note: There is a lot more of events & commands that we could restrict to capable targets, with the cost of some additional complexity, but the benefit of added correctness and better introspection. Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Message-Id: <20190214152251.2073-19-armbru@redhat.com>
-
由 Markus Armbruster 提交于
query-events doesn't reflect compile-time configuration. Instead of fixing that, deprecate the command in favor of query-qmp-schema. Libvirt prefers query-qmp-schema as of commit 22d7222ec0 "qemu: caps: Don't call 'query-events' when we probe events from QMP schema". It'll be in the next release. Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20190214152251.2073-18-armbru@redhat.com>
-
由 Marc-André Lureau 提交于
This command is no longer needed, the schema has compile-time configuration conditions. Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Message-Id: <20190214152251.2073-16-armbru@redhat.com>
-
由 Marc-André Lureau 提交于
It depends on TARGET_PPC || TARGET_ARM || TARGET_I386 || TARGET_S390X. Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Acked-by: NCornelia Huck <cohuck@redhat.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Message-Id: <20190214152251.2073-15-armbru@redhat.com>
-
由 Marc-André Lureau 提交于
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Acked-by: NCornelia Huck <cohuck@redhat.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Message-Id: <20190214152251.2073-14-armbru@redhat.com>
-
由 Marc-André Lureau 提交于
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Message-Id: <20190214152251.2073-13-armbru@redhat.com>
-
由 Marc-André Lureau 提交于
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Acked-by: NCornelia Huck <cohuck@redhat.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Message-Id: <20190214152251.2073-12-armbru@redhat.com>
-
由 Marc-André Lureau 提交于
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Acked-by: NCornelia Huck <cohuck@redhat.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Message-Id: <20190214152251.2073-11-armbru@redhat.com>
-
由 Marc-André Lureau 提交于
Move rtc-reset-reinjection and SEV in target.json and make them conditional on TARGET_I386. Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Message-Id: <20190214152251.2073-10-armbru@redhat.com>
-
由 Markus Armbruster 提交于
We can't add appropriate target-specific conditionals to misc.json, because that would make all of misc.json unusable in target-independent code. To keep misc.json target-independent, we need to split off target-dependent target.json. This commit doesn't actually split off anything, it merely creates the empty module. The next few patches will move stuff from misc.json there. Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20190214152251.2073-9-armbru@redhat.com>
-
由 Markus Armbruster 提交于
Adding QAPI's .o to util-obj-y, common-obj-y and obj-y is spread over three places: Makefile.objs takes care of target-independent generated code, Makefile.target of target-dependent generated code, and qapi/Makefile.objs of (target-independent) hand-written code. Do everything in qapi/Makefile.objs. Suggested-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20190214152251.2073-8-armbru@redhat.com>
-
- 14 2月, 2019 1 次提交
-
-
由 Eric Blake 提交于
Present since commit b25b387f (2.10). Signed-off-by: NEric Blake <eblake@redhat.com> Reviewed-by: NThomas Huth <thuth@redhat.com> Message-Id: <20190206202848.16999-1-eblake@redhat.com> Signed-off-by: NLaurent Vivier <laurent@vivier.eu>
-
- 12 2月, 2019 1 次提交
-
-
由 Andrey Shinkevich 提交于
In the 'Format specific information' section of the 'qemu-img info' command output, the supplemental information about existing QCOW2 bitmaps will be shown, such as a bitmap name, flags and granularity: image: /vz/vmprivate/VM1/harddisk.hdd file format: qcow2 virtual size: 64G (68719476736 bytes) disk size: 3.0M cluster_size: 1048576 Format specific information: compat: 1.1 lazy refcounts: true bitmaps: [0]: flags: [0]: in-use [1]: auto name: back-up1 granularity: 65536 [1]: flags: [0]: in-use [1]: auto name: back-up2 granularity: 65536 refcount bits: 16 corrupt: false Signed-off-by: NAndrey Shinkevich <andrey.shinkevich@virtuozzo.com> Reviewed-by: NEric Blake <eblake@redhat.com> Reviewed-by: NVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <1549638368-530182-3-git-send-email-andrey.shinkevich@virtuozzo.com> Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 01 2月, 2019 2 次提交
-
-
由 Kevin Wolf 提交于
Clarify that the number of extents provided in BlockdevCreateOptionsVmdk must match the number of extents that will actually be used. Providing more extents will result in an error now. This requires adapting the test case to provide the right number of extents. Signed-off-by: NKevin Wolf <kwolf@redhat.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
-
由 Fam Zheng 提交于
This makes VMDK support blockdev-create. The implementation reuses the image creation code in vmdk_co_create_opts which now acceptes a callback pointer to "retrieve" BlockBackend pointers from the caller. This way we separate the logic between file/extent acquisition and initialization. The QAPI command parameters are mostly the same as the old create_opts except the dropped legacy @compat6 switch, which is redundant with @hwversion. Signed-off-by: NFam Zheng <famz@redhat.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
- 31 1月, 2019 1 次提交
-
-
Add a new command, returning block nodes (and their users) graph. Signed-off-by: NVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-id: 20181221170909.25584-2-vsementsov@virtuozzo.com Signed-off-by: NMax Reitz <mreitz@redhat.com>
-
- 24 1月, 2019 3 次提交
-
-
由 Ryan El Kochta 提交于
This patch adds a new option to the input-linux object: grab-toggle=[key-combo] The key combination can be one of the following: * ctrl-ctrl * alt-alt * meta-meta * scrolllock * ctrl-scrolllock The user can pick any of these key combinations. The VM's grab of the evdev device will be toggled when the key combination is pressed. Any invalid setting will result in an error. No setting will result in the current default of ctrl-ctrl. The right and left ctrl key both work for Ctrl-Scrolllock. If scrolllock is selected as one of the grab-toggle keys, it will be entirely disabled and not passed to the guest at all. This is to prevent enabling it while attempting to leave or enter the VM. On the host, scrolllock can be disabled using xmodmap. First, find the modifier that Scroll_Lock is bound to: $ xmodmap -pm Then, remove Scroll_Lock from it, replacing modX with the modifier: $ xmodmap -e 'remove modX = Scroll_Lock' If Scroll_Lock is not bound to any modifier, it is already disabled. To save the changes, add them to your xinitrc. Ryan El Kochta (1): input-linux: customizable grab toggle keys v5 Signed-off-by: NRyan El Kochta <relkochta@gmail.com> Message-id: 20190123214555.12712-2-relkochta@gmail.com Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
Added examples for the qom-list, qom-get, and qom-set commands in qapi misc JSON file. Signed-off-by: NWainer dos Santos Moschetta <wainersm@redhat.com> Message-Id: <20181228194442.3506-1-wainersm@redhat.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
-
由 Markus Armbruster 提交于
The qapi_event_send_FOO() functions emit events like this: QMPEventFuncEmit emit; emit = qmp_event_get_func_emit(); if (!emit) { return; } qmp = qmp_event_build_dict("FOO"); [put event arguments into @qmp...] emit(QAPI_EVENT_FOO, qmp); The value of qmp_event_get_func_emit() depends only on the program: * In qemu-system-FOO, it's always monitor_qapi_event_queue. * In tests/test-qmp-event, it's always event_test_emit. * In all other programs, it's always null. This is exactly the kind of dependence the linker is supposed to resolve; we don't actually need an indirection. Note that things would fall apart if we linked more than one QAPI schema into a single program: each set of qapi_event_send_FOO() uses its own event enumeration, yet they share a single emit function. Which takes the event enumeration as an argument. Which one if there's more than one? More seriously: how does this work even now? qemu-system-FOO wants QAPIEvent, and passes a function taking that to qmp_event_set_func_emit(). test-qmp-event wants test_QAPIEvent, and passes a function taking that to qmp_event_set_func_emit(). It works by type trickery, of course: typedef void (*QMPEventFuncEmit)(unsigned event, QDict *dict); void qmp_event_set_func_emit(QMPEventFuncEmit emit); QMPEventFuncEmit qmp_event_get_func_emit(void); We use unsigned instead of the enumeration type. Relies on both enumerations boiling down to unsigned, which happens to be true for the compilers we use. Clean this up as follows: * Generate qapi_event_send_FOO() that call PREFIX_qapi_event_emit() instead of the value of qmp_event_set_func_emit(). * Generate a prototype for PREFIX_qapi_event_emit() into qapi-events.h. * PREFIX_ is empty for qapi/qapi-schema.json, and test_ for tests/qapi-schema/qapi-schema-test.json. It's qga_ for qga/qapi-schema.json, and doc-good- for tests/qapi-schema/doc-good.json, but those don't define any events. * Rename monitor_qapi_event_queue() to qapi_event_emit() instead of passing it to qmp_event_set_func_emit(). This takes care of qemu-system-FOO. * Rename event_test_emit() to test_qapi_event_emit() instead of passing it to qmp_event_set_func_emit(). This takes care of tests/test-qmp-event. * Add a qapi_event_emit() that does nothing to stubs/monitor.c. This takes care of all other programs that link code emitting QMP events. * Drop qmp_event_set_func_emit(), qmp_event_get_func_emit(). Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Message-Id: <20181218182234.28876-3-armbru@redhat.com> Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com> [Commit message typos fixed]
-
- 23 1月, 2019 1 次提交
-
-
由 Xiao Guangrong 提交于
It introduces a new statistic, pages-per-second, as bandwidth or mbps is not enough to measure the performance of posting pages out as we have compression, xbzrle, which can significantly reduce the amount of the data size, instead, pages-per-second is the one we want Signed-off-by: NXiao Guangrong <xiaoguangrong@tencent.com> Message-Id: <20190111063732.10484-2-xiaoguangrong@tencent.com> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com> With typo's Eric spotted fixed
-
- 15 1月, 2019 4 次提交
-
-
由 Eric Blake 提交于
Now that nbd-server-add can do the same functionality (well, other than making the exported bitmap name different than the underlying bitamp - but we argued that was not essential, since it is just as easy to create a new non-persistent bitmap with the desired name), we no longer need the experimental separate command. Signed-off-by: NEric Blake <eblake@redhat.com> Reviewed-by: NVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20190111194720.15671-7-eblake@redhat.com>
-
由 Eric Blake 提交于
With the experimental x-nbd-server-add-bitmap command, there was a window of time where an NBD client could see the export but not the associated dirty bitmap, which can cause a client that planned on using the dirty bitmap to be forced to treat the entire image as dirty as a safety fallback. Furthermore, if the QMP client successfully exports a disk but then fails to add the bitmap, it has to take on the burden of removing the export. Since we don't allow changing the exposed dirty bitmap (whether to a different bitmap, or removing advertisement of the bitmap), it is nicer to make the bitmap tied to the export at the time the export is created, with automatic failure to export if the bitmap is not available. The experimental command included an optional 'bitmap-export-name' field for remapping the name exposed over NBD to be different from the bitmap name stored on disk. However, my libvirt demo code for implementing differential backups on top of persistent bitmaps did not need to take advantage of that feature (it is instead possible to create a new temporary bitmap with the desired name, use block-dirty-bitmap-merge to merge one or more persistent bitmaps into the temporary, then associate the temporary with the NBD export, if control is needed over the exported bitmap name). Hence, I'm not copying that part of the experiment over to the stable addition. For more details on the libvirt demo, see https://www.redhat.com/archives/libvir-list/2018-October/msg01254.html, https://kvmforum2018.sched.com/event/FzuB/facilitating-incremental-backup-eric-blake-red-hat This patch focuses on the user interface, and reduces (but does not completely eliminate) the window where an NBD client can see the export but not the dirty bitmap, with less work to clean up after errors. Later patches will add further cleanups now that this interface is declared stable via a single QMP command, including removing the race window. Update test 223 to use the new interface. Signed-off-by: NEric Blake <eblake@redhat.com> Reviewed-by: NVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20190111194720.15671-6-eblake@redhat.com>
-
由 John Snow 提交于
The 'x' prefix was added because I was uncertain of the direction we'd take for the libvirt API. With the general approach solidified, I feel comfortable committing to this API for 4.0. Signed-off-by: NJohn Snow <jsnow@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com> Reviewed-by: NVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20181221093529.23855-5-jsnow@redhat.com> Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 John Snow 提交于
Especially outside of transactions, it is helpful to provide all-or-nothing semantics for bitmap merges. This facilitates the coalescing of multiple bitmaps into a single target for the "checkpoint" interpretation when assembling bitmaps that represent arbitrary points in time from component bitmaps. This is an incompatible change from the preliminary version of the API. Signed-off-by: NJohn Snow <jsnow@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com> Reviewed-by: NVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20181221093529.23855-4-jsnow@redhat.com> Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 22 12月, 2018 1 次提交
-
-
由 Yuval Shaia 提交于
pvrdma requires that the same GID attached to it will be attached to the backend device in the host. A new QMP messages is defined so pvrdma device can broadcast any change made to its GID table. This event is captured by libvirt which in turn will update the GID table in the backend device. Signed-off-by: NYuval Shaia <yuval.shaia@oracle.com> Reviewed-by: NMarcel Apfelbaum <marcel.apfelbaum@gmail.com> Acked-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NMarcel Apfelbaum <marcel.apfelbaum@gmail.com>
-
- 20 12月, 2018 1 次提交
-
-
由 Alex Williamson 提交于
Create properties to be able to define speeds and widths for PCIe links. The only tricky bit here is that our get and set callbacks translate from the fixed QAPI automagic enums to those we define in PCI code to represent the actual register segment value. Cc: Eric Blake <eblake@redhat.com> Tested-by: NGeoffrey McRae <geoff@hostfission.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NAlex Williamson <alex.williamson@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
- 18 12月, 2018 5 次提交
-
-
由 Daniel Henrique Barboza 提交于
The qmp/hmp command 'system_wakeup' is simply a direct call to 'qemu_system_wakeup_request' from vl.c. This function verifies if runstate is SUSPENDED and if the wake up reason is valid before proceeding. However, no error or warning is thrown if any of those pre-requirements isn't met. There is no way for the caller to differentiate between a successful wakeup or an error state caused when trying to wake up a guest that wasn't suspended. This means that system_wakeup is silently failing, which can be considered a bug. Adding error handling isn't an API break in this case - applications that didn't check the result will remain broken, the ones that check it will have a chance to deal with it. Adding to that, the commit before previous created a new QMP API called query-current-machine, with a new flag called wakeup-suspend-support, that indicates if the guest has the capability of waking up from suspended state. Although such guest will never reach SUSPENDED state and erroring it out in this scenario would suffice, it is more informative for the user to differentiate between a failure because the guest isn't suspended versus a failure because the guest does not have support for wake up at all. All this considered, this patch changes qmp_system_wakeup to check if the guest is capable of waking up from suspend, and if it is suspended. After this patch, this is the output of system_wakeup in a guest that does not have wake-up from suspend support (ppc64): (qemu) system_wakeup wake-up from suspend is not supported by this guest (qemu) And this is the output of system_wakeup in a x86 guest that has the support but isn't suspended: (qemu) system_wakeup Unable to wake up: guest is not in suspended state (qemu) Reported-by: NBalamuruhan S <bala24@linux.vnet.ibm.com> Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20181205194701.17836-4-danielhb413@gmail.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Acked-by: NEduardo Habkost <ehabkost@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
-
由 Daniel Henrique Barboza 提交于
When issuing the qmp/hmp 'system_wakeup' command, what happens in a nutshell is: - qmp_system_wakeup_request set runstate to RUNNING, sets a wakeup_reason and notify the event - in the main_loop, all vcpus are paused, a system reset is issued, all subscribers of wakeup_notifiers receives a notification, vcpus are then resumed and the wake up QAPI event is fired Note that this procedure alone doesn't ensure that the guest will awake from SUSPENDED state - the subscribers of the wake up event must take action to resume the guest, otherwise the guest will simply reboot. At this moment, only the ACPI machines via acpi_pm1_cnt_init and xen_hvm_init have wake-up from suspend support. However, only the presence of 'system_wakeup' is required for QGA to support 'guest-suspend-ram' and 'guest-suspend-hybrid' at this moment. This means that the user/management will expect to suspend the guest using one of those suspend commands and then resume execution using system_wakeup, regardless of the support offered in system_wakeup in the first place. This patch creates a new API called query-current-machine [1], that holds a new flag called 'wakeup-suspend-support' that indicates if the guest supports wake up from suspend via system_wakeup. The machine is considered to implement wake-up support if a call to a new 'qemu_register_wakeup_support' is made during its init, as it is now being done inside acpi_pm1_cnt_init and xen_hvm_init. This allows for any other machine type to declare wake-up support regardless of ACPI state or wakeup_notifiers subscription, making easier for newer implementations that might have their own mechanisms in the future. This is the expected output of query-current-machine when running a x86 guest: {"execute" : "query-current-machine"} {"return": {"wakeup-suspend-support": true}} Running the same x86 guest, but with the --no-acpi option: {"execute" : "query-current-machine"} {"return": {"wakeup-suspend-support": false}} This is the output when running a pseries guest: {"execute" : "query-current-machine"} {"return": {"wakeup-suspend-support": false}} With this extra tool, management can avoid situations where a guest that does not have proper suspend/wake capabilities ends up in inconsistent state (e.g. https://github.com/open-power-host-os/qemu/issues/31). [1] the decision of creating the query-current-machine API is based on discussions in the QEMU mailing list where it was decided that query-target wasn't a proper place to store the wake-up flag, neither was query-machines because this isn't a static property of the machine object. This new API can then be used to store other dynamic machine properties that are scattered around the code ATM. More info at: https://lists.gnu.org/archive/html/qemu-devel/2018-05/msg04235.htmlReported-by: NBalamuruhan S <bala24@linux.vnet.ibm.com> Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20181205194701.17836-2-danielhb413@gmail.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Acked-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
-
由 Dominik Csapak 提交于
It is interesting to know whether the shutdown cause was 'quit' or 'reset', especially when using "--no-reboot". In that case, a management layer can now determine if the guest wanted a reboot or shutdown, and can act accordingly. Changes the output of the reason in the iotests from 'host-qmp' to 'host-qmp-quit'. This does not break compatibility because the field was introduced in the same version. Signed-off-by: NDominik Csapak <d.csapak@proxmox.com> Message-Id: <20181205110131.23049-4-d.csapak@proxmox.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> [Commit message tweaked] Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
-
由 Dominik Csapak 提交于
This makes it possible to determine what the exact reason was for a RESET or a SHUTDOWN. A management layer might need the specific reason of those events to determine which cleanups or other actions it needs to do. This patch also updates the iotests to the new expected output that includes the reason. Signed-off-by: NDominik Csapak <d.csapak@proxmox.com> Message-Id: <20181205110131.23049-3-d.csapak@proxmox.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> [Commit message tweaked] Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
-
由 Dominik Csapak 提交于
Needed so the patch after next can add ShutdownCause to QMP events SHUTDOWN and RESET. Signed-off-by: NDominik Csapak <d.csapak@proxmox.com> Message-Id: <20181205110131.23049-2-d.csapak@proxmox.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
-
- 14 12月, 2018 6 次提交
-
-
由 Marc-André Lureau 提交于
Add #if defined(CONFIG_REPLICATION) in generated code, and adjust the code accordingly. Made conditional: * xen-set-replication, query-xen-replication-status, xen-colo-do-checkpoint Before the patch, we first register the commands unconditionally in generated code (requires a stub), then conditionally unregister in qmp_unregister_commands_hack(). Afterwards, we register only when CONFIG_REPLICATION. The command fails exactly the same, with CommandNotFound. Improvement, because now query-qmp-schema is accurate, and we're one step closer to killing qmp_unregister_commands_hack(). * enum BlockdevDriver value "replication" in command blockdev-add * BlockdevOptions variant @replication and related structures. Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Message-Id: <20181213123724.4866-23-marcandre.lureau@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
-
由 Marc-André Lureau 提交于
Now that member can be made conditional, let's make SPICE chardev conditional: * spiceport, spicevmc Before and after the patch for !CONFIG_SPICE, the error is the same ('spiceport' is not a valid char driver name). Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Message-Id: <20181213123724.4866-22-marcandre.lureau@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
-
由 Marc-André Lureau 提交于
Let's break the line before 'data'. While at it, improve a bit indentation/spacing. (I removed some alignment which are not helping much readability and become quickly inconsistent) Suggested-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20181208111606.8505-26-marcandre.lureau@redhat.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
-
由 David Hildenbrand 提交于
The input visitor has some problems right now, especially - unsigned type "Range" is used to process signed ranges, resulting in inconsistent behavior and ugly/magical code - uint64_t are parsed like int64_t, so big uint64_t values are not supported and error messages are misleading - lists/ranges of int64_t are accepted although no list is parsed and we should rather report an error - lists/ranges are preparsed using int64_t, making it hard to implement uint64_t values or uint64_t lists - types that don't support lists don't bail out - visiting beyond the end of a list is not handled properly - we don't actually parse lists, we parse *sets*: members are sorted, and duplicates eliminated So let's rewrite it by getting rid of usage of the type "Range" and properly supporting lists of int64_t and uint64_t (including ranges of both types), fixing the above mentioned issues. Lists of other types are not supported and will properly report an error. Virtual walks are now supported. Tests have to be fixed up: - Two BUGs were hardcoded that are fixed now - The string-input-visitor now actually returns a parsed list and not an ordered set. Please note that no users/callers have to be fixed up. Candidates using visit_type_uint16List() and friends are: - backends/hostmem.c:host_memory_backend_set_host_nodes() -- Code can deal with duplicates/unsorted lists - numa.c::query_memdev() -- via object_property_get_uint16List(), the list will still be sorted and without duplicates (via host_memory_backend_get_host_nodes()) - qapi-visit.c::visit_type_Memdev_members() - qapi-visit.c::visit_type_NumaNodeOptions_members() - qapi-visit.c::visit_type_RockerOfDpaGroup_members - qapi-visit.c::visit_type_RxFilterInfo_members() -- Not used with string-input-visitor. Reviewed-by: NEric Blake <eblake@redhat.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20181121164421.20780-7-david@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
-
由 David Hildenbrand 提交于
Let's use the new function. Just as current behavior, we have to consume the whole string (now it's just way clearer what's going on). Reviewed-by: NEric Blake <eblake@redhat.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20181121164421.20780-5-david@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
-
由 David Hildenbrand 提交于
The string-input-visitor happily accepts NaN and infinities when parsing numbers (doubles). They shouldn't. Fix that. Also, add two test cases, testing if "NaN" and "inf" is properly rejected. Reviewed-by: NEric Blake <eblake@redhat.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20181121164421.20780-4-david@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
-
- 12 12月, 2018 3 次提交
-
-
由 Alberto Garcia 提交于
The values specified in the documentation don't match the actual defaults set in qcrypto_block_luks_create(). Signed-off-by: NAlberto Garcia <berto@igalia.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Peter Xu 提交于
When a QMP client sends in-band commands more quickly that we can process them, we can either queue them without limit (QUEUE), drop commands when the queue is full (DROP), or suspend receiving commands when the queue is full (SUSPEND). None of them is ideal: * QUEUE lets a misbehaving client make QEMU eat memory without bounds. Not such a hot idea. * With DROP, the client has to cope with dropped in-band commands. To inform the client, we send a COMMAND_DROPPED event then. The event is flawed by design in two ways: it's ambiguous (see commit d621cfe0), and it brings back the "eat memory without bounds" problem. * With SUSPEND, the client has to manage the flow of in-band commands to keep the monitor available for out-of-band commands. We currently DROP. Switch to SUSPEND. Managing the flow of in-band commands to keep the monitor available for out-of-band commands isn't really hard: just count the number of "outstanding" in-band commands (commands sent minus replies received), and if it exceeds the limit, hold back additional ones until it drops below the limit again. Note that we need to be careful pairing the suspend with a resume, or else the monitor will hang, possibly forever. And here since we need to make sure both: (1) popping request from the req queue, and (2) reading length of the req queue will be in the same critical section, we let the pop function take the corresponding queue lock when there is a request, then we release the lock from the caller. Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: NPeter Xu <peterx@redhat.com> Message-Id: <20181009062718.1914-2-peterx@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
-
由 Kashyap Chamarthy 提交于
The intended functionality of QMP `cpu-add` is replaced with `device_add` (and `query-hotpluggable-cpus`). So let's deprecate `cpu-add`. A complete example of vCPU hotplug with the recommended way (using `device_add`) is provided as part of a seperate docs patch. Suggested-by: Eduardo Habkost <ehabkost@redhat.com Signed-off-by: NKashyap Chamarthy <kchamart@redhat.com> Message-Id: <20181030123526.26415-2-kchamart@redhat.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-