- 29 11月, 2016 2 次提交
-
-
由 Jan Beulich 提交于
There's no point setting fields always receiving the same value on each iteration, as handle_ioreq() doesn't alter them anyway. Set state and count once ahead of the loop, drop the redundant clearing of data_is_ptr, and avoid the meaningless (because count is 1) setting of df altogether. Also avoid doing an unsigned long calculation of size when the field to be initialized is only 32 bits wide (and the shift value in the range 0...3). Signed-off-by: NJan Beulich <jbeulich@suse.com> Reviewed-by: NPaul Durrant <paul.durrant@citrix.com> Reviewed-by: NStefano Stabellini <sstabellini@kernel.org> Signed-off-by: NStefano Stabellini <sstabellini@kernel.org>
-
由 Jan Beulich 提交于
We should not consume the second slot if it didn't get written yet. Normal writers - i.e. Xen - would not update write_pointer between the two writes, but the page may get fiddled with by the guest itself, and we're better off avoiding to enter an infinite loop in that case. Reported-by: Nyanghongke <yanghongke@huawei.com> Signed-off-by: NJan Beulich <jbeulich@suse.com> Reviewed-by: NPaul Durrant <paul.durrant@citrix.com> Reviewed-by: NStefano Stabellini <sstabellini@kernel.org> Signed-off-by: NStefano Stabellini <sstabellini@kernel.org>
-
- 24 11月, 2016 1 次提交
-
-
由 Olaf Hering 提交于
The guest sends discard requests as u64 sector/count pairs, but the block layer operates internally with s64/s32 pairs. The conversion leads to IO errors in the guest, the discard request is not processed. domU.cfg: 'vdev=xvda, format=qcow2, backendtype=qdisk, target=/x.qcow2' domU: mkfs.ext4 -F /dev/xvda Discarding device blocks: failed - Input/output error Fix this by splitting the request into chunks of BDRV_REQUEST_MAX_SECTORS. Add input range checking to avoid overflow. Fixes f3135204 ("xen_disk: add discard support") Signed-off-by: NOlaf Hering <olaf@aepfle.de> Reviewed-by: NEric Blake <eblake@redhat.com> Reviewed-by: NStefano Stabellini <sstabellini@kernel.org>
-
- 23 11月, 2016 9 次提交
-
-
由 Stefan Hajnoczi 提交于
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
-
由 Stefan Hajnoczi 提交于
Xen 2016/11/22 # gpg: Signature made Tue 22 Nov 2016 06:41:23 PM GMT # gpg: using RSA key 0x894F8F4870E1AE90 # gpg: Good signature from "Stefano Stabellini <sstabellini@kernel.org>" # gpg: aka "Stefano Stabellini <stefano.stabellini@eu.citrix.com>" # Primary key fingerprint: D04E 33AB A51F 67BA 07D3 0AEA 894F 8F48 70E1 AE90 * sstabellini/tags/xen-20161122-tag: xen: attach pvusb usb bus to backend qdev xen: create qdev for each backend device qdev: add function qdev_set_id() xen: add an own bus for xen backend devices xen: fix ioreq handling Message-id: alpine.DEB.2.10.1611221037010.21858@sstabellini-ThinkPad-X260 Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
-
由 Stefan Hajnoczi 提交于
Block layer patches for 2.8.0-rc1 # gpg: Signature made Tue 22 Nov 2016 03:55:38 PM GMT # gpg: using RSA key 0x7F09B272C88F2FD6 # gpg: Good signature from "Kevin Wolf <kwolf@redhat.com>" # Primary key fingerprint: DC3D EB15 9A9A F95D 3D74 56FE 7F09 B272 C88F 2FD6 * kwolf/tags/for-upstream: block: Pass unaligned discard requests to drivers block: Return -ENOTSUP rather than assert on unaligned discards block: Let write zeroes fallback work even with small max_transfer qcow2: Inform block layer about discard boundaries Message-id: 1479830693-26676-1-git-send-email-kwolf@redhat.com Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
-
由 Stefan Hajnoczi 提交于
seabios: update to 1.10.1 stable release # gpg: Signature made Tue 22 Nov 2016 09:12:39 AM GMT # gpg: using RSA key 0x4CB6D8EED3E87138 # gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>" # gpg: aka "Gerd Hoffmann <gerd@kraxel.org>" # gpg: aka "Gerd Hoffmann (private) <kraxel@gmail.com>" # Primary key fingerprint: A032 8CFF B93A 17A7 9901 FE7D 4CB6 D8EE D3E8 7138 * kraxel/tags/pull-seabios-20161122-1: seabios: update to 1.10.1 stable release Message-id: 1479806144-25599-1-git-send-email-kraxel@redhat.com Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
-
由 Juergen Gross 提交于
Attach the usb bus of a new pvusb controller to the qdev associated with the Xen backend. Any device connected to that controller can now specify the bus and port directly via its properties. 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 提交于
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>
-
由 Jan Beulich 提交于
Avoid double fetches and bounds check size to avoid overflowing internal variables. This is CVE-2016-9381 / XSA-197. Reported-by: Nyanghongke <yanghongke@huawei.com> Signed-off-by: NJan Beulich <jbeulich@suse.com> Reviewed-by: NStefano Stabellini <sstabellini@kernel.org> Signed-off-by: NStefano Stabellini <sstabellini@kernel.org>
-
- 22 11月, 2016 8 次提交
-
-
由 Eric Blake 提交于
Discard is advisory, so rounding the requests to alignment boundaries is never semantically wrong from the data that the guest sees. But at least the Dell Equallogic iSCSI SANs has an interesting property that its advertised discard alignment is 15M, yet documents that discarding a sequence of 1M slices will eventually result in the 15M page being marked as discarded, and it is possible to observe which pages have been discarded. Between commits 9f1963b3 and b8d0a980, we converted the block layer to a byte-based interface that ultimately ignores any unaligned head or tail based on the driver's advertised discard granularity, which means that qemu 2.7 refuses to pass any discard request smaller than 15M down to the Dell Equallogic hardware. This is a slight regression in behavior compared to earlier qemu, where a guest executing discards in power-of-2 chunks used to be able to get every page discarded, but is now left with various pages still allocated because the guest requests did not align with the hardware's 15M pages. Since the SCSI specification says nothing about a minimum discard granularity, and only documents the preferred alignment, it is best if the block layer gives the driver every bit of information about discard requests, rather than rounding it to alignment boundaries early. Rework the block layer discard algorithm to mirror the write zero algorithm: always peel off any unaligned head or tail and manage that in isolation, then do the bulk of the request on an aligned boundary. The fallback when the driver returns -ENOTSUP for an unaligned request is to silently ignore that portion of the discard request; but for devices that can pass the partial request all the way down to hardware, this can result in the hardware coalescing requests and discarding aligned pages after all. Reported by: Peter Lieven <pl@kamp.de> CC: qemu-stable@nongnu.org Signed-off-by: NEric Blake <eblake@redhat.com> Reviewed-by: NMax Reitz <mreitz@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Eric Blake 提交于
Right now, the block layer rounds discard requests, so that individual drivers are able to assert that discard requests will never be unaligned. But there are some ISCSI devices that track and coalesce multiple unaligned requests, turning it into an actual discard if the requests eventually cover an entire page, which implies that it is better to always pass discard requests as low down the stack as possible. In isolation, this patch has no semantic effect, since the block layer currently never passes an unaligned request through. But the block layer already has code that silently ignores drivers that return -ENOTSUP for a discard request that cannot be honored (as well as drivers that return 0 even when nothing was done). But the next patch will update the block layer to fragment discard requests, so that clients are guaranteed that they are either dealing with an unaligned head or tail, or an aligned core, making it similar to the block layer semantics of write zero fragmentation. CC: qemu-stable@nongnu.org Signed-off-by: NEric Blake <eblake@redhat.com> Reviewed-by: NMax Reitz <mreitz@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Eric Blake 提交于
Commit 443668ca rewrote the write_zeroes logic to guarantee that an unaligned request never crosses a cluster boundary. But in the rewrite, the new code assumed that at most one iteration would be needed to get to an alignment boundary. However, it is easy to trigger an assertion failure: the Linux kernel limits loopback devices to advertise a max_transfer of only 64k. Any operation that requires falling back to writes rather than more efficient zeroing must obey max_transfer during that fallback, which means an unaligned head may require multiple iterations of the write fallbacks before reaching the aligned boundaries, when layering a format with clusters larger than 64k atop the protocol of file access to a loopback device. Test case: $ qemu-img create -f qcow2 -o cluster_size=1M file 10M $ losetup /dev/loop2 /path/to/file $ qemu-io -f qcow2 /dev/loop2 qemu-io> w 7m 1k qemu-io> w -z 8003584 2093056 In fairness to Denis (as the original listed author of the culprit commit), the faulty logic for at most one iteration is probably all my fault in reworking his idea. But the solution is to restore what was in place prior to that commit: when dealing with an unaligned head or tail, iterate as many times as necessary while fragmenting the operation at max_transfer boundaries. Reported-by: NEd Swierk <eswierk@skyportsystems.com> CC: qemu-stable@nongnu.org CC: Denis V. Lunev <den@openvz.org> Signed-off-by: NEric Blake <eblake@redhat.com> Reviewed-by: NMax Reitz <mreitz@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Eric Blake 提交于
At the qcow2 layer, discard is only possible on a per-cluster basis; at the moment, qcow2 silently rounds any unaligned requests to this granularity. However, an upcoming patch will fix a regression in the block layer ignoring too much of an unaligned discard request, by changing the block layer to break up a discard request at alignment boundaries; for that to work, the block layer must know about our limits. However, we can't go one step further by changing qcow2_discard_clusters() to assert that requests are always aligned, since that helper function is reached on paths outside of the block layer. CC: qemu-stable@nongnu.org Signed-off-by: NEric Blake <eblake@redhat.com> Reviewed-by: NMax Reitz <mreitz@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Ed Maste 提交于
Include sys/user.h for declaration of 'struct kinfo_proc'. Add -lutil to qemu-ga link for kinfo_getproc. Signed-off-by: NEd Maste <emaste@freebsd.org> Message-id: 1479778365-11315-1-git-send-email-emaste@freebsd.org Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
-
由 Stefan Hajnoczi 提交于
# gpg: Signature made Mon 21 Nov 2016 10:12:43 PM GMT # gpg: using RSA key 0xBDBE7B27C0DE3057 # gpg: Good signature from "Jeffrey Cody <jcody@redhat.com>" # gpg: aka "Jeffrey Cody <jeff@codyprime.org>" # gpg: aka "Jeffrey Cody <codyprime@gmail.com>" # Primary key fingerprint: 9957 4B4D 3474 90E7 9D98 D624 BDBE 7B27 C0DE 3057 * jtc/tags/block-pull-request: gluster: Fix use after free in glfs_clear_preopened() Message-id: 1479766499-29972-1-git-send-email-jcody@redhat.com Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
-
由 Gerd Hoffmann 提交于
git shortlog rel-1.10.0..rel-1.10.1 =================================== Igor Mammedov (1): drop "etc/boot-cpus" fw_cfg file and reuse legacy QEMU_CFG_NB_CPUS Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Kevin Wolf 提交于
This fixes a use-after-free bug introduced in commit 6349c154. We need to use QLIST_FOREACH_SAFE() when freeing elements in the loop. Spotted by Coverity. Signed-off-by: NKevin Wolf <kwolf@redhat.com> Message-id: 1479378608-11962-1-git-send-email-kwolf@redhat.com Signed-off-by: NJeff Cody <jcody@redhat.com>
-
- 21 11月, 2016 2 次提交
-
-
由 Stefan Hajnoczi 提交于
Xen 2016/11/08 # gpg: Signature made Tue 08 Nov 2016 07:48:12 PM GMT # gpg: using RSA key 0x894F8F4870E1AE90 # gpg: Good signature from "Stefano Stabellini <sstabellini@kernel.org>" # gpg: aka "Stefano Stabellini <stefano.stabellini@eu.citrix.com>" # Primary key fingerprint: D04E 33AB A51F 67BA 07D3 0AEA 894F 8F48 70E1 AE90 * sstabellini/tags/xen-20161108-tag: xen: Fix xenpv machine initialisation Message-id: alpine.DEB.2.10.1611081150170.3491@sstabellini-ThinkPad-X260 Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
-
由 Stefan Hajnoczi 提交于
virtio, vhost, pc: fixes Most notably this fixes a regression with vhost introduced by the pull before last. Signed-off-by: NMichael S. Tsirkin <mst@redhat.com> # gpg: Signature made Fri 18 Nov 2016 03:51:55 PM GMT # gpg: using RSA key 0x281F0DB8D28D5469 # gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" # gpg: aka "Michael S. Tsirkin <mst@redhat.com>" # Primary key fingerprint: 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67 # Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA 8A0D 281F 0DB8 D28D 5469 * mst/tags/for_upstream: acpi: Use apic_id_limit when calculating legacy ACPI table size ipmi: fix qemu crash while migrating with ipmi ivshmem: Fix 64 bit memory bar configuration virtio: set ISR on dataplane notifications virtio: access ISR atomically virtio: introduce grab/release_ioeventfd to fix vhost virtio-crypto: fix virtio_queue_set_notification() race Message-id: 1479484366-7977-1-git-send-email-mst@redhat.com Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
-
- 18 11月, 2016 12 次提交
-
-
由 Eduardo Habkost 提交于
The code that calculates the legacy ACPI table size for migration compatibility uses max_cpus when calculating legacy_aml_len (the size of the DSDT and SSDT tables). However, the SSDT grows according to APIC ID limit, not max_cpus. The bug is not triggered very often because of the 4k alignment on the table size. But it can be triggered if you are unlucky enough to cross a 4k boundary. Change the legacy_aml_len calculation to use apic_id_limit, to calculate the right size. Signed-off-by: NEduardo Habkost <ehabkost@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 ZhuangYanying 提交于
Qemu crash in the source side while migrating, after starting ipmi service inside vm. ./x86_64-softmmu/qemu-system-x86_64 --enable-kvm -smp 4 -m 4096 \ -drive file=/work/suse/suse11_sp3_64_vt,format=raw,if=none,id=drive-virtio-disk0,cache=none \ -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0 \ -vnc :99 -monitor vc -device ipmi-bmc-sim,id=bmc0 -device isa-ipmi-kcs,bmc=bmc0,ioport=0xca2 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffec4268700 (LWP 7657)] __memcpy_ssse3_back () at ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:2757 (gdb) bt #0 __memcpy_ssse3_back () at ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:2757 #1 0x00005555559ef775 in memcpy (__len=3, __src=0xc1421c, __dest=<optimized out>) at /usr/include/bits/string3.h:51 #2 qemu_put_buffer (f=0x555557a97690, buf=0xc1421c <Address 0xc1421c out of bounds>, size=3) at migration/qemu-file.c:346 #3 0x00005555559eef66 in vmstate_save_state (f=f@entry=0x555557a97690, vmsd=0x555555f8a5a0 <vmstate_ISAIPMIKCSDevice>, opaque=0x555557231160, vmdesc=vmdesc@entry=0x55555798cc40) at migration/vmstate.c:333 #4 0x00005555557cfe45 in vmstate_save (f=f@entry=0x555557a97690, se=se@entry=0x555557231de0, vmdesc=vmdesc@entry=0x55555798cc40) at /mnt/sdb/zyy/qemu/migration/savevm.c:720 #5 0x00005555557d2be7 in qemu_savevm_state_complete_precopy (f=0x555557a97690, iterable_only=iterable_only@entry=false) at /mnt/sdb/zyy/qemu/migration/savevm.c:1128 #6 0x00005555559ea102 in migration_completion (start_time=<synthetic pointer>, old_vm_running=<synthetic pointer>, current_active_state=<optimized out>, s=0x5555560eaa80 <current_migration.44078>) at migration/migration.c:1707 #7 migration_thread (opaque=0x5555560eaa80 <current_migration.44078>) at migration/migration.c:1855 #8 0x00007ffff3900dc5 in start_thread (arg=0x7ffec4268700) at pthread_create.c:308 #9 0x00007fffefc6c71d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 Signed-off-by: NZhuang Yanying <ann.zhuangyanying@huawei.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Zhuang Yanying 提交于
Device ivshmem property use64=0 is designed to make the device expose a 32 bit shared memory BAR instead of 64 bit one. The default is a 64 bit BAR, except pc-1.2 and older retain a 32 bit BAR. A 32 bit BAR can support only up to 1 GiB of shared memory. This worked as designed until commit 5400c02b accidentally flipped its sense: since then, we misinterpret use64=0 as use64=1 and vice versa. Worse, the default got flipped as well. Devices ivshmem-plain and ivshmem-doorbell are not affected. Fix by restoring the test of IVShmemState member not_legacy_32bit that got messed up in commit 5400c02b. Also update its initialization for devices ivhsmem-plain and ivshmem-doorbell. Without that, they'd regress to 32 bit BARs. Cc: qemu-stable@nongnu.org Signed-off-by: NZhuang Yanying <ann.zhuangyanying@huawei.com> Reviewed-by: NGonglei <arei.gonglei@huawei.com> Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
-
由 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 提交于
This will be needed once dataplane will be able to set it outside the big QEMU lock. 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>
-
由 Stefan Hajnoczi 提交于
# gpg: Signature made Fri 18 Nov 2016 03:01:22 PM GMT # gpg: using RSA key 0x9CA4ABB381AB73C8 # gpg: Good signature from "Stefan Hajnoczi <stefanha@redhat.com>" # gpg: aka "Stefan Hajnoczi <stefanha@gmail.com>" # Primary key fingerprint: 8695 A8BF D3F9 7CDA AC35 775A 9CA4 ABB3 81AB 73C8 * public/tags/tracing-pull-request: trace: fix generated code build break Message-id: 1479481289-2479-1-git-send-email-stefanha@redhat.com Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
-
由 Stefan Hajnoczi 提交于
We must check for new virtqueue buffers after re-enabling notifications. This prevents the race condition where the guest added buffers just after we stopped popping the virtqueue but before we re-enabled notifications. I think the virtio-crypto code was based on virtio-net but this crucial detail was missed. virtio-net does not have the race condition because it processes the virtqueue one more time after re-enabling notifications. Cc: Gonglei <arei.gonglei@huawei.com> Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com> Tested-by: NAlexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com> Reviewed-by: NGonglei <arei.gonglei@huawei.com>
-
由 Stefan Hajnoczi 提交于
* remotes/elmarco/tags/ivshmem-pull-request: ivshmem: Fix 64 bit memory bar configuration Message-id: 20161117152613.18578-1-marcandre.lureau@redhat.com Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
-
由 Stefan Hajnoczi 提交于
Update alpha palcode for smp # gpg: Signature made Thu 17 Nov 2016 02:57:29 PM GMT # gpg: using RSA key 0xAD1270CC4DD0279B # gpg: Good signature from "Richard Henderson <rth7680@gmail.com>" # gpg: aka "Richard Henderson <rth@redhat.com>" # gpg: aka "Richard Henderson <rth@twiddle.net>" # Primary key fingerprint: 9CB1 8DDA F8E8 49AD 2AFC 16A4 AD12 70CC 4DD0 279B * rth/tags/pull-axp-20161117: target-alpha: Log cpuid with -d int target-alpha: Update palcode for smp Message-id: 1479394965-11254-1-git-send-email-rth@twiddle.net Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
-
由 Greg Kurz 提交于
If the QEMU source dir is /var/tmp/aaa-qemu-clone and the build dir is /var/tmp/qemu-aio-poll-v2 Then I get an error as: trace/generated-tracers.c:15950:13: error: invalid suffix "_trace_events" on integer constant TraceEvent *2_trace_events[] = { ^ trace/generated-tracers.c:15950:13: error: expected identifier or ‘(’ before numeric constant trace/generated-tracers.c: In function ‘trace_2_register_events’: trace/generated-tracers.c:17949:32: error: invalid suffix "_trace_events" on integer constant trace_event_register_group(2_trace_events); ^ make: *** [trace/generated-tracers.o] Error 1 This patch fixes the issue. Reported-by: NFam Zheng <famz@redhat.com> Signed-off-by: NGreg Kurz <groug@kaod.org> Tested-by: NFam Zheng <famz@redhat.com> Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
-
由 Stefan Hajnoczi 提交于
# gpg: Signature made Thu 17 Nov 2016 10:18:58 AM GMT # gpg: using RSA key 0xF30C38BD3F2FBE3C # gpg: Good signature from "Laurent Vivier <lvivier@redhat.com>" # gpg: aka "Laurent Vivier <laurent@vivier.eu>" # gpg: aka "Laurent Vivier (Red Hat) <lvivier@redhat.com>" # Primary key fingerprint: CD2F 75DD C8E3 A4DC 2E4F 5173 F30C 38BD 3F2F BE3C * vivier/tags/trivial-patches-pull-request: qapi-schema: clarify 'colo' state for MigrationStatus Message-id: 1479378016-19022-1-git-send-email-laurent@vivier.eu Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
-
- 17 11月, 2016 4 次提交
-
-
由 Richard Henderson 提交于
Signed-off-by: NRichard Henderson <rth@twiddle.net>
-
由 Richard Henderson 提交于
Signed-off-by: NRichard Henderson <rth@twiddle.net>
-
由 Zhuang Yanying 提交于
Device ivshmem property use64=0 is designed to make the device expose a 32 bit shared memory BAR instead of 64 bit one. The default is a 64 bit BAR, except pc-1.2 and older retain a 32 bit BAR. A 32 bit BAR can support only up to 1 GiB of shared memory. This worked as designed until commit 5400c02b accidentally flipped its sense: since then, we misinterpret use64=0 as use64=1 and vice versa. Worse, the default got flipped as well. Devices ivshmem-plain and ivshmem-doorbell are not affected. Fix by restoring the test of IVShmemState member not_legacy_32bit that got messed up in commit 5400c02b. Also update its initialization for devices ivhsmem-plain and ivshmem-doorbell. Without that, they'd regress to 32 bit BARs. Signed-off-by: NZhuang Yanying <ann.zhuangyanying@huawei.com> Reviewed-by: NGonglei <arei.gonglei@huawei.com> Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <1479385863-7648-1-git-send-email-ann.zhuangyanying@huawei.com>
-
由 zhanghailiang 提交于
VM can not get into colo state unless users enable 'x-colo' capability for migration, Here it is necessary to clarify this. Suggested-by: NEric Blake <eblake@redhat.com> Signed-off-by: Nzhanghailiang <zhang.zhanghailiang@huawei.com> Message-Id: <1478072652-9884-1-git-send-email-zhang.zhanghailiang@huawei.com> Reviewed-by: NEric Blake <eblake@redhat.com> Signed-off-by: NLaurent Vivier <laurent@vivier.eu>
-
- 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 提交于
PC will use this field in other way, so move it outside the common code so PC could set a different value, i.e. all CPUs regardless of where they are coming from (-smp X | -device cpu...). It's quick and dirty hack as it could be implemented in more generic way in MashineClass. But do it in simple way since only PC is affected so far. Later we can generalize it when another affected target gets support for -device cpu. Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Message-Id: <1479212236-183810-3-git-send-email-imammedo@redhat.com> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-