- 15 8月, 2019 27 次提交
-
-
由 Ivan Ren 提交于
Multifd sync will send MULTIFD_FLAG_SYNC flag info to destination, add these bytes to ram_counters record. Signed-off-by: NIvan Ren <ivanren@tencent.com> Suggested-by: NWei Yang <richardw.yang@linux.intel.com> Message-Id: <1564464816-21804-4-git-send-email-ivanren@tencent.com> Reviewed-by: NJuan Quintela <quintela@redhat.com> Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
-
由 Ivan Ren 提交于
Limit the speed of multifd migration through common speed limitation qemu file. Signed-off-by: NIvan Ren <ivanren@tencent.com> Message-Id: <1564464816-21804-3-git-send-email-ivanren@tencent.com> Reviewed-by: NWei Yang <richardw.yang@linux.intel.com> Reviewed-by: NJuan Quintela <quintela@redhat.com> Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
-
由 Ivan Ren 提交于
Add qemu_file_update_transfer for just update bytes_xfer for speed limitation. This will be used for further migration feature such as multifd migration. Signed-off-by: NIvan Ren <ivanren@tencent.com> Reviewed-by: NWei Yang <richardw.yang@linux.intel.com> Reviewed-by: NJuan Quintela <quintela@redhat.com> Message-Id: <1564464816-21804-2-git-send-email-ivanren@tencent.com> Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
-
由 Ivan Ren 提交于
This patch fix a multifd migration bug in migration speed calculation, this problem can be reproduced as follows: 1. start a vm and give a heavy memory write stress to prevent the vm be successfully migrated to destination 2. begin a migration with multifd 3. migrate for a long time [actually, this can be measured by transferred bytes] 4. migrate cancel 5. begin a new migration with multifd, the migration will directly run into migration_completion phase Reason as follows: Migration update bandwidth and s->threshold_size in function migration_update_counters after BUFFER_DELAY time: current_bytes = migration_total_bytes(s); transferred = current_bytes - s->iteration_initial_bytes; time_spent = current_time - s->iteration_start_time; bandwidth = (double)transferred / time_spent; s->threshold_size = bandwidth * s->parameters.downtime_limit; In multifd migration, migration_total_bytes function return qemu_ftell(s->to_dst_file) + ram_counters.multifd_bytes. s->iteration_initial_bytes will be initialized to 0 at every new migration, but ram_counters is a global variable, and history migration data will be accumulated. So if the ram_counters.multifd_bytes is big enough, it may lead pending_size >= s->threshold_size become false in migration_iteration_run after the first migration_update_counters. Signed-off-by: NIvan Ren <ivanren@tencent.com> Reviewed-by: NJuan Quintela <quintela@redhat.com> Reviewed-by: NWei Yang <richardw.yang@linux.intel.com> Suggested-by: NWei Yang <richardw.yang@linux.intel.com> Message-Id: <1564741121-1840-1-git-send-email-ivanren@tencent.com> Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
-
由 Wei Yang 提交于
MigrationState->bytes_xfer is only set to 0 in migrate_init(). Remove this unnecessary field. Signed-off-by: NWei Yang <richardw.yang@linux.intel.com> Message-Id: <20190402003106.17614-1-richardw.yang@linux.intel.com> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
-
由 Wei Yang 提交于
With the growth of migration capabilities, it is not proper to display them in "info migrate". Users are recommended to use "info migrate_capabiltiies" to list them. Signed-off-by: NWei Yang <richardw.yang@linux.intel.com> Suggested-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20190806003645.8426-1-richardw.yang@linux.intel.com> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
-
由 Wei Yang 提交于
Use QEMU_IS_ALIGNED for the check, it would be more consistent with other align calculations. Signed-off-by: NWei Yang <richardw.yang@linux.intel.com> Message-Id: <20190806004648.8659-3-richardw.yang@linux.intel.com> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
-
由 Wei Yang 提交于
The purpose of the calculation is to find a HostPage which is partially dirty. * fixup_start_addr points to the start of the HostPage to discard * run_start points to the next HostPage to check While in the middle stage, there would two cases for run_start: * aligned with HostPage means this is not partially dirty * not aligned means this is partially dirty When it is aligned, no work and calculation is necessary. run_start already points to the start of next HostPage and is ready to continue. When it is not aligned, the calculation could be simplified with: * fixup_start_addr = QEMU_ALIGN_DOWN(run_start, host_ratio) * run_start = QEMU_ALIGN_UP(run_start, host_ratio) By doing so, run_start always points to the next HostPage to check. fixup_start_addr always points to the HostPage to discard. Signed-off-by: NWei Yang <richardw.yang@linux.intel.com> Message-Id: <20190806004648.8659-2-richardw.yang@linux.intel.com> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
-
由 Wei Yang 提交于
In postcopy-ram.c, we provide three functions to discard certain RAMBlock range: * postcopy_discard_send_init() * postcopy_discard_send_range() * postcopy_discard_send_finish() Currently, we allocate/deallocate PostcopyDiscardState for each RAMBlock on sending discard information to destination. This is not necessary and the same data area could be reused for each RAMBlock. This patch defines PostcopyDiscardState a static variable. By doing so: 1) avoid memory allocation and deallocation to the system 2) avoid potential failure of memory allocation 3) hide some details for their users Signed-off-by: NWei Yang <richardw.yang@linux.intel.com> Message-Id: <20190724010721.2146-1-richardw.yang@linux.intel.com> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
-
由 Wei Yang 提交于
After cleanup, it would be clear to audience there are two cases ram_load: * precopy * postcopy And it is not necessary to check postcopy_running on each iteration for precopy. Signed-off-by: NWei Yang <richardw.yang@linux.intel.com> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20190725002023.2335-3-richardw.yang@linux.intel.com> Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
-
由 Wei Yang 提交于
It is not reasonable to continue when version_id mismatch. Signed-off-by: NWei Yang <richardw.yang@linux.intel.com> Message-Id: <20190722075339.25121-2-richardw.yang@linux.intel.com> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
-
由 Wei Yang 提交于
LOADVM_QUIT allows a command to quit all layers of nested loadvm loops, while current return value check is not that proper even it works now. Current return value check "ret & LOADVM_QUIT" would return true if bit[0] is 1. This would be true when ret is -1 which is used to indicate an error of handling a command. Since there is only one place return LOADVM_QUIT and no other combination of return value, use "ret == LOADVM_QUIT" would be more proper. Signed-off-by: NWei Yang <richardw.yang@linux.intel.com> Message-Id: <20190718064257.29218-1-richardw.yang@linux.intel.com> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
-
由 Wei Yang 提交于
RAMBlock->used_length is always passed to migration_bitmap_sync_range(), which could be retrieved from RAMBlock. Suggested-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NWei Yang <richardw.yang@linux.intel.com> Message-Id: <20190718012547.16373-1-richardw.yang@linux.intel.com> Reviewed-by: NPeter Xu <peterx@redhat.com> Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
-
由 Wei Yang 提交于
Use common helper function to check the state. Signed-off-by: NWei Yang <richardw.yang@linux.intel.com> Message-Id: <20190719071129.11880-1-richardw.yang@linux.intel.com> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
-
由 Wei Yang 提交于
There is only one place to set start_postcopy to true, qmp_migrate_start_postcopy(), which make sure start_postcopy could be set to true when migrate_postcopy() return true. So start_postcopy is true implies the other one. Signed-off-by: NWei Yang <richardw.yang@linux.intel.com> Message-Id: <20190718083747.5859-1-richardw.yang@linux.intel.com> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
-
由 Wei Yang 提交于
PostcopyState is already set to ADVISE at the beginning of loadvm_postcopy_handle_advise(). Remove the redundant set. Signed-off-by: NWei Yang <richardw.yang@linux.intel.com> Message-Id: <20190711080816.6405-1-richardw.yang@linux.intel.com> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
-
由 Wei Yang 提交于
in_postcopy and iterable_only are not SaveStateEntry specific, it would be more proper to check them out of iteration. Signed-off-by: NWei Yang <richardw.yang@linux.intel.com> Message-Id: <20190709140924.13291-4-richardw.yang@linux.intel.com> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
-
由 Wei Yang 提交于
This is a preparation patch for further cleanup. No functional change, just wrap two major part of qemu_savevm_state_complete_precopy() into function. Signed-off-by: NWei Yang <richardw.yang@linux.intel.com> Message-Id: <20190709140924.13291-3-richardw.yang@linux.intel.com> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
-
由 Wei Yang 提交于
It would be proper to flush file even for iterable_only case. Signed-off-by: NWei Yang <richardw.yang@linux.intel.com> Message-Id: <20190709140924.13291-2-richardw.yang@linux.intel.com> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
-
由 Wei Yang 提交于
This means it is not necessary to spare an extra variable to hold this condition. Use host_offset directly is fine. Signed-off-by: NWei Yang <richardw.yang@linux.intel.com> Message-Id: <20190710050814.31344-3-richardw.yang@linux.intel.com> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
-
由 Wei Yang 提交于
Use the same way for run_end to calculate run_start, which saves one operation. Signed-off-by: NWei Yang <richardw.yang@linux.intel.com> Message-Id: <20190710050814.31344-2-richardw.yang@linux.intel.com> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
-
由 Wei Yang 提交于
Since we break the loop when there is no more page to discard, we are sure the following process would find some page to discard. It is not necessary to check it again. Signed-off-by: NWei Yang <richardw.yang@linux.intel.com> Message-Id: <20190627020822.15485-4-richardw.yang@linux.intel.com> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
-
由 Wei Yang 提交于
When one is equal or bigger then end, it means there is no page to discard. Just break the loop in this case instead of processing it. No functional change, just refactor it a little. Signed-off-by: NWei Yang <richardw.yang@linux.intel.com> Message-Id: <20190627020822.15485-3-richardw.yang@linux.intel.com> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
-
由 Wei Yang 提交于
If one equals end, it means we have gone through the whole bitmap. Use a more restrict check to skip a unnecessary condition. Signed-off-by: NWei Yang <richardw.yang@linux.intel.com> Message-Id: <20190627020822.15485-2-richardw.yang@linux.intel.com> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
-
由 Wei Yang 提交于
Consolidate time information fill up into its function for better readability. Signed-off-by: NWei Yang <richardw.yang@linux.intel.com> Message-Id: <20190716005411.4156-1-richardw.yang@linux.intel.com> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
-
由 Marcel Apfelbaum 提交于
At some point vmxnet3 live migration stopped working and git-bisect didn't help finding a working version. The issue is the PCI configuration space is not being migrated successfully and MSIX remains masked at destination. Remove the migration differentiation between PCI and PCIe since the logic resides now inside VMSTATE_PCI_DEVICE. Remove also the VMXNET3_COMPAT_FLAG_DISABLE_PCIE based differentiation since at 'realize' time is decided if the device is PCI or PCIe, then the above macro is enough. Use the opportunity to move to the standard VMSTATE_MSIX instead of the deprecated SaveVMHandlers. Signed-off-by: NMarcel Apfelbaum <marcel.apfelbaum@gmail.com> Message-Id: <20190705010711.23277-1-marcel.apfelbaum@gmail.com> Tested-by: NSukrit Bhatnagar <skrtbhtngr@gmail.com> Reviewed-by: NDmitry Fleytman <dmitry.fleytman@gmail.com> Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
-
由 Yury Kotov 提交于
Currently, there is no information about error if outgoing migration was failed because of file channel errors. Example (QMP session): -> { "execute": "migrate", "arguments": { "uri": "exec:head -c 1" }} <- { "return": {} } ... -> { "execute": "query-migrate" } <- { "return": { "status": "failed" }} // There is not error's description And even in the QEMU's output there is nothing. This patch 1) Adds errp for the most of QEMUFileOps 2) Adds qemu_file_get_error_obj/qemu_file_set_error_obj 3) And finally using of qemu_file_get_error_obj in migration.c And now, the status for the mentioned fail will be: -> { "execute": "query-migrate" } <- { "return": { "status": "failed", "error-desc": "Unable to write to command: Broken pipe" }} Signed-off-by: NYury Kotov <yury-kotov@yandex-team.ru> Message-Id: <20190422103420.15686-1-yury-kotov@yandex-team.ru> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
-
- 13 8月, 2019 5 次提交
-
-
由 Peter Maydell 提交于
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Bin Meng 提交于
Currently the make rules are wrongly using qemu/virt opensbi image for sifive_u machine. Correct it. Signed-off-by: NBin Meng <bmeng.cn@gmail.com> Reviewed-by: NChih-Min Chao <chihmin.chao@sifive.com> Reviewed-by: NAlistair Francis <alistair.francis@wdc.com> Message-id: 1564812484-20385-1-git-send-email-bmeng.cn@gmail.com Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Peter Maydell 提交于
ppc patch queue 2019-08-13 (last minute qemu-4.1 fixes) Here's a very, very last minute pull request for qemu-4.1. This fixes two nasty bugs with the XIVE interrupt controller in "dual" mode (where the guest decides which interrupt controller it wants to use). One occurs when resetting the guest while I/O is active, and the other with migration of hotplugged CPUs. The timing here is very unfortunate. Alas, we only spotted these bugs very late, and I was sick last week, delaying analysis and fix even further. This series hasn't had nearly as much testing as I'd really like, but I'd still like to squeeze it into qemu-4.1 if possible, since definitely fixing two bad bugs seems like an acceptable tradeoff for the risk of introducing different bugs. # gpg: Signature made Tue 13 Aug 2019 07:56:42 BST # gpg: using RSA key 75F46586AE61A66CC44E87DC6C38CACA20D9B392 # gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>" [full] # gpg: aka "David Gibson (Red Hat) <dgibson@redhat.com>" [full] # gpg: aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>" [full] # gpg: aka "David Gibson (kernel.org) <dwg@kernel.org>" [unknown] # Primary key fingerprint: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392 * remotes/dgibson/tags/ppc-for-4.1-20190813: spapr/xive: Fix migration of hot-plugged CPUs spapr: Reset CAS & IRQ subsystem after devices Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Cédric Le Goater 提交于
The migration sequence of a guest using the XIVE exploitation mode relies on the fact that the states of all devices are restored before the machine is. This is not true for hot-plug devices such as CPUs which state come after the machine. This breaks migration because the thread interrupt context registers are not correctly set. Fix migration of hotplugged CPUs by restoring their context in the 'post_load' handler of the XiveTCTX model. Fixes: 277dd3d7 ("spapr/xive: add migration support for KVM") Signed-off-by: NCédric Le Goater <clg@kaod.org> Message-Id: <20190813064853.29310-1-clg@kaod.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 David Gibson 提交于
This fixes a nasty regression in qemu-4.1 for the 'pseries' machine, caused by the new "dual" interrupt controller model. Specifically, qemu can crash when used with KVM if a 'system_reset' is requested while there's active I/O in the guest. The problem is that in spapr_machine_reset() we: 1. Reset the CAS vector state spapr_ovec_cleanup(spapr->ov5_cas); 2. Reset all devices qemu_devices_reset() 3. Reset the irq subsystem spapr_irq_reset(); However (1) implicitly changes the interrupt delivery mode, because whether we're using XICS or XIVE depends on the CAS state. We don't properly initialize the new irq mode until (3) though - in particular setting up the KVM devices. During (2), we can temporarily drop the BQL allowing some irqs to be delivered which will go to an irq system that's not properly set up. Specifically, if the previous guest was in (KVM) XIVE mode, the CAS reset will put us back in XICS mode. kvm_kernel_irqchip() still returns true, because XIVE was using KVM, however XICs doesn't have its KVM components intialized and kernel_xics_fd == -1. When the irq is delivered it goes via ics_kvm_set_irq() which assert()s that kernel_xics_fd != -1. This change addresses the problem by delaying the CAS reset until after the devices reset. The device reset should quiesce all the devices so we won't get irqs delivered while we mess around with the IRQ. The CAS reset and irq re-initialize should also now be under the same BQL critical section so nothing else should be able to interrupt it either. We also move the spapr_irq_msi_reset() used in one of the legacy irq modes, since it logically makes sense at the same point as the spapr_irq_reset() (it's essentially an equivalent operation for older machine types). Since we don't need to switch between different interrupt controllers for those old machine types it shouldn't actually be broken in those cases though. Cc: Cédric Le Goater <clg@kaod.org> Fixes: b2e22477 "spapr: add a 'reset' method to the sPAPR IRQ backend" Fixes: 13db0cd9 "spapr: introduce a new sPAPR IRQ backend supporting XIVE and XICS" Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
- 12 8月, 2019 1 次提交
-
-
由 Gerd Hoffmann 提交于
Set QEMU_PCI_CAP_EXPRESS unconditionally in init(), then clear it in realize() in case the device is not connected to a PCIe bus. This makes sure the pci config space allocation is big enough, so accessing the PCIe extended config space doesn't overflow the pci config space buffer. PCI(e) config space is guest writable. Writes are limited by write mask (which probably is also filled with random stuff), so the guest can only flip enabled bits. But I suspect it still might be exploitable, so rather serious because it might be a host escape for the guest. On the other hand the device is probably not yet in widespread use. (For a QEMU version without this commit, a mitigation for the bug is available: use "-device bochs-display" as a conventional pci device only.) Cc: qemu-stable@nongnu.org Signed-off-by: NGerd Hoffmann <kraxel@redhat.com> Message-id: 20190812065221.20907-2-kraxel@redhat.com Reviewed-by: NAlex Williamson <alex.williamson@redhat.com> Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
- 07 8月, 2019 1 次提交
-
-
由 Peter Maydell 提交于
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
- 06 8月, 2019 6 次提交
-
-
由 Cornelia Huck 提交于
'edid' is a property of the virtio-gpu base device, so turning it off on virtio-gpu-pci is not enough (it misses -ccw). Turn it off on the base device instead. Fixes: 0a719662 ("edid: flip the default to enabled") Signed-off-by: NCornelia Huck <cohuck@redhat.com> Reviewed-by: NGerd Hoffmann <kraxel@redhat.com> Message-id: 20190806115819.16026-1-cohuck@redhat.com Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Peter Maydell 提交于
Block patches for 4.1.0-rc4: - Fix the backup block job when using copy offloading - Fix the mirror block job when using the write-blocking copy mode - Fix incremental backups after the image has been grown with the respective bitmap attached to it # gpg: Signature made Tue 06 Aug 2019 12:57:07 BST # gpg: using RSA key 91BEB60A30DB3E8857D11829F407DB0061D5CF40 # gpg: issuer "mreitz@redhat.com" # gpg: Good signature from "Max Reitz <mreitz@redhat.com>" [full] # Primary key fingerprint: 91BE B60A 30DB 3E88 57D1 1829 F407 DB00 61D5 CF40 * remotes/maxreitz/tags/pull-block-2019-08-06: block/backup: disable copy_range for compressed backup iotests: Test unaligned blocking mirror write mirror: Only mirror granularity-aligned chunks iotests: Test incremental backup after truncation util/hbitmap: update orig_size on truncate iotests: Test backup job with two guest writes backup: Copy only dirty areas Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
Enabled by default copy_range ignores compress option. It's definitely unexpected for user. It's broken since introduction of copy_range usage in backup in 9ded4a01. Signed-off-by: NVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-id: 20190730163251.755248-3-vsementsov@virtuozzo.com Reviewed-by: NJohn Snow <jsnow@redhat.com> Reviewed-by: NMax Reitz <mreitz@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: NMax Reitz <mreitz@redhat.com>
-
由 Max Reitz 提交于
Signed-off-by: NMax Reitz <mreitz@redhat.com> Message-id: 20190805113526.20319-1-mreitz@redhat.com Reviewed-by: NVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: NMax Reitz <mreitz@redhat.com>
-
由 Max Reitz 提交于
In write-blocking mode, all writes to the top node directly go to the target. We must only mirror chunks of data that are aligned to the job's granularity, because that is how the dirty bitmap works. Therefore, the request alignment for writes must be the job's granularity (in write-blocking mode). Unfortunately, this forces all reads and writes to have the same granularity (we only need this alignment for writes to the target, not the source), but that is something to be fixed another time. Cc: qemu-stable@nongnu.org Signed-off-by: NMax Reitz <mreitz@redhat.com> Message-id: 20190805153308.2657-1-mreitz@redhat.com Reviewed-by: NVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Fixes: d06107adSigned-off-by: NMax Reitz <mreitz@redhat.com>
-
由 Max Reitz 提交于
Signed-off-by: NMax Reitz <mreitz@redhat.com> Message-id: 20190805152840.32190-1-mreitz@redhat.com Signed-off-by: NMax Reitz <mreitz@redhat.com>
-