- 17 3月, 2017 2 次提交
-
-
由 Paolo Bonzini 提交于
When icount is active, tb_add_jump is surprisingly called with an out of bounds basic block index. I have no idea how that can work, but it does not seem like a good idea. Clear *last_tb for all TB_EXIT_ICOUNT_EXPIRED cases, even when all you have to do is refill icount_extra. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 43d70ddf) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Daniel P. Berrange 提交于
Wayland always uses evdev as its input source, so QEMU can use the existing evdev keymap data Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> Tested-by: NStefan Hajnoczi <stefanha@redhat.com> Message-id: 20161201094117.16407-1-berrange@redhat.com Signed-off-by: NGerd Hoffmann <kraxel@redhat.com> (cherry picked from commit a8ffb372) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
- 15 12月, 2016 1 次提交
-
-
由 Maxime Coquelin 提交于
This patch fixes a cross-version migration regression introduced by commit d1b4259f ("virtio-bus: Plug devices after features are negotiated"). The problem is encountered when host's vhost backend does not support VIRTIO_F_VERSION_1, and migration is initiated from a v2.7 or prior machine with virtio-pci modern capabilities enabled to a v2.8 machine. In this case, modern capabilities get exposed to the guest by the source, whereas the target will detect version 1 is not supported so will only expose legacy capabilities. The problem is fixed by introducing a new "x-ignore-backend-features" property, which is set in v2.7 and prior compatibility modes. Doing this, v2.7 machine keeps its broken behaviour (enabling modern while version is not supported), and newer machines will behave correctly. Reported-by: NMichael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: NMarcel Apfelbaum <marcel@redhat.com> Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Tested-by: NMichael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: NMaxime Coquelin <maxime.coquelin@redhat.com> Message-id: 20161214163035.3297-1-maxime.coquelin@redhat.com Suggested-by: NStefan Hajnoczi <stefanha@redhat.com> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Cornelia Huck <cornelia.huck@de.ibm.com> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: NMarcel Apfelbaum <marcel@redhat.com> Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com> Tested-by: NMichael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: NMaxime Coquelin <maxime.coquelin@redhat.com> Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
-
- 30 11月, 2016 1 次提交
-
-
由 Laszlo Ersek 提交于
* Commit 3e76099a ("loader: Allow a custom AddressSpace when loading ROMs") introduced the "Rom.as" field: (1) It modified the utility callers of rom_insert() to take "as" as a new parameter from *their* callers, and set "rom->as" from that parameter. The functions covered were rom_add_file() and rom_add_elf_program(). (2) It also modified rom_insert() itself, to auto-assign "&address_space_memory", in case the external caller passed -- and the utility caller forwarded -- as=NULL. Except, commit 3e76099a forgot to update the third utility caller of rom_insert(), under point (1), namely rom_add_blob(). * Later, commit 5e774eb3 ("loader: Add AddressSpace loading support to uImages") added the load_uimage_as() function, and the rom_add_blob_fixed_as() function-like macro, with the necessary changes elsewhere to propagate the new "as" parameter to rom_add_blob(): load_uimage_as() load_uboot_image() rom_add_blob_fixed_as() rom_add_blob() At this point, the signature (and workings) of rom_add_blob() had been broken already, and the rom_add_blob_fixed_as() macro passed its "_as" parameter to rom_add_blob() as "callback_opaque". Given that the "fw_callback" parameter itself was set to NULL (correctly), this did no additional damage (the opaque arg would never be used), but ultimately it broke the new functionality of load_uimage_as(). * The load_uimage_as() function would be put to use in one of the later patches, commit e481a1f6 ("generic-loader: Add a generic loader"). * We can fix this only in a unified patch now. Append "AddressSpace *as" to the signature of rom_add_blob(), and handle the new parameter. Pass NULL from all current callers, except from rom_add_blob_fixed_as(), where "_as" has to be bumped to the proper position. * Note that rom_add_file() rejects the case when both "mr" and "as" are passed in as non-NULL. The action that this is apparently supposed to prevent is the rom->mr = mr; assignment (that's the only place where the "mr" parameter is used in rom_add_file()). In rom_add_blob() though, we have no "mr" parameter, and the actions done on the fw_cfg branch: if (fw_file_name && fw_cfg) { if (mc->rom_file_has_mr) { data = rom_set_mr(rom, OBJECT(fw_cfg), devpath); mr = rom->mr; } else { data = rom->data; } reflect those that are performed by rom_add_file() too (with mr==NULL): if (rom->fw_file && fw_cfg) { if ((!option_rom || mc->option_rom_has_mr) && mc->rom_file_has_mr) { data = rom_set_mr(rom, OBJECT(fw_cfg), devpath); } else { data = rom->data; } Hence we need no additional restrictions in rom_add_blob(). * Stable is not affected as both problematic commits appeared first in v2.8.0-rc0. Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Alistair Francis <alistair.francis@xilinx.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Michael Walle <michael@walle.cc> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Shannon Zhao <zhaoshenglong@huawei.com> Cc: qemu-arm@nongnu.org Cc: qemu-devel@nongnu.org Fixes: 3e76099a Fixes: 5e774eb3Signed-off-by: NLaszlo Ersek <lersek@redhat.com> Reviewed-by: NAlistair Francis <alistair.francis@xilinx.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
- 28 11月, 2016 1 次提交
-
-
由 Dr. David Alan Gilbert 提交于
To keep backwards migration compatibility allow us to turn pcspk migration off. Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20161128133201.16104-3-dgilbert@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 23 11月, 2016 7 次提交
-
-
由 David Gibson 提交于
daa23699 "spapr_pci: Add a 64-bit MMIO window" subtly broke migration from qemu-2.7 to the current version. It split the device's MMIO window into two pieces for 32-bit and 64-bit MMIO. The patch included backwards compatibility code to convert the old property into the new format. However, the property value was also transferred in the migration stream and compared with a (probably unwise) VMSTATE_EQUAL. So, the "raw" value from 2.7 is compared to the new style converted value from (pre-)2.8 giving a mismatch and migration failure. Along with the actual field that caused the breakage, there are several other ill-advised VMSTATE_EQUAL()s. To fix forwards migration, we read the values in the stream into scratch variables and ignore them, instead of comparing for equality. To fix backwards migration, we populate those scratch variables in pre_save() with adjusted values to match the old behaviour. To permit the eventual possibility of removing this cruft from the stream, we only include these compatibility fields if a new 'pre-2.8-migration' property is set. We clear it on the pseries-2.8 machine type, which obviously can't be migrated backwards, but set it on earlier machine type versions. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: NThomas Huth <thuth@redhat.com> Reviewed-by: NGreg Kurz <groug@kaod.org> Reviewed-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
-
由 David Gibson 提交于
include/migration/cpu.h defines VMSTATE_UINTTL() and several variants for migrating target_ulong fields. It's defined in terms of VMSTATE_UINT32() or VMSTATE_UINT64() as appropriate. It doesn't, however, include a VMSTATE_UINTTL_TEST() variant, which I'm going to need shortly. So, add it. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: NThomas Huth <thuth@redhat.com> Reviewed-by: NGreg Kurz <groug@kaod.org>
-
由 Michael Roth 提交于
With the additional of the OV5_HP_EVT option vector, we now have certain functionality (namely, memory unplug) that checks at run-time for whether or not the guest negotiated the option via CAS. Because we don't currently migrate these negotiated values, we are unable to unplug memory from a guest after it's been migrated until after the guest is rebooted and CAS-negotiation is repeated. This patch fixes this by adding CAS-negotiated options to the migration stream. We do this using a subsection, since the negotiated value of OV5_HP_EVT is the only option currently needed to maintain proper functionality for a running guest. Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Bobby Bingham 提交于
In the user emulation code path, tlb_vaddr_to_host erronesously passed vaddr as the guest address to be translated, instead of addr, the parameter which actually contained the guest address. This resulted in incorrect addresses being used when emulating block copy (mvc/mvpg) and block clear (xc) instructions for the s390x target. Signed-off-by: NBobby Bingham <koorogi@koorogi.info> Message-Id: <20161113050523.23909-1-koorogi@koorogi.info> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Juergen Gross 提交于
Create a qdev plugged to the xen-sysbus for each new backend device. This device can be used as a parent for all needed devices of that backend. The id of the new device will be "xen-<type>-<dev>" with <type> being the xen backend type (e.g. "qdisk") and <dev> the xen backend number of the type under which it is to be found in xenstore. Signed-off-by: NJuergen Gross <jgross@suse.com> Reviewed-by: NStefano Stabellini <sstabellini@kernel.org> Signed-off-by: NStefano Stabellini <sstabellini@kernel.org>
-
由 Juergen Gross 提交于
In order to have an easy way to add a new qdev with a specific id carve out the needed functionality from qdev_device_add() into a new function qdev_set_id(). Signed-off-by: NJuergen Gross <jgross@suse.com> Reviewed-by: NStefano Stabellini <sstabellini@kernel.org> Signed-off-by: NStefano Stabellini <sstabellini@kernel.org>
-
由 Juergen Gross 提交于
Add a bus for Xen backend devices in order to be able to establish a dedicated device path for pluggable devices. Signed-off-by: NJuergen Gross <jgross@suse.com> Reviewed-by: NStefano Stabellini <sstabellini@kernel.org> Signed-off-by: NStefano Stabellini <sstabellini@kernel.org>
-
- 18 11月, 2016 2 次提交
-
-
由 Paolo Bonzini 提交于
Dataplane has been omitting forever the step of setting ISR when an interrupt is raised. This caused little breakage, because the specification actually says that ISR may not be updated in MSI mode. Some versions of the Windows drivers however didn't clear MSI mode correctly, and proceeded using polling mode (using ISR, not the used ring index!) for crashdump and hibernation. If it were just crashdump and hibernation it would not be a big deal, but recent releases of Windows do not really shut down, but rather log out and hibernate to make the next startup faster. Hence, this manifested as a more serious hang during shutdown with e.g. Windows 8.1 and virtio-win 1.8.0 RPMs. Newer versions fixed this, while older versions do not use MSI at all. The failure has always been there for virtio dataplane, but it became visible after commits 9ffe337c ("virtio-blk: always use dataplane path if ioeventfd is active", 2016-10-30) and ad07cd69 ("virtio-scsi: always use dataplane path if ioeventfd is active", 2016-10-30) made virtio-blk and virtio-scsi always use the dataplane code under KVM. The good news therefore is that it was not a bug in the patches---they were doing exactly what they were meant for, i.e. shake out remaining dataplane bugs. The fix is not hard, so it's worth arranging for the broken drivers. The virtio_should_notify+event_notifier_set pair that is common to virtio-blk and virtio-scsi dataplane is replaced with a new public function virtio_notify_irqfd that also sets ISR. The irqfd emulation code now need not set ISR anymore, so virtio_irq is removed. Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com> Tested-by: NFarhan Ali <alifm@linux.vnet.ibm.com> Tested-by: NAlex Williamson <alex.williamson@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Paolo Bonzini 提交于
Following the recent refactoring of virtio notifiers [1], more specifically the patch ed08a2a0 ("virtio: use virtio_bus_set_host_notifier to start/stop ioeventfd") that uses virtio_bus_set_host_notifier [2] by default, core virtio code requires 'ioeventfd_started' to be set to true/false when the host notifiers are configured. When vhost is stopped and started, however, there is a stop followed by another start. Since ioeventfd_started was never set to true, the 'stop' operation triggered by virtio_bus_set_host_notifier() will not result in a call to virtio_pci_ioeventfd_assign(assign=false). This leaves the memory regions with stale notifiers and results on the next start triggering the following assertion: kvm_mem_ioeventfd_add: error adding ioeventfd: File exists Aborted This patch reintroduces (hopefully in a cleaner way) the concept that was present with ioeventfd_disabled before the refactoring. When ioeventfd_grabbed>0, ioeventfd_started tracks whether ioeventfd should be enabled or not, but ioeventfd is actually not started at all until vhost releases the host notifiers. [1] http://lists.nongnu.org/archive/html/qemu-devel/2016-10/msg07748.html [2] http://lists.nongnu.org/archive/html/qemu-devel/2016-10/msg07760.htmlReported-by: NFelipe Franciosi <felipe@nutanix.com> Reported-by: NChristian Borntraeger <borntraeger@de.ibm.com> Reported-by: NAlex Williamson <alex.williamson@redhat.com> Fixes: ed08a2a0 ("virtio: use virtio_bus_set_host_notifier to start/stop ioeventfd") Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com> Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com> Tested-by: NAlexey Kardashevskiy <aik@ozlabs.ru> Tested-by: NFarhan Ali <alifm@linux.vnet.ibm.com> Tested-by: NAlex Williamson <alex.williamson@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
- 16 11月, 2016 2 次提交
-
-
由 Igor Mammedov 提交于
Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Message-Id: <1479301481-197333-1-git-send-email-imammedo@redhat.com> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Igor Mammedov 提交于
This reverts commit 080ac219. Legacy FW_CFG_NB_CPUS will be reused instead of 'etc/boot-cpus' fw_cfg file since it does the same and there is no point to maintaing duplicate guest ABI, if it can be helped. Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Message-Id: <1479212236-183810-2-git-send-email-imammedo@redhat.com> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
- 15 11月, 2016 19 次提交
-
-
由 Greg Kurz 提交于
These are not used anymore. Signed-off-by: NGreg Kurz <groug@kaod.org> Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Greg Kurz 提交于
The legacy vring layout is not used anymore as we use the separate mappings even for legacy devices. This patch simply removes it. This also fixes a bug with virtio 1 devices when the vring descriptor table is mapped at a higher address than the used vring because the following function may return an insanely great value: hwaddr virtio_queue_get_ring_size(VirtIODevice *vdev, int n) { return vdev->vq[n].vring.used - vdev->vq[n].vring.desc + virtio_queue_get_used_size(vdev, n); } and the mapping fails. Signed-off-by: NGreg Kurz <groug@kaod.org> Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Greg Kurz 提交于
With virtio 1, the vring layout is split in 3 separate regions of contiguous memory for the descriptor table, the available ring and the used ring, as opposed with legacy virtio which uses a single region. In case of memory re-mapping, the code ensures it doesn't affect the vring mapping. This is done in vhost_verify_ring_mappings() which assumes the device is legacy. This patch changes vhost_verify_ring_mappings() to check the mappings of each part of the vring separately. This works for legacy mappings as well. Cc: qemu-stable@nongnu.org Signed-off-by: NGreg Kurz <groug@kaod.org> Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Xiao Guangrong 提交于
Rename it to nvdimm_plug() Suggested-by: NIgor Mammedov <imammedo@redhat.com> Signed-off-by: NXiao Guangrong <guangrong.xiao@linux.intel.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com> Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
-
由 Xiao Guangrong 提交于
as they use completely different way to handle hotplug event Suggested-by: NIgor Mammedov <imammedo@redhat.com> Signed-off-by: NXiao Guangrong <guangrong.xiao@linux.intel.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com> Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
-
由 Xiao Guangrong 提交于
as there is a global lock to protect vm-exit handlers and QMP/monitor, this lock can be dropped Suggested-by: NIgor Mammedov <imammedo@redhat.com> Signed-off-by: NXiao Guangrong <guangrong.xiao@linux.intel.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com> Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
-
由 Xiao Guangrong 提交于
as nvdimm acpi is okay to build fit when the nvdimm device has not been 'realized' Suggested-by: NIgor Mammedov <imammedo@redhat.com> Signed-off-by: NXiao Guangrong <guangrong.xiao@linux.intel.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com> Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
-
由 Michael S. Tsirkin 提交于
Legacy features are those that transitional devices only expose on the legacy interface. Allow different ones per device class. Cc: qemu-stable@nongnu.org # dependency for the next patch Signed-off-by: NMichael S. Tsirkin <mst@redhat.com> Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com>
-
由 Peter Xu 提交于
We should not use cpu_to_le16() here, instead each of device/function value is stored in a 8 byte field. Signed-off-by: NPeter Xu <peterx@redhat.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Peter Xu 提交于
Signed-off-by: NPeter Xu <peterx@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Ladi Prosek 提交于
The function does not fully initialize the returned VirtQueueElement and should be used only internally from the virtio module. Signed-off-by: NLadi Prosek <lprosek@redhat.com> Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Ladi Prosek 提交于
The function undoes the effect of virtqueue_pop and doesn't do anything destructive or irreversible so virtqueue_unpop is a more fitting name. Signed-off-by: NLadi Prosek <lprosek@redhat.com> Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 John Snow 提交于
Refactor backup_start as backup_job_create, which only creates the job, but does not automatically start it. The old interface, 'backup_start', is not kept in favor of limiting the number of nearly-identical interfaces that would have to be edited to keep up with QAPI changes in the future. Callers that wish to synchronously start the backup_block_job can instead just call block_job_start immediately after calling backup_job_create. Transactions are updated to use the new interface, calling block_job_start only during the .commit phase, which helps prevent race conditions where jobs may finish before we even finish building the transaction. This may happen, for instance, during empty block backup jobs. Reported-by: NVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: NJohn Snow <jsnow@redhat.com> Message-id: 1478587839-9834-6-git-send-email-jsnow@redhat.com Signed-off-by: NJeff Cody <jcody@redhat.com>
-
由 John Snow 提交于
Instead of automatically starting jobs at creation time via backup_start et al, we'd like to return a job object pointer that can be started manually at later point in time. For now, add the block_job_start mechanism and start the jobs automatically as we have been doing, with conversions job-by-job coming in later patches. Of note: cancellation of unstarted jobs will perform all the normal cleanup as if the job had started, particularly abort and clean. The only difference is that we will not emit any events, because the job never actually started. Signed-off-by: NJohn Snow <jsnow@redhat.com> Message-id: 1478587839-9834-5-git-send-email-jsnow@redhat.com Signed-off-by: NJeff Cody <jcody@redhat.com>
-
由 John Snow 提交于
Add an explicit start field to specify the entrypoint. We already have ownership of the coroutine itself AND managing the lifetime of the coroutine, let's take control of creation of the coroutine, too. This will allow us to delay creation of the actual coroutine until we know we'll actually start a BlockJob in block_job_start. This avoids the sticky question of how to "un-create" a Coroutine that hasn't been started yet. Signed-off-by: NJohn Snow <jsnow@redhat.com> Reviewed-by: NKevin Wolf <kwolf@redhat.com> Message-id: 1478587839-9834-4-git-send-email-jsnow@redhat.com Signed-off-by: NJeff Cody <jcody@redhat.com>
-
由 John Snow 提交于
Cleaning up after we have deferred to the main thread but before the transaction has converged can be dangerous and result in deadlocks if the job cleanup invokes any BH polling loops. A job may attempt to begin cleaning up, but may induce another job to enter its cleanup routine. The second job, part of our same transaction, will block waiting for the first job to finish, so neither job may now make progress. To rectify this, allow jobs to register a cleanup operation that will always run regardless of if the job was in a transaction or not, and if the transaction job group completed successfully or not. Move sensitive cleanup to this callback instead which is guaranteed to be run only after the transaction has converged, which removes sensitive timing constraints from said cleanup. Furthermore, in future patches these cleanup operations will be performed regardless of whether or not we actually started the job. Therefore, cleanup callbacks should essentially confine themselves to undoing create operations, e.g. setup actions taken in what is now backup_start. Reported-by: NVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: NJohn Snow <jsnow@redhat.com> Reviewed-by: NKevin Wolf <kwolf@redhat.com> Message-id: 1478587839-9834-3-git-send-email-jsnow@redhat.com Signed-off-by: NJeff Cody <jcody@redhat.com>
-
由 Cédric Le Goater 提交于
The XSCOM addresses for the core registers are encoded in a slightly different way on POWER8 and POWER9. Signed-off-by: NCédric Le Goater <clg@kaod.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Cédric Le Goater 提交于
PnvChip is defined twice and this can confuse old compilers : CC ppc64-softmmu/hw/ppc/pnv_xscom.o In file included from qemu.git/hw/ppc/pnv.c:29: qemu.git/include/hw/ppc/pnv.h:60: error: redefinition of typedef ‘PnvChip’ qemu.git/include/hw/ppc/pnv_xscom.h:24: note: previous declaration of ‘PnvChip’ was here make[1]: *** [hw/ppc/pnv.o] Error 1 make[1]: *** Waiting for unfinished jobs.... Signed-off-by: NCédric Le Goater <clg@kaod.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Nikunj A Dadhania 提交于
All the variants for rol/ror have a bug in case where the shift == 0. For example rol32, would generate: return (word << 0) | (word >> 32); Which though works, would be flagged as a runtime error on clang's sanitizer. Suggested-by: NRichard Henderson <rth@twiddle.net> Signed-off-by: NNikunj A Dadhania <nikunj@linux.vnet.ibm.com> Reviewed-by: NRichard Henderson <rth@twiddle.net> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
- 03 11月, 2016 1 次提交
-
-
由 Wei Liu 提交于
Introduce this field to control whether ACPI build is enabled by a particular machine or accelerator. It defaults to true if the machine itself supports ACPI build. Xen accelerator will disable it because Xen is in charge of building ACPI tables for the guest. Signed-off-by: NWei Liu <wei.liu2@citrix.com> Signed-off-by: NStefano Stabellini <sstabellini@kernel.org> Reviewed-by: NStefano Stabellini <sstabellini@kernel.org> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Tested-by: NSander Eikelenboom <linux@eikelenboom.it>
-
- 02 11月, 2016 4 次提交
-
-
由 Eric Blake 提交于
Upstream NBD protocol recently added the ability to efficiently write zeroes without having to send the zeroes over the wire, along with a flag to control whether the client wants to allow a hole. Note that when it comes to requiring full allocation, vs. permitting optimizations, the NBD spec intentionally picked a different sense for the flag; the rules in qemu are: MAY_UNMAP == 0: must write zeroes MAY_UNMAP == 1: may use holes if reads will see zeroes while in NBD, the rules are: FLAG_NO_HOLE == 1: must write zeroes FLAG_NO_HOLE == 0: may use holes if reads will see zeroes In all cases, the 'may use holes' scenario is optional (the server need not use a hole, and must not use a hole if subsequent reads would not see zeroes). Signed-off-by: NEric Blake <eblake@redhat.com> Message-Id: <1476469998-28592-16-git-send-email-eblake@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Eric Blake 提交于
NBD commit 6d34500b clarified how clients and servers are supposed to behave before closing a connection. It added NBD_REP_ERR_SHUTDOWN (for the server to announce it is about to go away during option haggling, so the client should quit sending NBD_OPT_* other than NBD_OPT_ABORT) and ESHUTDOWN (for the server to announce it is about to go away during transmission, so the client should quit sending NBD_CMD_* other than NBD_CMD_DISC). It also clarified that NBD_OPT_ABORT gets a reply, while NBD_CMD_DISC does not. This patch merely adds the missing reply to NBD_OPT_ABORT and teaches the client to recognize server errors. Actually teaching the server to send NBD_REP_ERR_SHUTDOWN or ESHUTDOWN would require knowing that the server has been requested to shut down soon (maybe we could do that by installing a SIGINT handler in qemu-nbd, which transitions from RUNNING to a new state that waits for the client to react, rather than just out-right quitting - but that's a bigger task for another day). Signed-off-by: NEric Blake <eblake@redhat.com> Message-Id: <1476469998-28592-15-git-send-email-eblake@redhat.com> [Move dummy ESHUTDOWN to include/qemu/osdep.h. - Paolo] Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Eric Blake 提交于
The NBD Protocol allows the server and client to mutually agree on a shorter handshake (omit the 124 bytes of reserved 0), via the server advertising NBD_FLAG_NO_ZEROES and the client acknowledging with NBD_FLAG_C_NO_ZEROES (only possible in newstyle, whether or not it is fixed newstyle). It doesn't shave much off the wire, but we might as well implement it. Signed-off-by: NEric Blake <eblake@redhat.com> Reviewed-by: NAlex Bligh <alex@alex.org.uk> Message-Id: <1476469998-28592-13-git-send-email-eblake@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Eric Blake 提交于
Rather than open-coding each option request, it's easier to have common helper functions do the work. That in turn requires having convenient packed types for handling option requests and replies. Signed-off-by: NEric Blake <eblake@redhat.com> Message-Id: <1476469998-28592-9-git-send-email-eblake@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-