- 10 10月, 2019 2 次提交
-
-
由 Jonathon Jongsma 提交于
Add a qemu capbility to see if the standalone ramfb device is available. Reviewed-by: NCole Robinson <crobinso@redhat.com> Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com>
-
由 Jonathon Jongsma 提交于
When the bochs display type was added, the capability was never checked. Add that check in the same place as the other video device capability checks. Reviewed-by: NCole Robinson <crobinso@redhat.com> Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com>
-
- 09 10月, 2019 3 次提交
-
-
由 Michal Privoznik 提交于
This reverts commit a5a777a8. After previous commit the domain won't disappear while connecting to monitor. There's no need to ref monitor config then. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
-
由 Michal Privoznik 提交于
When connecting to qemu's monitor the @vm object is unlocked. This is justified - connecting may take a long time and we don't want to wait with the domain object locked. However, just before the domain object is locked again, the monitor's FD is registered in the event loop. Therefore, there is a small window where the event loop has a chance to call a handler for an event that occurred on the monitor FD but vm is not initalized properly just yet (i.e. priv->mon is not set). For instance, if there's an incoming migration, qemu creates its socket but then fails to initialize (for various reasons, I'm reproducing this by using hugepages but leaving the HP pool empty) then the following may happen: 1) qemuConnectMonitor() unlocks @vm 2) qemuMonitorOpen() connects to the monitor socket and by calling qemuMonitorOpenInternal() which subsequently calls qemuMonitorRegister() the event handler is installed 3) qemu fails to initialize and exit()-s, which closes the monitor 4) The even loop sees EOF on the monitor and the control gets to qemuProcessEventHandler() which locks @vm and calls processMonitorEOFEvent() which then calls qemuMonitorLastError(priv->mon). But priv->mon is not set just yet. 5) qemuMonitorLastError() dereferences NULL pointer The solution is to unlock the domain object for a shorter time and most importantly, register event handler with domain object locked so that any possible event processing is done only after @vm's private data was properly initialized. This issue is also mentioned in v4.2.0-99-ga5a777a8. Since we are unlocking @vm and locking it back, another thread might have destroyed the domain meanwhile. Therefore we have to check if domain is still active, and we have to do it at the same place where domain lock is acquired back, i.e. in qemuMonitorOpen(). This creates a small problem for our test suite which calls qemuMonitorOpen() directly and passes @vm which has no definition. This makes virDomainObjIsActive() call crash. Fortunately, allocating empty domain definition is sufficient. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
-
由 Jiri Denemark 提交于
QEMU 2.11 for ppc64 changed all CPU model names to lower case. Since libvirt can't change the model names for compatibility reasons, we need to translate the matching lower case models to the names known by libvirt. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
- 08 10月, 2019 2 次提交
-
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1755303 With the recent work in daemon split and socket activation daemons can come and go. They can and will be started many times during a session which results in objects being autostarted multiple times. This is not optimal. Use virDriverShouldAutostart() to determine if autostart should be done or not. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Michal Privoznik 提交于
The comment says that the function kills domains and networks. This is obviously not the case. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 07 10月, 2019 14 次提交
-
-
由 Fabiano Fidêncio 提交于
086c19d6 added bochs-display capability but didn't fill in the info for domain capabilities. Signed-off-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: NErik Skultety <eskultet@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Collin Walling 提交于
This command is hooked into the virsh hypervisor-cpu-compare command. As such, the CPU model XML provided to the command will be compared to the hypervisor CPU contained in the QEMU capabilities file for the appropriate QEMU binary (for s390x, this CPU definition can be observed via virsh domcapabilities). QMP will report that the XML CPU is either identical to, a subset of, or incompatible with the hypervisor CPU. s390 can also report that the XML CPU is a "superset" of the hypervisor CPU. This response is presented as incompatible, as this CPU model would not be able to run on the hypervisor. Signed-off-by: NCollin Walling <walling@linux.ibm.com> Reviewed-by: NDaniel Henrique Barboza <danielh413@gmail.com> Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com> Message-Id: <1568924706-2311-15-git-send-email-walling@linux.ibm.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Collin Walling 提交于
This capability enables comparison of CPU models via QMP. Signed-off-by: NCollin Walling <walling@linux.ibm.com> Reviewed-by: NDaniel Henrique Barboza <danielh413@gmail.com> Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com> Message-Id: <1568924706-2311-13-git-send-email-walling@linux.ibm.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Collin Walling 提交于
Interfaces with QEMU to compare CPU models. The command takes two CPU models, A and B, that are given a model name and an optional list of CPU features. Through the query-cpu-model-comparison command issued via QMP, a result is produced that contains the comparison evaluation string (identical, superset, subset, incompatible). The list of properties (aka CPU features) that is returned from the QMP response is ignored. Signed-off-by: NCollin Walling <walling@linux.ibm.com> Reviewed-by: NDaniel Henrique Barboza <danielh413@gmail.com> Message-Id: <1568924706-2311-12-git-send-email-walling@linux.ibm.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Collin Walling 提交于
Perform a full CPU model expansion on the result of the baselined model name when the features flag is present. Signed-off-by: NCollin Walling <walling@linux.ibm.com> Message-Id: <1568924706-2311-11-git-send-email-walling@linux.ibm.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Collin Walling 提交于
This command is hooked into the virsh hypervisor-cpu-baseline command. The CPU models provided in the XML sent to the command will be baselined via the query-cpu-model-baseline QMP command. The resulting CPU model will be reported. Signed-off-by: NCollin Walling <walling@linux.ibm.com> Reviewed-by: NDaniel Henrique Barboza <danielh413@gmail.com> Message-Id: <1568924706-2311-10-git-send-email-walling@linux.ibm.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Collin Walling 提交于
This capability enables baselining of CPU models via QMP. Signed-off-by: NCollin Walling <walling@linux.ibm.com> Reviewed-by: NDaniel Henrique Barboza <danielh413@gmail.com> Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com> Message-Id: <1568924706-2311-9-git-send-email-walling@linux.ibm.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Collin Walling 提交于
Interfaces with QEMU to baseline CPU models. The command takes two CPU models, A and B, that are given a model name and an optional list of CPU features. Through the query-cpu-model-baseline command issued via QMP, a result is produced that contains a new baselined CPU model that is guaranteed to run on both A and B. Signed-off-by: NCollin Walling <walling@linux.ibm.com> Reviewed-by: NDaniel Henrique Barboza <danielh413@gmail.com> Message-Id: <1568924706-2311-8-git-send-email-walling@linux.ibm.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Collin Walling 提交于
Modify the error messages in qemuMonitorJSONParseCPUModelData to print the command name provided to the function. Signed-off-by: NCollin Walling <walling@linux.ibm.com> Message-Id: <1568924706-2311-7-git-send-email-walling@linux.ibm.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Collin Walling 提交于
Some older s390 CPU models (e.g. z900) will not report props as a response from query-cpu-model-expansion. As such, we should make the props field optional when parsing the return data from the QMP response. Signed-off-by: NCollin Walling <walling@linux.ibm.com> Message-Id: <1568924706-2311-6-git-send-email-walling@linux.ibm.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Collin Walling 提交于
query-cpu-model-baseline/comparison will accept a list of features as part of the command. Since CPUs may be defined with CPU feature policies, let's parse it to the appropriate boolean that the QMP command expects. A feature that is set to required, force, or if it is a hypervisor CPU feature (-1), then set the property value to true. Otherwise (optional, disabled) set the value to false. Signed-off-by: NCollin Walling <walling@linux.ibm.com> Message-Id: <1568924706-2311-5-git-send-email-walling@linux.ibm.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Collin Walling 提交于
When expanding a CPU model via query-cpu-model-expansion, any features that were a part of the original model are discarded. For exmaple, when expanding modelA with features f1, f2, a full expansion may reveal feature f3, but the expanded model will not include f1 or f2. Let's pass a virCPUDefPtr to the expansion function in preparation for taking features into consideration. Signed-off-by: NCollin Walling <walling@linux.ibm.com> Message-Id: <1568924706-2311-4-git-send-email-walling@linux.ibm.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Collin Walling 提交于
With refactoring most of the expansion function, let's take care of some additional cleanups. Signed-off-by: NCollin Walling <walling@linux.ibm.com> Message-Id: <1568924706-2311-3-git-send-email-walling@linux.ibm.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Collin Walling 提交于
Refactor some code in qemuMonitorJSONGetCPUModelExpansion to be later used for the comparison and baseline functions. Signed-off-by: NCollin Walling <walling@linux.ibm.com> Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com> Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <1568924706-2311-2-git-send-email-walling@linux.ibm.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
-
- 02 10月, 2019 2 次提交
-
-
由 Pavel Mores 提交于
Parseability of disk name is now checked in qemuDomainDeviceDefValidateDisk(). Signed-off-by: NPavel Mores <pmores@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Pavel Mores 提交于
The way in which the qemu driver generates aliases for disks involves ignoring the partition number part of a target dev name. This means that all partitions of a block device and the device itself all end up with the same alias. If multiple such disks are specified in XML, the resulting name clash makes qemu invocation fail. Since attaching partitions to qemu VMs doesn't seem to make much sense anyway, disallow partitions in target specifications altogether. https://bugzilla.redhat.com/show_bug.cgi?id=1346265Signed-off-by: NPavel Mores <pmores@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 01 10月, 2019 3 次提交
-
-
由 Michal Privoznik 提交于
In the domain capabilities XML there are FW image paths printed. There are two sources for the image paths (in order of preference): 1) firmware descriptor files - as returned by qemuFirmwareGetSupported() 2) a compile time list of FW:NRAM pairs which can be overridden in qemu.conf If either of those contains a duplicate FW image path (which is a valid use case) it is printed twice in the capabilities XML. While it's technically not a bug, it doesn't look good. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Tested-by: NKashyap Chamarthy <kchamart@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Peter Krempa 提交于
Similarly to the snapshot code there's no reason to modify current checkpoint until we are done creating the new one. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Peter Krempa 提交于
Since commit f1056279 we store whether a snapshot is current globally rather than locally in the snapshot object. This means that we don't have to unset the current snapshot prior to taking/reverting the snapshot and we can do it only when everything is done successfully. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 30 9月, 2019 14 次提交
-
-
由 Daniel P. Berrangé 提交于
Ensure that the FD we're passing to QEMU is actually open, so we get a sane error message upfront instead of telling QEMU to use a closed FD. Reviewed-by: NMichal Privoznik <mprivozn@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
The video private data was not initializing the vhostuser FD causing us to attempt to close FD 0 many times over. Fixes commit ca60ecfa Author: Marc-André Lureau <marcandre.lureau@redhat.com> Date: Mon Sep 23 14:44:36 2019 +0400 qemu: add qemuDomainVideoPrivate Since the test suite does not invoke qemuExtDevicesStart(), no vhost_user_fd will be present when generating test XML. To deal with this we can must a fake FD number. While the current XML is using FD == 0, we pick a very interesting number that's unlikely to be a real FD, so that we're more likely to see any mistakes closing the invalid FD. Reviewed-by: NMichal Privoznik <mprivozn@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Peter Krempa 提交于
Now it's not used outside of qemu_monitor_json.c. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Peter Krempa 提交于
Use the generators provided by the monitor code instead. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Peter Krempa 提交于
Use the new generator residing in the monitor code rather than directly using qemuMonitorJSONTransactionAdd. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Peter Krempa 提交于
Unify with other code that generates parameters for the 'transaction' command. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Peter Krempa 提交于
Rather than generating the transaction contents in random places add a unified set of APIs to generate the contents for a 'transaction' for the dirty bitmap APIs. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Peter Krempa 提交于
The QEMU_CAPS_INCREMENTAL_BACKUP will be enabled once all bits of the incremental backup feature work as expected which means also properly interacting with blockjobs and snapshots. Thus we can allow blockjobs and snapshots if QEMU_CAPS_INCREMENTAL_BACKUP is present even when checkpoints exist. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Peter Krempa 提交于
Rather than having to fix 5 places once we support the combination, add a function called by all the blockjob/snapshot APIs. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Peter Krempa 提交于
Checkpoints by themselves are not very useful for anything else than testing the few bitmap interactions that are currently implemented. It's very unlikely that anybody used this feature and thus we can disable it until we have a more complete implementation ready. Additionally the code for deleting checkpoints has many broken failure scenarios which should be fixed first. This will require support of deleting a bitmap in a qemu 'transaction' which was not released yet. Curious users obviously can use the qemu namespace in the XML to enable this for experiments: <domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> ... <qemu:capabilities> <qemu:add capability='incremental-backup'/> </qemu:capabilities> </domain> Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Peter Krempa 提交于
Add a new all-covering capability which will be used to interlock incremental backup support until all bits are ready. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Peter Krempa 提交于
Add a 'cleanup' label and use jumps as we do in other places. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Peter Krempa 提交于
Once somebody is motivated enough to add the support for the quiesce flag or offline checkpoint deletion they are welcome to do so but we don't need to have a reminder. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Peter Krempa 提交于
Use VIR_AUTO* helpers and get rid of the 'cleanup' label. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-