Re: [Qemu-devel] [PATCH RFC V2 6/6] xen: introduce xenpv-softmmu.mak
On Fri, Jul 04, 2014 at 04:10:13PM +0100, Stefano Stabellini wrote: I realize now that patch #5 and #6 of this series feel through the cracks. Could you please rebase and resend? Hi Peter and Paolo I would like to ask for your suggestion on how to move this forward. The first few refactoring patches have been upstreamed. These two patches (and a dependency patch which is not included here) seem to be the last missing bits to have QEMU binary for Xen on ARM. We would really like to find a way to upstream these changes and avoid forking. Wei.
Re: [Qemu-devel] [PATCH V2 2/6] runner: Tool for fuzz tests execution
On Fri, 07/04 15:39, Maria Kustova wrote: v1 - v2: Added parameter for a fuzzer configuration file In the future revisions, please put such revision change notes below a '---' line, like: commit log Signed-off-by: Your Name y...@email.com --- v1 - v2: change This way, it doesn't get into git log when maintainers apply your patch email with git am. The reason is that revision notes only matter when reviewing patches, but has no value once applied to master. Thanks, Fam
Re: [Qemu-devel] [PATCH for-2.1?] scripts: qapi-event.py: support vendor extension
On Wed, 09 Jul 2014 09:43:53 -0600 Eric Blake ebl...@redhat.com wrote: On 07/08/2014 12:17 PM, Luiz Capitulino wrote: The event code generator barfs when it sees a dot in an event argument, this makes it impossible to support vendor extensions in event arguments as they always contain dots. Fix this by replacing dots by hyphens in the generated code. PS: Event names and QMP command arguments may suffer from the same issue, but I'm not checking/fixing them today. Signed-off-by: Luiz Capitulino lcapitul...@redhat.com --- scripts/qapi-event.py | 8 scripts/qapi.py | 4 2 files changed, 8 insertions(+), 4 deletions(-) Reviewed-by: Eric Blake ebl...@redhat.com This is borderline on whether it is a bug fix worth applying in 2.1 - it is fixing something that is new to this release (event-as-qapi) and which affects downstream vendors; but at the same time, it is something which cannot be triggered _except_ by downstream vendors, which are perfectly capable of applying this patch even if it misses 2.1. I'll leave it up to you. I'm not sure it qualifies. On the one hand it's a bug in new code that didn't exist before, on the other hand this is by far not blocker and it doesn't cause any code to malfunction.
Re: [Qemu-devel] [PATCH V2 6/6] image-fuzzer: GPLv2 license file
On Fri, 07/04 15:39, Maria Kustova wrote: Signed-off-by: Maria Kustova mari...@catit.be You have the copyright headers in each file, so it's not really necessary to put the license here. No need to respin for this, if it's unwanted in the end, maintainer could probably skip when merging the series. Fam
[Qemu-devel] [RFC 01/25] vl.c: Small coding style fix
Just to make checkpatch.pl happy when moving the code.
Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
vl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/vl.c b/vl.c
index 6e084c2..8da895f 100644
--- a/vl.c
+++ b/vl.c
@@ -2692,7 +2692,7 @@ static int configure_accelerator(MachineClass *mc)
if (*p == ':') {
p++;
}
-p = get_opt_name(buf, sizeof (buf), p, ':');
+p = get_opt_name(buf, sizeof(buf), p, ':');
for (i = 0; i ARRAY_SIZE(accel_list); i++) {
if (strcmp(accel_list[i].opt_name, buf) == 0) {
if (!accel_list[i].available()) {
--
1.9.3
Re: [Qemu-devel] dataplane degradation in 2.1
On Wed, 07/09 20:50, Andrey Korolyov wrote: Hello, I`ve observed an immediate crash running tagged -rc1 with virtio-blk(675879f6f3c9463e103735a4e41e9deb0bee9b39). Please take a look on attached backtrace, hope that the fix still can made its way to 2.1. 1.6 works well with same config, so it`s clearly a regression. This one should fix it: http://lists.nongnu.org/archive/html/qemu-devel/2014-07/msg01531.html Fam /usr/bin/qemu-system-x86_64 -name Windows2008R2 -S -machine pc-i440fx-2.1,accel=kvm,usb=off -m 4096 -realtime mlock=off -smp 2,sockets=1,cores=2,threads=2 -numa node,nodeid=0,cpus=0,mem=4096 -uuid 16e64e7e-2582-3236-c93b-ab37828325ea -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/Windows2008R2.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -drive file=/dev/virtmachines/win2008r2,if=none,id=drive-virtio-disk0,format=raw,cache=none,aio=native -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/win2008r2.sock,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.1 -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -cpu qemu64,hv_relaxed -set device.virtio-disk0.config-wce=off -set device.virtio-disk0.scsi=off -set device.virtio-disk0.x-data-plane=on -msg timestamp=on Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f79a8bfe700 (LWP 11306)] 0x7f79badf323f in virtio_blk_rw_complete (opaque=0x7f79bb9606a0, ret=0) at /var/tmp/portage/app-emulation/qemu-2.1.0/work/qemu-2.1.0/hw/block/virtio-blk.c:99 99 bdrv_acct_done(req-dev-bs, req-acct); (gdb) thread apply all bt Thread 5 (Thread 0x7f79aa753700 (LWP 11302)): #0 0x7f79b4a87727 in ioctl () from /lib64/libc.so.6 #1 0x7f79bade24d9 in kvm_vcpu_ioctl (cpu=cpu@entry=0x7f79bba17eb0, type=type@entry=44672) at /var/tmp/portage/app-emulation/qemu-2.1.0/work/qemu-2.1.0/kvm-all.c:1845 #2 0x7f79bade2615 in kvm_cpu_exec (cpu=cpu@entry=0x7f79bba17eb0) at /var/tmp/portage/app-emulation/qemu-2.1.0/work/qemu-2.1.0/kvm-all.c:1714 #3 0x7f79badcdd2c in qemu_kvm_cpu_thread_fn (arg=0x7f79bba17eb0) at /var/tmp/portage/app-emulation/qemu-2.1.0/work/qemu-2.1.0/cpus.c:874 #4 0x7f79b7589f3a in start_thread () from /lib64/libpthread.so.0 #5 0x7f79b4a8fc3d in clone () from /lib64/libc.so.6 Thread 4 (Thread 0x7f79a9f52700 (LWP 11303)): #0 0x7f79b4a87727 in ioctl () from /lib64/libc.so.6 #1 0x7f79bade24d9 in kvm_vcpu_ioctl (cpu=cpu@entry=0x7f79bba53760, type=type@entry=44672) at /var/tmp/portage/app-emulation/qemu-2.1.0/work/qemu-2.1.0/kvm-all.c:1845 #2 0x7f79bade2615 in kvm_cpu_exec (cpu=cpu@entry=0x7f79bba53760) at /var/tmp/portage/app-emulation/qemu-2.1.0/work/qemu-2.1.0/kvm-all.c:1714 #3 0x7f79badcdd2c in qemu_kvm_cpu_thread_fn (arg=0x7f79bba53760) at /var/tmp/portage/app-emulation/qemu-2.1.0/work/qemu-2.1.0/cpus.c:874 #4 0x7f79b7589f3a in start_thread () from /lib64/libpthread.so.0 #5 0x7f79b4a8fc3d in clone () from /lib64/libc.so.6 Thread 3 (Thread 0x7f79a8bfe700 (LWP 11306)): #0 0x7f79badf323f in virtio_blk_rw_complete (opaque=0x7f79bb9606a0, ret=0) at /var/tmp/portage/app-emulation/qemu-2.1.0/work/qemu-2.1.0/hw/block/virtio-blk.c:99 #1 0x7f79bb029a62 in bdrv_co_em_bh (opaque=0x7f789400dc30) at /var/tmp/portage/app-emulation/qemu-2.1.0/work/qemu-2.1.0/block.c:4666 #2 0x7f79bb021597 in aio_bh_poll (ctx=ctx@entry=0x7f79bba37e90) at /var/tmp/portage/app-emulation/qemu-2.1.0/work/qemu-2.1.0/async.c:81 #3 0x7f79bb032d05 in aio_poll (ctx=0x7f79bba37e90, blocking=blocking@entry=true) at /var/tmp/portage/app-emulation/qemu-2.1.0/work/qemu-2.1.0/aio-posix.c:188 #4 0x7f79baea67b7 in iothread_run (opaque=0x7f79bbc18728) at /var/tmp/portage/app-emulation/qemu-2.1.0/work/qemu-2.1.0/iothread.c:41 #5 0x7f79b7589f3a in start_thread () from /lib64/libpthread.so.0 #6 0x7f79b4a8fc3d in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x7f789b7ff700 (LWP 11307)): #0 0x7f79b758dd0c in pthread_cond_wait () from /lib64/libpthread.so.0 #1 0x7f79bb07fcb9 in qemu_cond_wait (cond=cond@entry=0x7f79bbc17e20, mutex=mutex@entry=0x7f79bbc17e50) at /var/tmp/portage/app-emulation/qemu-2.1.0/work/qemu-2.1.0/util/qemu-thread-posix.c:135 #2 0x7f79bb01c95b in vnc_worker_thread_loop (queue=queue@entry=0x7f79bbc17e20) at /var/tmp/portage/app-emulation/qemu-2.1.0/work/qemu-2.1.0/ui/vnc-jobs.c:222 #3 0x7f79bb01cd30 in
[Qemu-devel] [PATCH 065/156] pci-assign: limit # of msix vectors
From: Michael S. Tsirkin m...@redhat.com
KVM only supports MSIX table size up to 256 vectors,
but some assigned devices support more vectors,
at the moment attempts to assign them fail with EINVAL.
Tweak the MSIX capability exposed to guest to limit table size
to a supported value.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Tested-by: Gonglei arei.gong...@huawei.com
Cc: qemu-sta...@nongnu.org
Acked-by: Alex Williamson alex.william...@redhat.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
(cherry picked from commit 639973a4740f38789057744b550df3a175bc49ad)
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
hw/i386/kvm/pci-assign.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/hw/i386/kvm/pci-assign.c b/hw/i386/kvm/pci-assign.c
index 9686801..db70d6e 100644
--- a/hw/i386/kvm/pci-assign.c
+++ b/hw/i386/kvm/pci-assign.c
@@ -1257,6 +1257,7 @@ static int assigned_device_pci_cap_init(PCIDevice
*pci_dev)
if (pos != 0 kvm_device_msix_supported(kvm_state)) {
int bar_nr;
uint32_t msix_table_entry;
+uint16_t msix_max;
if (!check_irqchip_in_kernel()) {
return -ENOTSUP;
@@ -1268,9 +1269,10 @@ static int assigned_device_pci_cap_init(PCIDevice
*pci_dev)
}
pci_dev-msix_cap = pos;
-pci_set_word(pci_dev-config + pos + PCI_MSIX_FLAGS,
- pci_get_word(pci_dev-config + pos + PCI_MSIX_FLAGS)
- PCI_MSIX_FLAGS_QSIZE);
+msix_max = (pci_get_word(pci_dev-config + pos + PCI_MSIX_FLAGS)
+PCI_MSIX_FLAGS_QSIZE) + 1;
+msix_max = MIN(msix_max, KVM_MAX_MSIX_PER_DEV);
+pci_set_word(pci_dev-config + pos + PCI_MSIX_FLAGS, msix_max - 1);
/* Only enable and function mask bits are writable */
pci_set_word(pci_dev-wmask + pos + PCI_MSIX_FLAGS,
@@ -1280,9 +1282,7 @@ static int assigned_device_pci_cap_init(PCIDevice
*pci_dev)
bar_nr = msix_table_entry PCI_MSIX_FLAGS_BIRMASK;
msix_table_entry = ~PCI_MSIX_FLAGS_BIRMASK;
dev-msix_table_addr = pci_region[bar_nr].base_addr + msix_table_entry;
-dev-msix_max = pci_get_word(pci_dev-config + pos + PCI_MSIX_FLAGS);
-dev-msix_max = PCI_MSIX_FLAGS_QSIZE;
-dev-msix_max += 1;
+dev-msix_max = msix_max;
}
/* Minimal PM support, nothing writable, device appears to NAK changes */
--
1.9.1
Re: [Qemu-devel] [PATCH V2 4/6] layout: Generator of fuzzed qcow2 images
On Fri, 07/04 15:39, Maria Kustova wrote:
Layout submodule of qcow2 package creates a random valid image, randomly
selects some amount of its fields, fuzzes them and write the fuzzed image to
the file.
Now only header and header extensions are generated, a remaining file is
filled
by zeroes.
v1 - v2:
* Added support of fuzzer configurations.
* Created general Image class:
** fixed mixed defs/classes module style
** internalized all functions related to image generation
** simplified internal image representation
Signed-off-by: Maria Kustova mari...@catit.be
---
tests/image-fuzzer/qcow2/layout.py | 319
+
1 file changed, 319 insertions(+)
create mode 100644 tests/image-fuzzer/qcow2/layout.py
diff --git a/tests/image-fuzzer/qcow2/layout.py
b/tests/image-fuzzer/qcow2/layout.py
new file mode 100644
index 000..d6fc1ab
--- /dev/null
+++ b/tests/image-fuzzer/qcow2/layout.py
@@ -0,0 +1,319 @@
+# Generator of fuzzed qcow2 images
+#
+# Copyright (C) 2014 Maria Kustova mari...@catit.be
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see http://www.gnu.org/licenses/.
+#
+
+import random
+import struct
+import qcow2.fuzz
+
+MAX_IMAGE_SIZE = 10*2**20
+# Standard sizes
+UINT32_S = 4
+UINT64_S = 8
+
+# Percentage of fields will be fuzzed
+BIAS = random.uniform(0.2, 0.5)
+
+
+class Field(object):
+Atomic image element (field)
+
+The class represents an image field as quadruple of a data format
+of value necessary for its packing to binary form, an offset from
+the beginning of the image, a value and a name.
+
+The field can be iterated as a list [format, offset, value]
+
+__slots__ = ('fmt', 'offset', 'value', 'name')
+
+def __init__(self, fmt, offset, val, name):
+self.fmt = fmt
+self.offset = offset
+self.value = val
+self.name = name
+
+def __iter__(self):
+return (x for x in [self.fmt, self.offset, self.value])
+
+def __repr__(self):
+return Field(fmt='%s', offset=%d, value=%s, name=%s) % \
+(self.fmt, self.offset, str(self.value), self.name)
+
+
+class FieldsList(object):
+List of fields
+
+The class allows access to a field in the list by its name and joins
+several list in one via in-place addition
+
+def __init__(self, meta_data=None):
+if meta_data is None:
+self.data = []
+else:
+self.data = [Field(f[0], f[1], f[2], f[3])
+ for f in meta_data]
+
+def __getitem__(self, name):
+return [x for x in self.data if x.name == name]
+
+def __iter__(self):
+return (x for x in self.data)
+
+def __iadd__(self, other):
+self.data += other.data
+return self
+
+def __len__(self):
+return len(self.data)
+
+
+class Image(object):
+ Qcow2 image object
+
+This class allows to create valid qcow2 images with random structure,
+fuzz them via external qcow2.fuzz module and write to files.
+
+@staticmethod
+def _size_params():
+Generate a random file size aligned to a random correct cluster
size
+
+cluster_bits = random.randrange(9, 21)
+cluster_size = 1 cluster_bits
+# Minimal image size is equal to 5 clusters as for qcow2 empty image
+# created by qemu-img
+file_size = random.randrange(5*cluster_size, MAX_IMAGE_SIZE + 1,
+ cluster_size)
+return [cluster_bits, file_size]
+
+@staticmethod
+def _header(cluster_bits, img_size):
+Generate a random valid header
+meta_header = [
+['4s', 0, QFI\xfb, 'magic'],
+['I', 4, random.randint(2, 3), 'version'],
+['Q', 8, 0, 'backing_file_offset'],
+['I', 16, 0, 'backing_file_size'],
+['I', 20, cluster_bits, 'cluster_bits'],
+['Q', 24, img_size, 'size'],
+['I', 32, 0, 'crypt_method'],
+['I', 36, 0, 'l1_size'],
+['Q', 40, 0, 'l1_table_offset'],
+['Q', 48, 0, 'refcount_table_offset'],
+['I', 56, 0, 'refcount_table_clusters'],
+['I', 60, 0, 'nb_snapshots'],
+['Q', 64, 0, 'snapshots_offset'],
+['Q', 72, 0,
[Qemu-devel] [PATCH v3 2.1 1/4] virtio-blk: Factor common checks out of virtio_blk_handle_read/write()
Signed-off-by: Markus Armbruster arm...@redhat.com
Reviewed-by: Fam Zheng f...@redhat.com
---
hw/block/virtio-blk.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
index aec3146..d946fa9 100644
--- a/hw/block/virtio-blk.c
+++ b/hw/block/virtio-blk.c
@@ -288,6 +288,18 @@ static void virtio_blk_handle_flush(VirtIOBlockReq *req,
MultiReqBuffer *mrb)
bdrv_aio_flush(req-dev-bs, virtio_blk_flush_complete, req);
}
+static bool virtio_blk_sect_range_ok(VirtIOBlock *dev,
+ uint64_t sector, size_t size)
+{
+if (sector dev-sector_mask) {
+return false;
+}
+if (size % dev-conf-logical_block_size) {
+return false;
+}
+return true;
+}
+
static void virtio_blk_handle_write(VirtIOBlockReq *req, MultiReqBuffer *mrb)
{
BlockRequest *blkreq;
@@ -299,11 +311,7 @@ static void virtio_blk_handle_write(VirtIOBlockReq *req,
MultiReqBuffer *mrb)
trace_virtio_blk_handle_write(req, sector, req-qiov.size / 512);
-if (sector req-dev-sector_mask) {
-virtio_blk_rw_complete(req, -EIO);
-return;
-}
-if (req-qiov.size % req-dev-conf-logical_block_size) {
+if (!virtio_blk_sect_range_ok(req-dev, sector, req-qiov.size)) {
virtio_blk_rw_complete(req, -EIO);
return;
}
@@ -333,11 +341,7 @@ static void virtio_blk_handle_read(VirtIOBlockReq *req)
trace_virtio_blk_handle_read(req, sector, req-qiov.size / 512);
-if (sector req-dev-sector_mask) {
-virtio_blk_rw_complete(req, -EIO);
-return;
-}
-if (req-qiov.size % req-dev-conf-logical_block_size) {
+if (!virtio_blk_sect_range_ok(req-dev, sector, req-qiov.size)) {
virtio_blk_rw_complete(req, -EIO);
return;
}
--
1.9.3
[Qemu-devel] [PATCH 103/156] dmg: prevent out-of-bounds array access on terminator
From: Stefan Hajnoczi stefa...@redhat.com
When a terminator is reached the base for offsets and sectors is stored.
The following records that are processed will use this base value.
If the first record we encounter is a terminator, then calculating the
base values would result in out-of-bounds array accesses. Don't do
that.
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
Reviewed-by: Max Reitz mre...@redhat.com
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
(cherry picked from commit 73ed27ec28a1dbebdd2ae792284151f029950fbe)
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
block/dmg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/dmg.c b/block/dmg.c
index be2f26e..f4f3e8e 100644
--- a/block/dmg.c
+++ b/block/dmg.c
@@ -182,7 +182,7 @@ static int dmg_open(BlockDriverState *bs, QDict *options,
int flags,
offset += 4;
if (s-types[i] != 0x8005 s-types[i] != 1
s-types[i] != 2) {
-if (s-types[i] == 0x) {
+if (s-types[i] == 0x i 0) {
last_in_offset = s-offsets[i - 1] + s-lengths[i - 1];
last_out_offset = s-sectors[i - 1] +
s-sectorcounts[i - 1];
--
1.9.1
Re: [Qemu-devel] [Bug 1324112] Re: qemu parallel building error on libcacard.la
On Thu, Jul 10, 2014 at 7:28 AM, Fam Zheng f...@redhat.com wrote: Could be because of this rule: # libtool will build the .o files, too $(libcacard-obj-y): | $(libcacard-lobj-y) Does removing the | (order deps) solve the issue? I don't think so: libcacard.la: $(libcacard-lobj-y) $(call LINK,$^) The problem is the libcacard-obj-y target is not required by anything. Try this on qemu.git/master: $ make distclean $ ./configure $ make libcacard/vscclient libcacard/vscclient.o: In function `do_command': /home/stefanha/qemu/libcacard/vscclient.c:500: undefined reference to `vreader_get_reader_by_id' /home/stefanha/qemu/libcacard/vscclient.c:502: undefined reference to `vcard_emul_force_card_insert' /home/stefanha/qemu/libcacard/vscclient.c:503: undefined reference to `vreader_get_name' ... The Makefile is broken. I suspect that putting proper dependencies in place with fix this issue. Stefan
[Qemu-devel] [PATCH 020/156] megasas: Implement LD_LIST_QUERY
From: Hannes Reinecke h...@suse.de
Newer firmware implement a LD_LIST_QUERY command, and due to a driver
issue no drives might be detected if this command isn't supported.
So add emulation for this command, too.
Cc: qemu-sta...@nongnu.org
Signed-off-by: Hannes Reinecke h...@suse.de
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
(cherry picked from commit 34bb4d02e00e508fa9d111a6a31b45bbfecbdba5)
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
hw/scsi/megasas.c | 17 +
hw/scsi/mfi.h | 9 +
trace-events | 1 +
3 files changed, 27 insertions(+)
diff --git a/hw/scsi/megasas.c b/hw/scsi/megasas.c
index 7c5a1a2..dc09de3 100644
--- a/hw/scsi/megasas.c
+++ b/hw/scsi/megasas.c
@@ -1101,6 +1101,21 @@ static int megasas_dcmd_ld_get_list(MegasasState *s,
MegasasCmd *cmd)
return MFI_STAT_OK;
}
+static int megasas_dcmd_ld_list_query(MegasasState *s, MegasasCmd *cmd)
+{
+uint16_t flags;
+
+/* mbox0 contains flags */
+flags = le16_to_cpu(cmd-frame-dcmd.mbox[0]);
+trace_megasas_dcmd_ld_list_query(cmd-index, flags);
+if (flags == MR_LD_QUERY_TYPE_ALL ||
+flags == MR_LD_QUERY_TYPE_EXPOSED_TO_HOST) {
+return megasas_dcmd_ld_get_list(s, cmd);
+}
+
+return MFI_STAT_OK;
+}
+
static int megasas_ld_get_info_submit(SCSIDevice *sdev, int lun,
MegasasCmd *cmd)
{
@@ -1404,6 +1419,8 @@ static const struct dcmd_cmd_tbl_t {
megasas_dcmd_dummy },
{ MFI_DCMD_LD_GET_LIST, LD_GET_LIST,
megasas_dcmd_ld_get_list},
+{ MFI_DCMD_LD_LIST_QUERY, LD_LIST_QUERY,
+ megasas_dcmd_ld_list_query },
{ MFI_DCMD_LD_GET_INFO, LD_GET_INFO,
megasas_dcmd_ld_get_info },
{ MFI_DCMD_LD_GET_PROP, LD_GET_PROP,
diff --git a/hw/scsi/mfi.h b/hw/scsi/mfi.h
index cd8355b..a3034f6 100644
--- a/hw/scsi/mfi.h
+++ b/hw/scsi/mfi.h
@@ -164,6 +164,7 @@ typedef enum {
MFI_DCMD_PD_BLINK = 0x02070100,
MFI_DCMD_PD_UNBLINK = 0x02070200,
MFI_DCMD_LD_GET_LIST = 0x0301,
+MFI_DCMD_LD_LIST_QUERY =0x03010100,
MFI_DCMD_LD_GET_INFO = 0x0302,
MFI_DCMD_LD_GET_PROP = 0x0303,
MFI_DCMD_LD_SET_PROP = 0x0304,
@@ -411,6 +412,14 @@ typedef enum {
MR_PD_QUERY_TYPE_EXPOSED_TO_HOST = 5, /*query for system drives */
} mfi_pd_query_type;
+typedef enum {
+MR_LD_QUERY_TYPE_ALL = 0,
+MR_LD_QUERY_TYPE_EXPOSED_TO_HOST = 1,
+MR_LD_QUERY_TYPE_USED_TGT_IDS = 2,
+MR_LD_QUERY_TYPE_CLUSTER_ACCESS = 3,
+MR_LD_QUERY_TYPE_CLUSTER_LOCALE = 4,
+} mfi_ld_query_type;
+
/*
* Other propertities and definitions
*/
diff --git a/trace-events b/trace-events
index b8887c1..87fe42e 100644
--- a/trace-events
+++ b/trace-events
@@ -670,6 +670,7 @@ megasas_dcmd_ld_get_list(int cmd, int num, int max) scmd
%d: DCMD LD get list:
megasas_dcmd_ld_get_info(int cmd, int ld_id) scmd %d: DCMD LD get info for
dev %d
megasas_dcmd_pd_get_info(int cmd, int pd_id) scmd %d: DCMD PD get info for
dev %d
megasas_dcmd_pd_list_query(int cmd, int flags) scmd %d: DCMD PD list query
flags %x
+megasas_dcmd_ld_list_query(int cmd, int flags) scmd %d: DCMD LD list query
flags %x
megasas_dcmd_unsupported(int cmd, unsigned long size) scmd %d: set properties
len %ld
megasas_abort_frame(int cmd, int abort_cmd) scmd %d: aborting frame %x
megasas_abort_no_cmd(int cmd, uint64_t context) scmd %d: no active command
for frame context % PRIx64
--
1.9.1
Re: [Qemu-devel] [Bug 1324112] Re: qemu parallel building error on libcacard.la
On Thu, Jul 10, 2014 at 9:32 AM, Stefan Hajnoczi stefa...@gmail.com wrote: Try this on qemu.git/master: $ make distclean $ ./configure $ make libcacard/vscclient libcacard/vscclient.o: In function `do_command': /home/stefanha/qemu/libcacard/vscclient.c:500: undefined reference to `vreader_get_reader_by_id' /home/stefanha/qemu/libcacard/vscclient.c:502: undefined reference to `vcard_emul_force_card_insert' /home/stefanha/qemu/libcacard/vscclient.c:503: undefined reference to `vreader_get_name' ... The Makefile is broken. I suspect that putting proper dependencies in place with fix this issue. Please ignore, the libcacard Makefile is actually supposed to be invoked as make vscclient from the QEMU root directory. These errors were just caused by a %.o: %.c default make target. Stefan
Re: [Qemu-devel] [Bug 1324112] Re: qemu parallel building error on libcacard.la
Since the following commit, libcacard and vscclient no longer link against QEMU common code: commit fd25c0e6dd1ed2aa932fa7ef814b32457bf270fd Author: Michael Tokarev m...@tls.msk.ru Date: Thu May 8 12:30:48 2014 +0400 libcacard: replace qemu thread primitives with glib ones Therefore this bug no longer exists in qemu.git/master and can be closed. Stefan ** Changed in: qemu Status: New = Fix Committed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1324112 Title: qemu parallel building error on libcacard.la Status in QEMU: Fix Committed Bug description: hi, im building qemu with a large make -j value(9). sometimes the build fails because of an error: libtool: link: ar cru .libs/libcacard.a stubs/arch-query-cpu-def.o stubs/clock-warp.o stubs/cpu-get-clock.o stubs/cpu-get-icount.o stubs/dump.o stubs/fdset-add-fd.o stubs/fdset-find-fd.o stubs/fdset-get-fd.o stubs/fdset-remove-fd.o stubs/gdbstub.o stubs/get-fd.o stubs/get-vm-name.o stubs/iothread-lock.o stubs/migr-blocker.o stubs/mon-is-qmp.o stubs/mon-printf.o stubs/mon-print-filename.o stubs/mon-protocol-event.o stubs/mon-set-error.o stubs/pci-drive-hot-add.o stubs/qtest.o stubs/reset.o stubs/runstate-check.o stubs/set-fd-handler.o stubs/slirp.o stubs/sysbus.o stubs/uuid.o stubs/vm-stop.o stubs/vmstate.o stubs/cpus.o stubs/kvm.o libcacard/cac.o libcacard/event.o libcacard/vcard.o libcacard/vreader.o libcacard/vcard_emul_nss.o libcacard/vcard_emul_type.o libcacard/card_7816.o libcacard/vcardt.o util/osdep.o util/cutils.o util/qemu-timer-common.o util/error.o util/qemu-error.o util/oslib-posix.o util/qemu-thread-posix.o trace/generated-events.o trace/default.o trace/control.o trace/generated-tracers.o ar: trace/generated-events.o: No such file or directory make[2]: *** [libcacard.la] Error 1 i see the build of generated-events.o in the log before the ar command. because of the -j it was probably not completed yet. the generated-events.o build command: /usr/bin/gcc -I/home/npsdb/qemu/qemu/tcg -I/home/npsdb/qemu/qemu/tcg/i386 -I/home/npsdb/qemu/qemu/linux-headers -I/home/npsdb/qemu/build/linux_x86_64/linux-headers -I. -I/home/npsdb/qemu/qemu -I/home/npsdb/jenkins/qemu/qemu/include -I/home/npsdb/qemu/qemu/libcacard -Itrace -Itrace -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/libpng12 -I/usr/include/nss3 -I/usr/include/nspr4 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/home/npsdb/qemu/qemu/tests -I qga/qapi-generated -MMD -MP -MT trace/generated-events.o -MF trace/generated-events.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -g -c -o trace/generated-events.o trace/generated-events.c must be a race condition in the makefile because of a missing dependency. i tried to find it but it was a little bit complicated to me. thanks, tal To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1324112/+subscriptions
Re: [Qemu-devel] [PATCH for 2.1 0/2] Fix commit of oversized layer
On Fri, 06/27 11:44, Kevin Wolf wrote: In general, it feels like it would be the right thing to do, especially considering the goal of operation categories in the final state, but on the other hand it means that RESIZE would have to be excluded from bs-backing_blocker, too, allowing standalone resize commands on backing files. Not sure that this would be a good idea... Is it really dangerous if we relax the backing_blocker on resize? In general, I expect the only critical category of operation is chain manipulation, particularly bdrv_swap. And speaking of bdrv_swap, in longer term, if we have the BlockBackend that can serve as a level of abstraction between BlockDriverState (the backend implementation) and its users (the backend consumers, like device), we can probably drop bdrv_swap() by updating the BB-BDS link. To illustrate: [top] --- device emulation ||-- NBD server |`-- commit block job [mid] | [bot] When we commit top to mid, bdrv_swap will move the data into original top's position, so the old users of top now automatically start to use mid (of course, it is assigned some properties of top, like device name). [mid] --- device emulation ||-- NBD server |`-- commit block job (done) | [bot] Where the original [mid]'s memory is freed (bdrv_unref, precisely). With the imaginary BlockBackend, we start over again: [top] --- backend0 --- device emulation || `--- NBD server || |commit block job [mid] | [bot] Now the block job, device and NBD server all uses BlockBackend backend0, who represents an endpoint for the blockdev operations. Normally they don't care who is behind backend0, except that block job will look at the backing BDSes, because in order to commit through the chain, it has to know the topology behind it. When the job is done, block job can safely update the backend's link to point to [bot], while all the other backend user's pointers remain valid because we don't move backend0 around. Everyone is happy. [top] /-- backend0 --- device emulation || | `--- NBD server || | || commit block job (done) [mid] | || [bot] / Is this a good direction? Fam
Re: [Qemu-devel] [PULL 2/3] hw/arm/vexpress: Alias NOR flash at 0 for vexpress-a9
On 8 July 2014 13:13, Peter Maydell peter.mayd...@linaro.org wrote: Make the vexpress-a9 board alias the first NOR flash region at address zero, like vexpress-a15. This makes -bios actually usable on this board. Oof. Judging by the headers lists.gnu sat on this email for over 36 hours... -- PMM
[Qemu-devel] [PATCH 073/156] block/cloop: refuse images with huge offsets arrays (CVE-2014-0144)
From: Stefan Hajnoczi stefa...@redhat.com
Limit offsets_size to 512 MB so that:
1. g_malloc() does not abort due to an unreasonable size argument.
2. offsets_size does not overflow the bdrv_pread() int size argument.
This limit imposes a maximum image size of 16 TB at 256 KB block size.
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
Reviewed-by: Max Reitz mre...@redhat.com
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
(cherry picked from commit 7b103b36d6ef3b11827c203d3a793bf7da50ecd6)
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
block/cloop.c | 9 +
tests/qemu-iotests/075 | 6 ++
tests/qemu-iotests/075.out | 4
3 files changed, 19 insertions(+)
diff --git a/block/cloop.c b/block/cloop.c
index 563e916..844665e 100644
--- a/block/cloop.c
+++ b/block/cloop.c
@@ -107,6 +107,15 @@ static int cloop_open(BlockDriverState *bs, QDict
*options, int flags,
return -EINVAL;
}
offsets_size = s-n_blocks * sizeof(uint64_t);
+if (offsets_size 512 * 1024 * 1024) {
+/* Prevent ridiculous offsets_size which causes memory allocation to
+ * fail or overflows bdrv_pread() size. In practice the 512 MB
+ * offsets[] limit supports 16 TB images at 256 KB block size.
+ */
+error_setg(errp, image requires too many offsets,
+ try increasing block size);
+return -EINVAL;
+}
s-offsets = g_malloc(offsets_size);
ret = bdrv_pread(bs-file, 128 + 4 + 4, s-offsets, offsets_size);
diff --git a/tests/qemu-iotests/075 b/tests/qemu-iotests/075
index 9ce6b1f..9c00fa8 100755
--- a/tests/qemu-iotests/075
+++ b/tests/qemu-iotests/075
@@ -74,6 +74,12 @@ _use_sample_img simple-pattern.cloop.bz2
poke_file $TEST_IMG $n_blocks_offset \xff\xff\xff\xff
$QEMU_IO -c read 0 512 $TEST_IMG 21 | _filter_qemu_io | _filter_testdir
+echo
+echo == refuse images that require too many offsets ===
+_use_sample_img simple-pattern.cloop.bz2
+poke_file $TEST_IMG $n_blocks_offset \x04\x00\x00\x01
+$QEMU_IO -c read 0 512 $TEST_IMG 21 | _filter_qemu_io | _filter_testdir
+
# success, all done
echo *** done
rm -f $seq.full
diff --git a/tests/qemu-iotests/075.out b/tests/qemu-iotests/075.out
index a771789..7cdaee1 100644
--- a/tests/qemu-iotests/075.out
+++ b/tests/qemu-iotests/075.out
@@ -19,4 +19,8 @@ no file open, try 'help open'
== offsets_size overflow ===
qemu-io: can't open device TEST_DIR/simple-pattern.cloop: n_blocks 4294967295
must be 536870911 or less
no file open, try 'help open'
+
+== refuse images that require too many offsets ===
+qemu-io: can't open device TEST_DIR/simple-pattern.cloop: image requires too
many offsets, try increasing block size
+no file open, try 'help open'
*** done
--
1.9.1
Re: [Qemu-devel] [PATCH for 2.1 0/2] Fix commit of oversized layer
On Thu, 07/10 11:25, Kevin Wolf wrote: Am 10.07.2014 um 10:42 hat Fam Zheng geschrieben: On Fri, 06/27 11:44, Kevin Wolf wrote: In general, it feels like it would be the right thing to do, especially considering the goal of operation categories in the final state, but on the other hand it means that RESIZE would have to be excluded from bs-backing_blocker, too, allowing standalone resize commands on backing files. Not sure that this would be a good idea... Is it really dangerous if we relax the backing_blocker on resize? In general, I expect the only critical category of operation is chain manipulation, particularly bdrv_swap. I'm not completely sure about backing_blockers on resize, but I don't think there's currently a way to make it safe, except if the image could be safely removed from the backing chain altogether. In any case, as long as block jobs don't set blockers on all images they touch but rather just on the top-level one, allowing to resize arbitrary nodes is dangerous because the block jobs can't cope with BDSes changing their size in the middle of the operation. What's the worst case here? Something like block job never complete? User might get to some error state in this case but that's expected. Because guest can't cope with devices changing their size in the middle of some of its operations, as well. Fam
Re: [Qemu-devel] [Bug 1324112] [NEW] qemu parallel building error on libcacard.la
Il 10/06/2014 17:08, tal zilcer ha scritto: Trace/generated*.o files depends on trace/generated*.la files($(libcacard-obj-y): | $(libcacard-lobj-y)) Also util depends on generated-*.o files (util-obj-y += generated-events.o) This means when libcacard.la is being build generated-*.o files can be build by the util target. I think you should change libcacard.la dependencies to include the o files and not only the la files. This should now be fixed because libcacard doesn't use trace/* anymore. In any case, this was the logic: - trace/generated-events.o should not be started until after trace/generated-events.lo has been built. - trace/generated-events.lo will also build trace/generated-events.o, so the trace/generated-events.o rule will never be invoked. Paolo
[Qemu-devel] [PULL 11/18] target-alpha: Disallow literal operand to 1C.30 to 1C.37
Before 64f45e49 we used to have literal checks for 4 of these 8 opcodes.
Confirmed that real hardware doesn't allow them.
Reported-by: Al Viro v...@zeniv.linux.org.uk
Signed-off-by: Richard Henderson r...@twiddle.net
---
target-alpha/translate.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/target-alpha/translate.c b/target-alpha/translate.c
index e0fc0a3..5785dd7 100644
--- a/target-alpha/translate.c
+++ b/target-alpha/translate.c
@@ -1357,6 +1357,13 @@ static ExitStatus gen_mtpr(DisasContext *ctx, TCGv vb,
int regno)
}
#endif /* !USER_ONLY*/
+#define REQUIRE_NO_LIT \
+do {\
+if (real_islit) { \
+goto invalid_opc; \
+} \
+} while (0)
+
#define REQUIRE_TB_FLAG(FLAG) \
do {\
if ((ctx-tb-flags (FLAG)) == 0) { \
@@ -1376,7 +1383,7 @@ static ExitStatus translate_one(DisasContext *ctx,
uint32_t insn)
int32_t disp21, disp16, disp12 __attribute__((unused));
uint16_t fn11;
uint8_t opc, ra, rb, rc, fpfn, fn7, lit;
-bool islit;
+bool islit, real_islit;
TCGv va, vb, vc, tmp, tmp2;
TCGv_i32 t32;
ExitStatus ret;
@@ -1386,7 +1393,7 @@ static ExitStatus translate_one(DisasContext *ctx,
uint32_t insn)
ra = extract32(insn, 21, 5);
rb = extract32(insn, 16, 5);
rc = extract32(insn, 0, 5);
-islit = extract32(insn, 12, 1);
+real_islit = islit = extract32(insn, 12, 1);
lit = extract32(insn, 13, 8);
disp21 = sextract32(insn, 0, 21);
@@ -2481,11 +2488,13 @@ static ExitStatus translate_one(DisasContext *ctx,
uint32_t insn)
/* CTPOP */
REQUIRE_TB_FLAG(TB_FLAGS_AMASK_CIX);
REQUIRE_REG_31(ra);
+REQUIRE_NO_LIT;
gen_helper_ctpop(vc, vb);
break;
case 0x31:
/* PERR */
REQUIRE_TB_FLAG(TB_FLAGS_AMASK_MVI);
+REQUIRE_NO_LIT;
va = load_gpr(ctx, ra);
gen_helper_perr(vc, va, vb);
break;
@@ -2493,36 +2502,42 @@ static ExitStatus translate_one(DisasContext *ctx,
uint32_t insn)
/* CTLZ */
REQUIRE_TB_FLAG(TB_FLAGS_AMASK_CIX);
REQUIRE_REG_31(ra);
+REQUIRE_NO_LIT;
gen_helper_ctlz(vc, vb);
break;
case 0x33:
/* CTTZ */
REQUIRE_TB_FLAG(TB_FLAGS_AMASK_CIX);
REQUIRE_REG_31(ra);
+REQUIRE_NO_LIT;
gen_helper_cttz(vc, vb);
break;
case 0x34:
/* UNPKBW */
REQUIRE_TB_FLAG(TB_FLAGS_AMASK_MVI);
REQUIRE_REG_31(ra);
+REQUIRE_NO_LIT;
gen_helper_unpkbw(vc, vb);
break;
case 0x35:
/* UNPKBL */
REQUIRE_TB_FLAG(TB_FLAGS_AMASK_MVI);
REQUIRE_REG_31(ra);
+REQUIRE_NO_LIT;
gen_helper_unpkbl(vc, vb);
break;
case 0x36:
/* PKWB */
REQUIRE_TB_FLAG(TB_FLAGS_AMASK_MVI);
REQUIRE_REG_31(ra);
+REQUIRE_NO_LIT;
gen_helper_pkwb(vc, vb);
break;
case 0x37:
/* PKLB */
REQUIRE_TB_FLAG(TB_FLAGS_AMASK_MVI);
REQUIRE_REG_31(ra);
+REQUIRE_NO_LIT;
gen_helper_pklb(vc, vb);
break;
case 0x38:
--
1.9.3
[Qemu-devel] [RFC 19/25] accel: Use target-specific accel class if available
Target-specific accelerator subclasses are optional. If a given
accelerator type needs to make it mandatory, the base class can be made
abstract.
Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
hw/core/accel.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/hw/core/accel.c b/hw/core/accel.c
index 78e7dfc..6efe36c 100644
--- a/hw/core/accel.c
+++ b/hw/core/accel.c
@@ -51,11 +51,25 @@ static const TypeInfo accel_type = {
};
/* Lookup AccelClass from opt_name. Returns NULL if not found */
-static AccelClass *accel_find(const char *opt_name)
+static AccelClass *accel_find(const char *opt_name, const char *target_name)
{
char *class_name = g_strdup_printf(%s-accel, opt_name);
-AccelClass *ac = ACCEL_CLASS(object_class_by_name(class_name));
+char *target_class_name = g_strdup_printf(%s-%s-accel,
+ target_name, opt_name);
+ObjectClass *oc;
+AccelClass *ac;
+oc = object_class_by_name(target_class_name);
+if (!oc) {
+oc = object_class_by_name(class_name);
+}
+/* Must be a TYPE_ACCEL subclass, and not abstract */
+oc = object_class_dynamic_cast(oc, TYPE_ACCEL);
+if (oc object_class_is_abstract(oc)) {
+oc = NULL;
+}
+ac = ACCEL_CLASS(oc);
g_free(class_name);
+g_free(target_class_name);
return ac;
}
@@ -96,7 +110,7 @@ int init_accelerator(MachineState *ms, const char
*target_name)
p++;
}
p = get_opt_name(buf, sizeof(buf), p, ':');
-acc = accel_find(buf);
+acc = accel_find(buf, target_name);
if (!acc) {
fprintf(stderr, \%s\ accelerator does not exist.\n, buf);
continue;
--
1.9.3
Re: [Qemu-devel] [PATCH for 2.1 0/2] Fix commit of oversized layer
Am 10.07.2014 um 10:42 hat Fam Zheng geschrieben: On Fri, 06/27 11:44, Kevin Wolf wrote: In general, it feels like it would be the right thing to do, especially considering the goal of operation categories in the final state, but on the other hand it means that RESIZE would have to be excluded from bs-backing_blocker, too, allowing standalone resize commands on backing files. Not sure that this would be a good idea... Is it really dangerous if we relax the backing_blocker on resize? In general, I expect the only critical category of operation is chain manipulation, particularly bdrv_swap. I'm not completely sure about backing_blockers on resize, but I don't think there's currently a way to make it safe, except if the image could be safely removed from the backing chain altogether. In any case, as long as block jobs don't set blockers on all images they touch but rather just on the top-level one, allowing to resize arbitrary nodes is dangerous because the block jobs can't cope with BDSes changing their size in the middle of the operation. And speaking of bdrv_swap, in longer term, if we have the BlockBackend that can serve as a level of abstraction between BlockDriverState (the backend implementation) and its users (the backend consumers, like device), we can probably drop bdrv_swap() by updating the BB-BDS link. [...] Is this a good direction? Yes, eventually we'll want to get rid of bdrv_swap() and just update pointers instead. We're not quite there yet, though. Kevin
Re: [Qemu-devel] [PATCH v4 2.1 0/4] Suppress error action on r/w beyond end
Am 09.07.2014 um 19:07 hat Markus Armbruster geschrieben: When a device model's I/O operation fails, we execute the error action. This lets layers above QEMU implement thin provisioning, or attempt to correct errors before they reach the guest. But when the I/O operation fails because its invalid, reporting the error to the guest is the only sensible action. SCSI does that, but virtio-blk and IDE don't. Fix them. No other device model supports error actions. Thanks, applied to the block branch. Kevin
Re: [Qemu-devel] [PATCH v5] spapr: add uuid/host details to device tree
On 09.07.14 12:38, Nikunj A Dadhania wrote: Useful for identifying the guest/host uniquely within the guest. Adding following properties to the guest root node. vm,uuid - uuid of the guest host-model - Host model number host-serial - Host machine serial number hypervisor type - Tells its kvm Signed-off-by: Nikunj A Dadhania nik...@linux.vnet.ibm.com Thanks, applied to ppc-next-2.2. Alex
[Qemu-devel] [PATCH 0/6 v6] ppc: Add debug stub support
This patchset add support for - software breakpoint - h/w breakpoint - h/w watchpoint Please find description in individual patch. v5-v6 - Added a new patch to synchronize excp_vectors. - Inject program exception rather than debug exception if guest is not able to handle debug exception. why? detail in respective patch. v4-v5 - cleanup in kvmppc_hw_debug_points_init() - replaced assert in kvm_arch_insert_hw_breakpoint() with return. This allows gdb to through warning You may have requested too many hardware breakpoints/watchpoints.. Now user can remove extra breakpint and continue. v3-v4 - remove hardcoding for size of instruction in software breakpoint - remove unnecessary assert in debug handler - Corrected assert comparison in insert_breakpoint() v2-v3 - Sharing of code for book3s support (which may come in future) - Initializing number of hw breakpoint/watchpoints from KVM world - Other minor cleanup/fixes v1-v2: - use kvm_get_one_reg() for getting trap instruction - factored out e500 specific code based on exception model POWERPC_EXCP_BOOKE. - Not supporting ppc440 Bharat Bhushan (6): ppc: debug stub: Get trap instruction opcode from KVM ppc: Add interface to inject interrupt to guest ppc: synchronize excp_vectors for injecting exception ppc: Add program exception injection handler ppc: Add software breakpoint support ppc: Add hw breakpoint watchpoint support target-ppc/cpu.h | 1 + target-ppc/kvm.c | 390 +++ 2 files changed, 363 insertions(+), 28 deletions(-) -- 1.9.3
[Qemu-devel] [PATCH 2/6 v6] ppc: Add interface to inject interrupt to guest
This patch adds interface to inject interrupt to guest.
Currently a void program check exception function added.
Follow up patch will use this interface to inject program
check exception to guest
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
v5-v6
- replace debug with program interrupt
target-ppc/cpu.h | 1 +
target-ppc/kvm.c | 23 +++
2 files changed, 24 insertions(+)
diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
index b64c652..e60fc40 100644
--- a/target-ppc/cpu.h
+++ b/target-ppc/cpu.h
@@ -2144,6 +2144,7 @@ enum {
PPC_INTERRUPT_CDOORBELL, /* Critical doorbell interrupt */
PPC_INTERRUPT_DOORBELL, /* Doorbell interrupt */
PPC_INTERRUPT_PERFM, /* Performance monitor interrupt*/
+PPC_INTERRUPT_PROGRAM,/* Program check exception */
};
/* Processor Compatibility mask (PCR) */
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 4df23dd..673c369 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -761,6 +761,25 @@ static int kvm_put_vpa(CPUState *cs)
}
#endif /* TARGET_PPC64 */
+static int kvmppc_inject_program_exception(CPUState *cs)
+{
+return 0;
+}
+
+static void kvmppc_inject_exception(CPUState *cs)
+{
+PowerPCCPU *cpu = POWERPC_CPU(cs);
+CPUPPCState *env = cpu-env;
+
+if (env-pending_interrupts (1 PPC_INTERRUPT_PROGRAM)) {
+if (kvmppc_inject_program_exception(cs)) {
+fprintf(stderr, %s: PROGRAM exception injection failed\n,
__func__);
+return;
+}
+env-pending_interrupts = ~(1 PPC_INTERRUPT_PROGRAM);
+}
+}
+
int kvm_arch_put_registers(CPUState *cs, int level)
{
PowerPCCPU *cpu = POWERPC_CPU(cs);
@@ -774,6 +793,10 @@ int kvm_arch_put_registers(CPUState *cs, int level)
return ret;
}
+if (env-pending_interrupts) {
+kvmppc_inject_exception(cs);
+}
+
regs.ctr = env-ctr;
regs.lr = env-lr;
regs.xer = cpu_read_xer(env);
--
1.9.3
[Qemu-devel] [PATCH 4/6 v6] ppc: Add program exception injection handler
With this patch a program check exception can be injected
to guest. Follow up patch will use this interface to inject
program exception to guest.
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
v5-v6
- new patch (infact replace debug interrupt injection)
target-ppc/kvm.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 329a38b..d1239b4 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -763,6 +763,11 @@ static int kvm_put_vpa(CPUState *cs)
static int kvmppc_inject_program_exception(CPUState *cs)
{
+PowerPCCPU *cpu = POWERPC_CPU(cs);
+CPUPPCState *env = cpu-env;
+cs-exception_index = POWERPC_EXCP_PROGRAM;
+env-error_code = POWERPC_EXCP_INVAL;
+ppc_cpu_do_interrupt(cs);
return 0;
}
--
1.9.3
[Qemu-devel] [PATCH 3/6 v6] ppc: synchronize excp_vectors for injecting exception
This patch synchronizes env-excp_vectors[] with env-iovr[].
This is required for using the existing interrupt injection mechanism
for kvm.
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
v5-v6
- new patch
target-ppc/kvm.c | 44
1 file changed, 44 insertions(+)
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 673c369..329a38b 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -1008,35 +1008,79 @@ int kvm_arch_get_registers(CPUState *cs)
if (sregs.u.e.features KVM_SREGS_E_IVOR) {
env-spr[SPR_BOOKE_IVOR0] = sregs.u.e.ivor_low[0];
+env-excp_vectors[POWERPC_EXCP_CRITICAL] =
+ env-spr[SPR_BOOKE_IVOR0] + env-spr[SPR_BOOKE_IVPR];
env-spr[SPR_BOOKE_IVOR1] = sregs.u.e.ivor_low[1];
+env-excp_vectors[POWERPC_EXCP_MCHECK] =
+ env-spr[SPR_BOOKE_IVOR1] + env-spr[SPR_BOOKE_IVPR];
env-spr[SPR_BOOKE_IVOR2] = sregs.u.e.ivor_low[2];
+env-excp_vectors[POWERPC_EXCP_DSI] =
+ env-spr[SPR_BOOKE_IVOR2] + env-spr[SPR_BOOKE_IVPR];
env-spr[SPR_BOOKE_IVOR3] = sregs.u.e.ivor_low[3];
+env-excp_vectors[POWERPC_EXCP_ISI] =
+ env-spr[SPR_BOOKE_IVOR3] + env-spr[SPR_BOOKE_IVPR];
env-spr[SPR_BOOKE_IVOR4] = sregs.u.e.ivor_low[4];
+env-excp_vectors[POWERPC_EXCP_EXTERNAL] =
+ env-spr[SPR_BOOKE_IVOR4] + env-spr[SPR_BOOKE_IVPR];
env-spr[SPR_BOOKE_IVOR5] = sregs.u.e.ivor_low[5];
+env-excp_vectors[POWERPC_EXCP_ALIGN] =
+ env-spr[SPR_BOOKE_IVOR5] + env-spr[SPR_BOOKE_IVPR];
env-spr[SPR_BOOKE_IVOR6] = sregs.u.e.ivor_low[6];
+env-excp_vectors[POWERPC_EXCP_PROGRAM] =
+ env-spr[SPR_BOOKE_IVOR6] + env-spr[SPR_BOOKE_IVPR];
env-spr[SPR_BOOKE_IVOR7] = sregs.u.e.ivor_low[7];
+env-excp_vectors[POWERPC_EXCP_FPU] =
+ env-spr[SPR_BOOKE_IVOR7] + env-spr[SPR_BOOKE_IVPR];
env-spr[SPR_BOOKE_IVOR8] = sregs.u.e.ivor_low[8];
+env-excp_vectors[POWERPC_EXCP_SYSCALL] =
+ env-spr[SPR_BOOKE_IVOR8] + env-spr[SPR_BOOKE_IVPR];
env-spr[SPR_BOOKE_IVOR9] = sregs.u.e.ivor_low[9];
+env-excp_vectors[POWERPC_EXCP_APU] =
+ env-spr[SPR_BOOKE_IVOR9] + env-spr[SPR_BOOKE_IVPR];
env-spr[SPR_BOOKE_IVOR10] = sregs.u.e.ivor_low[10];
+env-excp_vectors[POWERPC_EXCP_DECR] =
+ env-spr[SPR_BOOKE_IVOR10] + env-spr[SPR_BOOKE_IVPR];
env-spr[SPR_BOOKE_IVOR11] = sregs.u.e.ivor_low[11];
+env-excp_vectors[POWERPC_EXCP_FIT] =
+ env-spr[SPR_BOOKE_IVOR11] + env-spr[SPR_BOOKE_IVPR];
env-spr[SPR_BOOKE_IVOR12] = sregs.u.e.ivor_low[12];
+env-excp_vectors[POWERPC_EXCP_WDT] =
+ env-spr[SPR_BOOKE_IVOR12] + env-spr[SPR_BOOKE_IVPR];
env-spr[SPR_BOOKE_IVOR13] = sregs.u.e.ivor_low[13];
+env-excp_vectors[POWERPC_EXCP_DTLB] =
+ env-spr[SPR_BOOKE_IVOR13] + env-spr[SPR_BOOKE_IVPR];
env-spr[SPR_BOOKE_IVOR14] = sregs.u.e.ivor_low[14];
+env-excp_vectors[POWERPC_EXCP_ITLB] =
+ env-spr[SPR_BOOKE_IVOR14] + env-spr[SPR_BOOKE_IVPR];
env-spr[SPR_BOOKE_IVOR15] = sregs.u.e.ivor_low[15];
+env-excp_vectors[POWERPC_EXCP_DEBUG] =
+ env-spr[SPR_BOOKE_IVOR15] + env-spr[SPR_BOOKE_IVPR];
if (sregs.u.e.features KVM_SREGS_E_SPE) {
env-spr[SPR_BOOKE_IVOR32] = sregs.u.e.ivor_high[0];
+env-excp_vectors[POWERPC_EXCP_SPEU] =
+ env-spr[SPR_BOOKE_IVOR32] + env-spr[SPR_BOOKE_IVPR];
env-spr[SPR_BOOKE_IVOR33] = sregs.u.e.ivor_high[1];
+env-excp_vectors[POWERPC_EXCP_EFPDI] =
+ env-spr[SPR_BOOKE_IVOR33] + env-spr[SPR_BOOKE_IVPR];
env-spr[SPR_BOOKE_IVOR34] = sregs.u.e.ivor_high[2];
+env-excp_vectors[POWERPC_EXCP_EFPRI] =
+ env-spr[SPR_BOOKE_IVOR34] + env-spr[SPR_BOOKE_IVPR];
}
if (sregs.u.e.features KVM_SREGS_E_PM) {
env-spr[SPR_BOOKE_IVOR35] = sregs.u.e.ivor_high[3];
+env-excp_vectors[POWERPC_EXCP_EPERFM] =
+ env-spr[SPR_BOOKE_IVOR35] + env-spr[SPR_BOOKE_IVPR];
}
if (sregs.u.e.features KVM_SREGS_E_PC) {
env-spr[SPR_BOOKE_IVOR36] = sregs.u.e.ivor_high[4];
+env-excp_vectors[POWERPC_EXCP_DOORI] =
+ env-spr[SPR_BOOKE_IVOR36] + env-spr[SPR_BOOKE_IVPR];
env-spr[SPR_BOOKE_IVOR37] = sregs.u.e.ivor_high[5];
+env-excp_vectors[POWERPC_EXCP_DOORCI] =
+ env-spr[SPR_BOOKE_IVOR37] + env-spr[SPR_BOOKE_IVPR];
}
}
--
1.9.3
Re: [Qemu-devel] [PATCH 2/6 v6] ppc: Add interface to inject interrupt to guest
On 10.07.14 12:57, Bharat Bhushan wrote:
This patch adds interface to inject interrupt to guest.
Currently a void program check exception function added.
Follow up patch will use this interface to inject program
check exception to guest
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
v5-v6
- replace debug with program interrupt
target-ppc/cpu.h | 1 +
target-ppc/kvm.c | 23 +++
2 files changed, 24 insertions(+)
diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
index b64c652..e60fc40 100644
--- a/target-ppc/cpu.h
+++ b/target-ppc/cpu.h
@@ -2144,6 +2144,7 @@ enum {
PPC_INTERRUPT_CDOORBELL, /* Critical doorbell interrupt */
PPC_INTERRUPT_DOORBELL, /* Doorbell interrupt */
PPC_INTERRUPT_PERFM, /* Performance monitor interrupt*/
+PPC_INTERRUPT_PROGRAM,/* Program check exception */
};
/* Processor Compatibility mask (PCR) */
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 4df23dd..673c369 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -761,6 +761,25 @@ static int kvm_put_vpa(CPUState *cs)
}
#endif /* TARGET_PPC64 */
+static int kvmppc_inject_program_exception(CPUState *cs)
+{
+return 0;
+}
+
+static void kvmppc_inject_exception(CPUState *cs)
+{
+PowerPCCPU *cpu = POWERPC_CPU(cs);
+CPUPPCState *env = cpu-env;
+
+if (env-pending_interrupts (1 PPC_INTERRUPT_PROGRAM)) {
+if (kvmppc_inject_program_exception(cs)) {
+fprintf(stderr, %s: PROGRAM exception injection failed\n,
__func__);
+return;
+}
+env-pending_interrupts = ~(1 PPC_INTERRUPT_PROGRAM);
Do we really need to jump through these hoops? We could just directly
call the injection, no?
Alex
+}
+}
+
int kvm_arch_put_registers(CPUState *cs, int level)
{
PowerPCCPU *cpu = POWERPC_CPU(cs);
@@ -774,6 +793,10 @@ int kvm_arch_put_registers(CPUState *cs, int level)
return ret;
}
+if (env-pending_interrupts) {
+kvmppc_inject_exception(cs);
+}
+
regs.ctr = env-ctr;
regs.lr = env-lr;
regs.xer = cpu_read_xer(env);
Re: [Qemu-devel] [PATCH 3/6 v6] ppc: synchronize excp_vectors for injecting exception
On 10.07.14 12:57, Bharat Bhushan wrote:
This patch synchronizes env-excp_vectors[] with env-iovr[].
This is required for using the existing interrupt injection mechanism
for kvm.
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
v5-v6
- new patch
target-ppc/kvm.c | 44
1 file changed, 44 insertions(+)
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 673c369..329a38b 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -1008,35 +1008,79 @@ int kvm_arch_get_registers(CPUState *cs)
if (sregs.u.e.features KVM_SREGS_E_IVOR) {
env-spr[SPR_BOOKE_IVOR0] = sregs.u.e.ivor_low[0];
+env-excp_vectors[POWERPC_EXCP_CRITICAL] =
+ env-spr[SPR_BOOKE_IVOR0] + env-spr[SPR_BOOKE_IVPR];
This is quite hard to read. How about
static void kvm_sync_excp(CPUPPCState *env, int vector, int ivor)
{
env-excp_vectors[vector] = env-spr[ivor] + env-spr[SPR_BOOKE_IVPR];
}
kvm_sync_excp(env, POWERPC_EXCP_CRITICAL, SPR_BOOKE_IVOR0);
Alex
env-spr[SPR_BOOKE_IVOR1] = sregs.u.e.ivor_low[1];
+env-excp_vectors[POWERPC_EXCP_MCHECK] =
+ env-spr[SPR_BOOKE_IVOR1] + env-spr[SPR_BOOKE_IVPR];
env-spr[SPR_BOOKE_IVOR2] = sregs.u.e.ivor_low[2];
+env-excp_vectors[POWERPC_EXCP_DSI] =
+ env-spr[SPR_BOOKE_IVOR2] + env-spr[SPR_BOOKE_IVPR];
env-spr[SPR_BOOKE_IVOR3] = sregs.u.e.ivor_low[3];
+env-excp_vectors[POWERPC_EXCP_ISI] =
+ env-spr[SPR_BOOKE_IVOR3] + env-spr[SPR_BOOKE_IVPR];
env-spr[SPR_BOOKE_IVOR4] = sregs.u.e.ivor_low[4];
+env-excp_vectors[POWERPC_EXCP_EXTERNAL] =
+ env-spr[SPR_BOOKE_IVOR4] + env-spr[SPR_BOOKE_IVPR];
env-spr[SPR_BOOKE_IVOR5] = sregs.u.e.ivor_low[5];
+env-excp_vectors[POWERPC_EXCP_ALIGN] =
+ env-spr[SPR_BOOKE_IVOR5] + env-spr[SPR_BOOKE_IVPR];
env-spr[SPR_BOOKE_IVOR6] = sregs.u.e.ivor_low[6];
+env-excp_vectors[POWERPC_EXCP_PROGRAM] =
+ env-spr[SPR_BOOKE_IVOR6] + env-spr[SPR_BOOKE_IVPR];
env-spr[SPR_BOOKE_IVOR7] = sregs.u.e.ivor_low[7];
+env-excp_vectors[POWERPC_EXCP_FPU] =
+ env-spr[SPR_BOOKE_IVOR7] + env-spr[SPR_BOOKE_IVPR];
env-spr[SPR_BOOKE_IVOR8] = sregs.u.e.ivor_low[8];
+env-excp_vectors[POWERPC_EXCP_SYSCALL] =
+ env-spr[SPR_BOOKE_IVOR8] + env-spr[SPR_BOOKE_IVPR];
env-spr[SPR_BOOKE_IVOR9] = sregs.u.e.ivor_low[9];
+env-excp_vectors[POWERPC_EXCP_APU] =
+ env-spr[SPR_BOOKE_IVOR9] + env-spr[SPR_BOOKE_IVPR];
env-spr[SPR_BOOKE_IVOR10] = sregs.u.e.ivor_low[10];
+env-excp_vectors[POWERPC_EXCP_DECR] =
+ env-spr[SPR_BOOKE_IVOR10] + env-spr[SPR_BOOKE_IVPR];
env-spr[SPR_BOOKE_IVOR11] = sregs.u.e.ivor_low[11];
+env-excp_vectors[POWERPC_EXCP_FIT] =
+ env-spr[SPR_BOOKE_IVOR11] + env-spr[SPR_BOOKE_IVPR];
env-spr[SPR_BOOKE_IVOR12] = sregs.u.e.ivor_low[12];
+env-excp_vectors[POWERPC_EXCP_WDT] =
+ env-spr[SPR_BOOKE_IVOR12] + env-spr[SPR_BOOKE_IVPR];
env-spr[SPR_BOOKE_IVOR13] = sregs.u.e.ivor_low[13];
+env-excp_vectors[POWERPC_EXCP_DTLB] =
+ env-spr[SPR_BOOKE_IVOR13] + env-spr[SPR_BOOKE_IVPR];
env-spr[SPR_BOOKE_IVOR14] = sregs.u.e.ivor_low[14];
+env-excp_vectors[POWERPC_EXCP_ITLB] =
+ env-spr[SPR_BOOKE_IVOR14] + env-spr[SPR_BOOKE_IVPR];
env-spr[SPR_BOOKE_IVOR15] = sregs.u.e.ivor_low[15];
+env-excp_vectors[POWERPC_EXCP_DEBUG] =
+ env-spr[SPR_BOOKE_IVOR15] + env-spr[SPR_BOOKE_IVPR];
if (sregs.u.e.features KVM_SREGS_E_SPE) {
env-spr[SPR_BOOKE_IVOR32] = sregs.u.e.ivor_high[0];
+env-excp_vectors[POWERPC_EXCP_SPEU] =
+ env-spr[SPR_BOOKE_IVOR32] + env-spr[SPR_BOOKE_IVPR];
env-spr[SPR_BOOKE_IVOR33] = sregs.u.e.ivor_high[1];
+env-excp_vectors[POWERPC_EXCP_EFPDI] =
+ env-spr[SPR_BOOKE_IVOR33] + env-spr[SPR_BOOKE_IVPR];
env-spr[SPR_BOOKE_IVOR34] = sregs.u.e.ivor_high[2];
+env-excp_vectors[POWERPC_EXCP_EFPRI] =
+ env-spr[SPR_BOOKE_IVOR34] + env-spr[SPR_BOOKE_IVPR];
}
if (sregs.u.e.features KVM_SREGS_E_PM) {
env-spr[SPR_BOOKE_IVOR35] = sregs.u.e.ivor_high[3];
+env-excp_vectors[POWERPC_EXCP_EPERFM] =
+ env-spr[SPR_BOOKE_IVOR35] + env-spr[SPR_BOOKE_IVPR];
}
if (sregs.u.e.features KVM_SREGS_E_PC) {
env-spr[SPR_BOOKE_IVOR36] = sregs.u.e.ivor_high[4];
+
Re: [Qemu-devel] [PATCH 5/6 v6] ppc: Add software breakpoint support
On 10.07.14 12:58, Bharat Bhushan wrote:
This patch allow insert/remove software breakpoint
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
v5-v6
- No change
target-ppc/kvm.c | 73 +---
1 file changed, 59 insertions(+), 14 deletions(-)
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index d1239b4..c4a1fa5 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -1320,6 +1320,55 @@ static int kvmppc_handle_dcr_write(CPUPPCState *env,
uint32_t dcrn, uint32_t dat
return 0;
}
+int kvm_arch_insert_sw_breakpoint(CPUState *cs, struct kvm_sw_breakpoint *bp)
+{
+/* Mixed endian case is not handled */
+uint32_t sc = debug_inst_opcode;
+
+if (cpu_memory_rw_debug(cs, bp-pc, (uint8_t *)bp-saved_insn,
+sizeof(sc), 0) ||
+cpu_memory_rw_debug(cs, bp-pc, (uint8_t *)sc, sizeof(sc), 1)) {
+return -EINVAL;
+}
+
+return 0;
+}
+
+int kvm_arch_remove_sw_breakpoint(CPUState *cs, struct kvm_sw_breakpoint *bp)
+{
+uint32_t sc;
+
+if (cpu_memory_rw_debug(cs, bp-pc, (uint8_t *)sc, sizeof(sc), 0) ||
+sc != debug_inst_opcode ||
+cpu_memory_rw_debug(cs, bp-pc, (uint8_t *)bp-saved_insn,
+sizeof(sc), 1)) {
+return -EINVAL;
+}
+
+return 0;
+}
+
+void kvm_arch_update_guest_debug(CPUState *cs, struct kvm_guest_debug *dbg)
+{
+/* Software Breakpoint updates */
+if (kvm_sw_breakpoints_active(cs)) {
+dbg-control |= KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_SW_BP;
+}
+}
+
+static int kvm_handle_debug(PowerPCCPU *cpu, struct kvm_run *run)
+{
+CPUState *cs = CPU(cpu);
+struct kvm_debug_exit_arch *arch_info = run-debug.arch;
+int handle = 0;
+
+if (kvm_find_sw_breakpoint(cs, arch_info-address)) {
+handle = 1;
+}
+
+return handle;
+}
+
int kvm_arch_handle_exit(CPUState *cs, struct kvm_run *run)
{
PowerPCCPU *cpu = POWERPC_CPU(cs);
@@ -1360,6 +1409,16 @@ int kvm_arch_handle_exit(CPUState *cs, struct kvm_run
*run)
ret = 0;
break;
+case KVM_EXIT_DEBUG:
+DPRINTF(handle debug exception\n);
+if (kvm_handle_debug(cpu, run)) {
+ret = EXCP_DEBUG;
+break;
+}
+/* re-enter, this exception was guest-internal */
+ret = 0;
Where do we inject the program interrupt into our guest here?
Alex
Re: [Qemu-devel] [PATCH] pass $($*.o-cflags) first to gcc/g++
On Thu, 10 Jul 2014, Paolo Bonzini wrote: Il 09/07/2014 23:59, Stefano Stabellini ha scritto: On Wed, 9 Jul 2014, Paolo Bonzini wrote: What package is it that has the conflicting utils.h file? Any chance to get it fixed in your distro? Here I get: $ find /usr/include/ -name utils.h /usr/include/libnl3/netlink/utils.h /usr/include/libnl3/netlink/cli/utils.h /usr/include/id3/utils.h /usr/include/octave-3.6.4/octave/utils.h but none of them have the path in -I. It's Xen: when building QEMU as part of the Xen build process, tools/Makefile uses --extra-cflags to add the local Xen directories to the QEMU include path. However one of the Xen header files is named utils.h, conflicting with utils.h from disas/libvixl. It seems to be that --extra-cflags should come after the QEMU include paths. I think the bug is in Xen then. I have an oldish checkout and I see: $ find . -name utils.h ./tools/console/daemon/utils.h ./tools/xenstore/utils.h this is the one Could you move more headers to tools/include/ and avoid polluting QEMU_CFLAGS? I'll see what I can do That said, for this particular case not using foo.o-cflags can be a stopgap solution too. Thanks, I'll try to work on the Xen side to fix the problem. I'll come back to this patch only if strictly necessary :-)
Re: [Qemu-devel] [PATCH 6/6 v6] ppc: Add hw breakpoint watchpoint support
On 10.07.14 12:58, Bharat Bhushan wrote:
This patch adds hardware breakpoint and hardware watchpoint support
for ppc.
On BOOKE architecture we cannot share debug resources between QEMU
and guest because:
When QEMU is using debug resources then debug exception must
be always enabled. To achieve this we set MSR_DE and also set
MSRP_DEP so guest cannot change MSR_DE.
When emulating debug resource for guest we want guest
to control MSR_DE (enable/disable debug interrupt on need).
So above mentioned two configuration cannot be supported
at the same time. So the result is that we cannot share
debug resources between QEMU and Guest on BOOKE architecture.
In the current design QEMU gets priority over guest,
this means that if QEMU is using debug resources then guest
cannot use them and if guest is using debug resource then
qemu can overwrite them.
When QEMU is not able to handle debug exception then we inject program
exception to guest. Yes program exception NOT debug exception and the
reason is:
1) QEMU and guest not sharing debug resources
2) For software breakpoint QEMU uses a ehpriv-1 instruction;
So there cannot be any reason that we are in qemu with exit reason
KVM_EXIT_DEBUG for guest set debug exception, only possibility is
guest executed ehpriv-1 privilege instruction and that's why we are
injecting program exception.
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
v5-v6
- Inject program exception rather than debug exception if
guest is not able to handle debug exception. why? detail
in respective patch.
target-ppc/kvm.c | 245 +++
1 file changed, 229 insertions(+), 16 deletions(-)
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index c4a1fa5..6156f09 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -38,6 +38,7 @@
#include hw/ppc/ppc.h
#include sysemu/watchdog.h
#include trace.h
+#include exec/gdbstub.h
//#define DEBUG_KVM
@@ -412,6 +413,38 @@ unsigned long kvm_arch_vcpu_id(CPUState *cpu)
return ppc_get_vcpu_dt_id(POWERPC_CPU(cpu));
}
+/* e500 supports 2 h/w breakpoint and 2 watchpoint.
+ * book3s supports only 1 watchpoint, so array size
+ * of 4 is sufficient for now.
+ */
+#define MAX_HW_BKPTS 4
+
+static struct HWBreakpoint {
+target_ulong addr;
+int type;
+} hw_debug_points[MAX_HW_BKPTS];
+
+static CPUWatchpoint hw_watchpoint;
+
+/* Default there is no breakpoint and watchpoint supported */
+static int max_hw_breakpoint;
+static int max_hw_watchpoint;
+static int nb_hw_breakpoint;
+static int nb_hw_watchpoint;
+
+static void kvmppc_hw_debug_points_init(CPUPPCState *cenv)
+{
+if (cenv-excp_model == POWERPC_EXCP_BOOKE) {
+max_hw_breakpoint = 2;
+max_hw_watchpoint = 2;
+}
+
+if ((max_hw_breakpoint + max_hw_watchpoint) MAX_HW_BKPTS) {
+fprintf(stderr, Error initializing h/w breakpoints\n);
+return;
+}
+}
+
int kvm_arch_init_vcpu(CPUState *cs)
{
PowerPCCPU *cpu = POWERPC_CPU(cs);
@@ -439,6 +472,7 @@ int kvm_arch_init_vcpu(CPUState *cs)
}
kvm_get_one_reg(cs, KVM_REG_PPC_DEBUG_INST, debug_inst_opcode);
+kvmppc_hw_debug_points_init(cenv);
return ret;
}
@@ -1348,24 +1382,217 @@ int kvm_arch_remove_sw_breakpoint(CPUState *cs, struct
kvm_sw_breakpoint *bp)
return 0;
}
+static int find_hw_breakpoint(target_ulong addr, int type)
+{
+int n;
+
+assert((nb_hw_breakpoint + nb_hw_watchpoint)
+ = ARRAY_SIZE(hw_debug_points));
+
+for (n = 0; n nb_hw_breakpoint + nb_hw_watchpoint; n++) {
+if (hw_debug_points[n].addr == addr hw_debug_points[n].type ==
type) {
+return n;
+}
+}
+
+return -1;
+}
+
+static int find_hw_watchpoint(target_ulong addr, int *flag)
+{
+int n;
+
+n = find_hw_breakpoint(addr, GDB_WATCHPOINT_ACCESS);
+if (n = 0) {
+*flag = BP_MEM_ACCESS;
+return n;
+}
+
+n = find_hw_breakpoint(addr, GDB_WATCHPOINT_WRITE);
+if (n = 0) {
+*flag = BP_MEM_WRITE;
+return n;
+}
+
+n = find_hw_breakpoint(addr, GDB_WATCHPOINT_READ);
+if (n = 0) {
+*flag = BP_MEM_READ;
+return n;
+}
+
+return -1;
+}
+
+int kvm_arch_insert_hw_breakpoint(target_ulong addr,
+ target_ulong len, int type)
+{
+if ((nb_hw_breakpoint + nb_hw_watchpoint) = ARRAY_SIZE(hw_debug_points))
+ return -ENOBUFS;
+
+hw_debug_points[nb_hw_breakpoint + nb_hw_watchpoint].addr = addr;
+hw_debug_points[nb_hw_breakpoint + nb_hw_watchpoint].type = type;
+
+switch (type) {
+case GDB_BREAKPOINT_HW:
+if (nb_hw_breakpoint = max_hw_breakpoint) {
+return -ENOBUFS;
+}
+
+if (find_hw_breakpoint(addr, type) = 0) {
+return -EEXIST;
+}
+
+nb_hw_breakpoint++;
+break;
+
+case GDB_WATCHPOINT_WRITE:
+case
[Qemu-devel] [PULL 09/18] target-alpha: Fix integer overflow checking insns
We need to write the result to the destination register before
raising any exception. Thus inline the code for each insn, and
check for any exception after we're done.
Reported-by: Al Viro v...@zeniv.linux.org.uk
Signed-off-by: Richard Henderson r...@twiddle.net
---
target-alpha/helper.h | 7 +-
target-alpha/int_helper.c | 59 ++
target-alpha/translate.c | 60 +--
3 files changed, 56 insertions(+), 70 deletions(-)
diff --git a/target-alpha/helper.h b/target-alpha/helper.h
index 173db01..2cc100b 100644
--- a/target-alpha/helper.h
+++ b/target-alpha/helper.h
@@ -1,12 +1,7 @@
DEF_HELPER_3(excp, noreturn, env, int, int)
DEF_HELPER_FLAGS_1(load_pcc, TCG_CALL_NO_RWG_SE, i64, env)
-DEF_HELPER_FLAGS_3(addqv, TCG_CALL_NO_WG, i64, env, i64, i64)
-DEF_HELPER_FLAGS_3(addlv, TCG_CALL_NO_WG, i64, env, i64, i64)
-DEF_HELPER_FLAGS_3(subqv, TCG_CALL_NO_WG, i64, env, i64, i64)
-DEF_HELPER_FLAGS_3(sublv, TCG_CALL_NO_WG, i64, env, i64, i64)
-DEF_HELPER_FLAGS_3(mullv, TCG_CALL_NO_WG, i64, env, i64, i64)
-DEF_HELPER_FLAGS_3(mulqv, TCG_CALL_NO_WG, i64, env, i64, i64)
+DEF_HELPER_FLAGS_3(check_overflow, TCG_CALL_NO_WG, void, env, i64, i64)
DEF_HELPER_FLAGS_1(ctpop, TCG_CALL_NO_RWG_SE, i64, i64)
DEF_HELPER_FLAGS_1(ctlz, TCG_CALL_NO_RWG_SE, i64, i64)
diff --git a/target-alpha/int_helper.c b/target-alpha/int_helper.c
index 7a205eb..8e4537f 100644
--- a/target-alpha/int_helper.c
+++ b/target-alpha/int_helper.c
@@ -249,64 +249,9 @@ uint64_t helper_unpkbw(uint64_t op1)
| ((op1 0xff00) 24));
}
-uint64_t helper_addqv(CPUAlphaState *env, uint64_t op1, uint64_t op2)
+void helper_check_overflow(CPUAlphaState *env, uint64_t op1, uint64_t op2)
{
-uint64_t tmp = op1;
-op1 += op2;
-if (unlikely((tmp ^ op2 ^ (-1ULL)) (tmp ^ op1) (1ULL 63))) {
+if (unlikely(op1 != op2)) {
arith_excp(env, GETPC(), EXC_M_IOV, 0);
}
-return op1;
-}
-
-uint64_t helper_addlv(CPUAlphaState *env, uint64_t op1, uint64_t op2)
-{
-uint64_t tmp = op1;
-op1 = (uint32_t)(op1 + op2);
-if (unlikely((tmp ^ op2 ^ (-1UL)) (tmp ^ op1) (1UL 31))) {
-arith_excp(env, GETPC(), EXC_M_IOV, 0);
-}
-return op1;
-}
-
-uint64_t helper_subqv(CPUAlphaState *env, uint64_t op1, uint64_t op2)
-{
-uint64_t res;
-res = op1 - op2;
-if (unlikely((op1 ^ op2) (res ^ op1) (1ULL 63))) {
-arith_excp(env, GETPC(), EXC_M_IOV, 0);
-}
-return res;
-}
-
-uint64_t helper_sublv(CPUAlphaState *env, uint64_t op1, uint64_t op2)
-{
-uint32_t res;
-res = op1 - op2;
-if (unlikely((op1 ^ op2) (res ^ op1) (1UL 31))) {
-arith_excp(env, GETPC(), EXC_M_IOV, 0);
-}
-return res;
-}
-
-uint64_t helper_mullv(CPUAlphaState *env, uint64_t op1, uint64_t op2)
-{
-int64_t res = (int64_t)op1 * (int64_t)op2;
-
-if (unlikely((int32_t)res != res)) {
-arith_excp(env, GETPC(), EXC_M_IOV, 0);
-}
-return (int64_t)((int32_t)res);
-}
-
-uint64_t helper_mulqv(CPUAlphaState *env, uint64_t op1, uint64_t op2)
-{
-uint64_t tl, th;
-
-muls64(tl, th, op1, op2);
-/* If th != 0 th != -1, then we had an overflow */
-if (unlikely((th + 1) 1)) {
-arith_excp(env, GETPC(), EXC_M_IOV, 0);
-}
-return tl;
}
diff --git a/target-alpha/translate.c b/target-alpha/translate.c
index 183573d..6ea33f3 100644
--- a/target-alpha/translate.c
+++ b/target-alpha/translate.c
@@ -1377,7 +1377,7 @@ static ExitStatus translate_one(DisasContext *ctx,
uint32_t insn)
uint16_t fn11;
uint8_t opc, ra, rb, rc, fpfn, fn7, lit;
bool islit;
-TCGv va, vb, vc, tmp;
+TCGv va, vb, vc, tmp, tmp2;
TCGv_i32 t32;
ExitStatus ret;
@@ -1589,11 +1589,23 @@ static ExitStatus translate_one(DisasContext *ctx,
uint32_t insn)
break;
case 0x40:
/* ADDL/V */
-gen_helper_addlv(vc, cpu_env, va, vb);
+tmp = tcg_temp_new();
+tcg_gen_ext32s_i64(tmp, va);
+tcg_gen_ext32s_i64(vc, vb);
+tcg_gen_add_i64(tmp, tmp, vc);
+tcg_gen_ext32s_i64(vc, tmp);
+gen_helper_check_overflow(cpu_env, vc, tmp);
+tcg_temp_free(tmp);
break;
case 0x49:
/* SUBL/V */
-gen_helper_sublv(vc, cpu_env, va, vb);
+tmp = tcg_temp_new();
+tcg_gen_ext32s_i64(tmp, va);
+tcg_gen_ext32s_i64(vc, vb);
+tcg_gen_sub_i64(tmp, tmp, vc);
+tcg_gen_ext32s_i64(vc, tmp);
+gen_helper_check_overflow(cpu_env, vc, tmp);
+tcg_temp_free(tmp);
break;
case 0x4D:
/* CMPLT */
@@ -1601,11 +1613,33 @@ static ExitStatus translate_one(DisasContext *ctx,
uint32_t insn)
break;
case 0x60:
/* ADDQ/V */
-gen_helper_addqv(vc, cpu_env, va, vb);
+tmp = tcg_temp_new();
+
Re: [Qemu-devel] [RFC PATCH v2] spapr: Enable use of huge pages
On 07/10/2014 08:29 PM, Alexander Graf wrote:
On 09.07.14 15:59, Alexey Kardashevskiy wrote:
On 07/09/2014 05:46 PM, Paolo Bonzini wrote: Il 09/07/2014 07:57, Alexey
Kardashevskiy ha scritto:
0b183fc87 memory: move mem_path handling to
memory_region_allocate_system_memory disabled -mempath use for all
machines that do not use memory_region_allocate_system_memory() to
register RAM. Since SPAPR uses memory_region_init_ram(), the huge pages
support was disabled for it.
This replaces memory_region_init_ram()+vmstate_register_ram_global() with
memory_region_allocate_system_memory() to get huge pages back.
Cc: Paolo Bonzini pbonz...@redhat.com
Cc: Hu Tao hu...@cn.fujitsu.com
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
hw/ppc/spapr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index a23c0f0..8fa9f7e 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -1337,8 +1337,8 @@ static void ppc_spapr_init(MachineState *machine)
ram_addr_t nonrma_base = rma_alloc_size;
ram_addr_t nonrma_size = spapr-ram_limit - rma_alloc_size;
-memory_region_init_ram(ram, NULL, ppc_spapr.ram, nonrma_size);
-vmstate_register_ram_global(ram);
+memory_region_allocate_system_memory(ram, NULL, ppc_spapr.ram,
+ nonrma_size);
The reason why I didn't do this in the simple way is that depending on the
value of nonrma_base you may get smaller hugepages than you wanted.
For example, if the hugepage size is 1G but nonrma_base is 32M, you will
not be able to get a page size larger than 32M.
Depending on the value of nonrma_base, it may be better to allocate the
whole spapr-ram_limit to ppc_spapr.ram, and just ignore the first part
of it.
I see in target-ppc/kvm.c that rma_alloc_size is capped to 256M, and in
practice it is 128M (arch/powerpc/kvm/book3s_hv_builtin.c. Considering
that Linux overcommits so the memory isn't lost in the non-hugepage case, I
think it's better to just waste the 128M of address space.
Paolo
memory_region_add_subregion(sysmem, nonrma_base, ram);
}
Did you mean something like below? If so, I have to change MR tree and
place RMA under RAM, I guess.
I'll try to give it a try tomorrow on bare PPC970.
---
hw/ppc/spapr.c | 19 ---
target-ppc/kvm.c | 9 +
target-ppc/kvm_ppc.h | 2 +-
3 files changed, 14 insertions(+), 16 deletions(-)
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index a23c0f0..47ae6c1 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -1223,6 +1223,7 @@ static void ppc_spapr_init(MachineState *machine)
int i;
MemoryRegion *sysmem = get_system_memory();
MemoryRegion *ram = g_new(MemoryRegion, 1);
+MemoryRegion *rma_region;
hwaddr rma_alloc_size;
hwaddr node0_size = (nb_numa_nodes 1) ? numa_info[0].node_mem :
ram_size;
uint32_t initrd_base = 0;
@@ -1230,6 +1231,7 @@ static void ppc_spapr_init(MachineState *machine)
long load_limit, rtas_limit, fw_size;
bool kernel_le = false;
char *filename;
+void *rma = NULL;
msi_supported = true;
@@ -1239,7 +1241,7 @@ static void ppc_spapr_init(MachineState *machine)
cpu_ppc_hypercall = emulate_spapr_hypercall;
/* Allocate RMA if necessary */
-rma_alloc_size = kvmppc_alloc_rma(ppc_spapr.rma, sysmem);
+rma_alloc_size = kvmppc_alloc_rma(rma);
if (rma_alloc_size == -1) {
hw_error(qemu: Unable to create RMA\n);
@@ -1333,13 +1335,16 @@ static void ppc_spapr_init(MachineState *machine)
/* allocate RAM */
spapr-ram_limit = ram_size;
-if (spapr-ram_limit rma_alloc_size) {
-ram_addr_t nonrma_base = rma_alloc_size;
-ram_addr_t nonrma_size = spapr-ram_limit - rma_alloc_size;
+memory_region_allocate_system_memory(ram, NULL, ppc_spapr.ram,
+ spapr-ram_limit);
+memory_region_add_subregion(sysmem, 0, ram);
-memory_region_init_ram(ram, NULL, ppc_spapr.ram, nonrma_size);
-vmstate_register_ram_global(ram);
-memory_region_add_subregion(sysmem, nonrma_base, ram);
+if (rma_alloc_size rma) {
+rma_region = g_new(MemoryRegion, 1);
+memory_region_init_ram_ptr(rma_region, NULL, ppc_spapr.rma,
+ rma_alloc_size, rma);
+vmstate_register_ram_global(rma_region);
+memory_region_add_subregion(sysmem, 0, rma_region);
}
filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, spapr-rtas.bin);
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 995706a..9ca14d2 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -1582,13 +1582,11 @@ int kvmppc_smt_threads(void)
}
#ifdef TARGET_PPC64
-off_t kvmppc_alloc_rma(const char *name, MemoryRegion *sysmem)
+off_t kvmppc_alloc_rma(void **rma)
[Qemu-devel] [PATCH v2] ppc: memory: Replace memory_region_init_ram with memory_region_allocate_system_memory
Commit 0b183fc871:memory: move mem_path handling to memory_region_allocate_system_memory split memory_region_init_ram and memory_region_init_ram_from_file. Also it moved mem-path handling a step up from memory_region_init_ram to memory_region_allocate_system_memory. Therefore for any board that uses memory_region_init_ram directly, -mem-path is not supported. Fix this by replacing memory_region_init_ram with memory_region_allocate_system_memory. Signed-off-by: Shreyas B. Prabhu shre...@linux.vnet.ibm.com --- Changes in v2: Dropping changes from hw/ppc/spapr.c based on the comment. hw/ppc/e500.c | 3 +-- hw/ppc/mac_newworld.c | 7 +++ hw/ppc/mac_oldworld.c | 8 hw/ppc/ppc405_boards.c | 21 + hw/ppc/ppc405_uc.c | 5 +++-- hw/ppc/ppc4xx_devs.c | 5 +++-- hw/ppc/prep.c | 3 +-- hw/ppc/virtex_ml507.c | 3 +-- 8 files changed, 25 insertions(+), 30 deletions(-) diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c index bb2e75f..1a5b30d 100644 --- a/hw/ppc/e500.c +++ b/hw/ppc/e500.c @@ -701,8 +701,7 @@ void ppce500_init(MachineState *machine, PPCE500Params *params) machine-ram_size = ram_size; /* Register Memory */ -memory_region_init_ram(ram, NULL, mpc8544ds.ram, ram_size); -vmstate_register_ram_global(ram); +memory_region_allocate_system_memory(ram, NULL, mpc8544ds.ram, ram_size); memory_region_add_subregion(address_space_mem, 0, ram); dev = qdev_create(NULL, e500-ccsr); diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c index 89d3cad..7e97af4 100644 --- a/hw/ppc/mac_newworld.c +++ b/hw/ppc/mac_newworld.c @@ -200,13 +200,12 @@ static void ppc_core99_init(MachineState *machine) } /* allocate RAM */ -memory_region_init_ram(ram, NULL, ppc_core99.ram, ram_size); -vmstate_register_ram_global(ram); +memory_region_allocate_system_memory(ram, NULL, ppc_core99.ram, ram_size); memory_region_add_subregion(get_system_memory(), 0, ram); /* allocate and load BIOS */ -memory_region_init_ram(bios, NULL, ppc_core99.bios, BIOS_SIZE); -vmstate_register_ram_global(bios); +memory_region_allocate_system_memory(bios, NULL, ppc_core99.bios, + BIOS_SIZE); if (bios_name == NULL) bios_name = PROM_FILENAME; filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name); diff --git a/hw/ppc/mac_oldworld.c b/hw/ppc/mac_oldworld.c index 4b5e905..afae825 100644 --- a/hw/ppc/mac_oldworld.c +++ b/hw/ppc/mac_oldworld.c @@ -130,13 +130,13 @@ static void ppc_heathrow_init(MachineState *machine) exit(1); } -memory_region_init_ram(ram, NULL, ppc_heathrow.ram, ram_size); -vmstate_register_ram_global(ram); +memory_region_allocate_system_memory(ram, NULL, ppc_heathrow.ram, + ram_size); memory_region_add_subregion(sysmem, 0, ram); /* allocate and load BIOS */ -memory_region_init_ram(bios, NULL, ppc_heathrow.bios, BIOS_SIZE); -vmstate_register_ram_global(bios); +memory_region_allocate_system_memory(bios, NULL, ppc_heathrow.bios, + BIOS_SIZE); if (bios_name == NULL) bios_name = PROM_FILENAME; filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name); diff --git a/hw/ppc/ppc405_boards.c b/hw/ppc/ppc405_boards.c index 98ad2d7..6b566cd 100644 --- a/hw/ppc/ppc405_boards.c +++ b/hw/ppc/ppc405_boards.c @@ -199,8 +199,8 @@ static void ref405ep_init(MachineState *machine) MemoryRegion *sysmem = get_system_memory(); /* XXX: fix this */ -memory_region_init_ram(ram_memories[0], NULL, ef405ep.ram, 0x0800); -vmstate_register_ram_global(ram_memories[0]); +memory_region_allocate_system_memory(ram_memories[0], NULL, ef405ep.ram, + 0x0800); ram_bases[0] = 0; ram_sizes[0] = 0x0800; memory_region_init(ram_memories[1], NULL, ef405ep.ram1, 0); @@ -214,8 +214,7 @@ static void ref405ep_init(MachineState *machine) , pic, kernel_filename == NULL ? 0 : 1); /* allocate SRAM */ sram_size = 512 * 1024; -memory_region_init_ram(sram, NULL, ef405ep.sram, sram_size); -vmstate_register_ram_global(sram); +memory_region_allocate_system_memory(sram, NULL, ef405ep.sram, sram_size); memory_region_add_subregion(sysmem, 0xFFF0, sram); /* allocate and load BIOS */ #ifdef DEBUG_BOARD_INIT @@ -246,8 +245,8 @@ static void ref405ep_init(MachineState *machine) printf(Load BIOS from file\n); #endif bios = g_new(MemoryRegion, 1); -memory_region_init_ram(bios, NULL, ef405ep.bios, BIOS_SIZE); -vmstate_register_ram_global(bios); +memory_region_allocate_system_memory(bios, NULL, ef405ep.bios, + BIOS_SIZE); if (bios_name == NULL) bios_name = BIOS_FILENAME; filename =
Re: [Qemu-devel] [PATCH v2] ppc: memory: Replace memory_region_init_ram with memory_region_allocate_system_memory
On 10.07.14 14:01, Shreyas B. Prabhu wrote: Commit 0b183fc871:memory: move mem_path handling to memory_region_allocate_system_memory split memory_region_init_ram and memory_region_init_ram_from_file. Also it moved mem-path handling a step up from memory_region_init_ram to memory_region_allocate_system_memory. Therefore for any board that uses memory_region_init_ram directly, -mem-path is not supported. Fix this by replacing memory_region_init_ram with memory_region_allocate_system_memory. Signed-off-by: Shreyas B. Prabhu shre...@linux.vnet.ibm.com Thanks, applied to ppc-next (for 2.1 - it's a regression after all). Alex
[Qemu-devel] [PATCH 011/156] configure: Don't use __int128_t for clang versions before 3.2
From: Stefan Weil s...@weilnetz.de
Those versions don't fully support __int128_t.
Cc: qemu-sta...@nongnu.org
Signed-off-by: Stefan Weil s...@weilnetz.de
Signed-off-by: Michael Tokarev m...@tls.msk.ru
(cherry picked from commit a00f66ab9b3021e781695a73c579b6292501ab37)
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
configure | 5 +
1 file changed, 5 insertions(+)
diff --git a/configure b/configure
index 3cbcea1..c0882dc 100755
--- a/configure
+++ b/configure
@@ -3520,6 +3520,11 @@ fi
int128=no
cat $TMPC EOF
+#if defined(__clang_major__) defined(__clang_minor__)
+# if ((__clang_major__ 3) || (__clang_major__ == 3) (__clang_minor__ 2))
+# error __int128_t does not work in CLANG before 3.2
+# endif
+#endif
__int128_t a;
__uint128_t b;
int main (void) {
--
1.9.1
Re: [Qemu-devel] [PATCH v2] ppc: memory: Replace memory_region_init_ram with memory_region_allocate_system_memory
On Thursday 10 July 2014 05:34 PM, Alexander Graf wrote: On 10.07.14 14:01, Shreyas B. Prabhu wrote: Commit 0b183fc871:memory: move mem_path handling to memory_region_allocate_system_memory split memory_region_init_ram and memory_region_init_ram_from_file. Also it moved mem-path handling a step up from memory_region_init_ram to memory_region_allocate_system_memory. Therefore for any board that uses memory_region_init_ram directly, -mem-path is not supported. Fix this by replacing memory_region_init_ram with memory_region_allocate_system_memory. Signed-off-by: Shreyas B. Prabhu shre...@linux.vnet.ibm.com Thanks, applied to ppc-next (for 2.1 - it's a regression after all). Thanks! Alex
[Qemu-devel] [PATCH 151/156] nbd: Shutdown socket before closing.
From: Hani Benhabiles kroo...@gmail.com
This forces finishing data sending to client before closing the socket like in
exports listing or replying with NBD_REP_ERR_UNSUP cases.
Signed-off-by: Hani Benhabiles kroo...@gmail.com
Cc: qemu-sta...@nongnu.org
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
(cherry picked from commit 27e5eae4577316f7e86a56eb7363d4e78f79e3e5)
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
blockdev-nbd.c | 1 +
qemu-nbd.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/blockdev-nbd.c b/blockdev-nbd.c
index 18dc528..b3a2474 100644
--- a/blockdev-nbd.c
+++ b/blockdev-nbd.c
@@ -28,6 +28,7 @@ static void nbd_accept(void *opaque)
int fd = accept(server_fd, (struct sockaddr *)addr, addr_len);
if (fd = 0 !nbd_client_new(NULL, fd, nbd_client_put)) {
+shutdown(fd, 2);
close(fd);
}
}
diff --git a/qemu-nbd.c b/qemu-nbd.c
index 7a2cff9..474966f 100644
--- a/qemu-nbd.c
+++ b/qemu-nbd.c
@@ -302,6 +302,7 @@ static void nbd_accept(void *opaque)
if (nbd_client_new(exp, fd, nbd_client_closed)) {
nb_fds++;
} else {
+shutdown(fd, 2);
close(fd);
}
}
--
1.9.1
Re: [Qemu-devel] [PATCH v5 00/12] KVM Support for MIPS32 Processors
On 17 June 2014 23:10, James Hogan james.ho...@imgtec.com wrote: The patchset depends on v4 of target-mips: implement UserLocal Register. I'm aiming for QEMU 2.1, hopefully it isn't too late to get some final review. Thanks to everybody who has already taken part in review. This patchset implements KVM support for MIPS32 processors, using Trap Emulation. I was looking at what happens for MMIO accesses to nonexistent memory when we're running under KVM, and interestingly this patchset means MIPS is now the only CPU which both (a) supports KVM and (b) has an implementation of the do_unassigned_access() CPU hook. Does the current code support a guest attempt to access unassigned physical addresses? I had a look at the code and it seems like mips_cpu_unassigned_access() will end up calling cpu_restore_state() and cpu_loop_exit(), which I think will probably crash if you call them when using KVM rather than TCG... More generally, there doesn't really seem to be provision in the KVM KVM_EXIT_MMIO API for returning this access failed. I guess in theory userspace could do all the figure out how to adjust CPU state to do exception entry and then run VCPU, but that seems like quite a lot of work which the kernel already knows how to do; is there some way to provide a simpler API that lets userspace just inform the kernel that it needs to fault the access? thanks -- PMM
[Qemu-devel] [PATCH 049/156] ssi-sd: fix buffer overrun on invalid state load
From: Michael S. Tsirkin m...@redhat.com
CVE-2013-4537
s-arglen is taken from wire and used as idx
in ssi_sd_transfer().
Validate it before access.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Signed-off-by: Juan Quintela quint...@redhat.com
(cherry picked from commit a9c380db3b8c6af19546a68145c8d1438a09c92b)
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
hw/sd/ssi-sd.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/hw/sd/ssi-sd.c b/hw/sd/ssi-sd.c
index 1bb56c4..90ff07b 100644
--- a/hw/sd/ssi-sd.c
+++ b/hw/sd/ssi-sd.c
@@ -230,8 +230,17 @@ static int ssi_sd_load(QEMUFile *f, void *opaque, int
version_id)
for (i = 0; i 5; i++)
s-response[i] = qemu_get_be32(f);
s-arglen = qemu_get_be32(f);
+if (s-mode == SSI_SD_CMDARG
+(s-arglen 0 || s-arglen = ARRAY_SIZE(s-cmdarg))) {
+return -EINVAL;
+}
s-response_pos = qemu_get_be32(f);
s-stopping = qemu_get_be32(f);
+if (s-mode == SSI_SD_RESPONSE
+(s-response_pos 0 || s-response_pos = ARRAY_SIZE(s-response) ||
+(!s-stopping s-arglen ARRAY_SIZE(s-response {
+return -EINVAL;
+}
ss-cs = qemu_get_be32(f);
--
1.9.1
Re: [Qemu-devel] [PATCH] ppc: memory: Replace memory_region_init_ram with memory_region_allocate_system_memory
On 10.07.14 09:01, Shreyas B. Prabhu wrote: Commit 0b183fc871:memory: move mem_path handling to memory_region_allocate_system_memory split memory_region_init_ram and memory_region_init_ram_from_file. Also it moved mem-path handling a step up from memory_region_init_ram to memory_region_allocate_system_memory. Therefore for any board that uses memory_region_init_ram directly, -mem-path is not supported. Fix this by replacing memory_region_init_ram with memory_region_allocate_system_memory. Signed-off-by: Shreyas B. Prabhu shre...@linux.vnet.ibm.com It think it's reasonable to do this for all targets, except for spapr where Alexey is already working on a bigger patch. Could you please remove the spapr change so I can apply the rest to ppc-next already? Alex
[Qemu-devel] [PULL for-2.1 04/22] block: drop aio functions that operate on the main AioContext
From: Paolo Bonzini pbonz...@redhat.com
The main AioContext should be accessed explicitly via qemu_get_aio_context().
Most of the time, using it is not the right thing to do.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
aio-posix.c | 4 ++--
aio-win32.c | 6 +++---
include/block/aio.h | 17 ++---
include/block/blockjob.h | 4 ++--
include/block/coroutine.h | 2 +-
main-loop.c | 21 -
tests/test-thread-pool.c | 4 ++--
7 files changed, 12 insertions(+), 46 deletions(-)
diff --git a/aio-posix.c b/aio-posix.c
index f921d4f..44c4df3 100644
--- a/aio-posix.c
+++ b/aio-posix.c
@@ -125,7 +125,7 @@ static bool aio_dispatch(AioContext *ctx)
bool progress = false;
/*
- * We have to walk very carefully in case qemu_aio_set_fd_handler is
+ * We have to walk very carefully in case aio_set_fd_handler is
* called while we're walking.
*/
node = QLIST_FIRST(ctx-aio_handlers);
@@ -183,7 +183,7 @@ bool aio_poll(AioContext *ctx, bool blocking)
/*
* If there are callbacks left that have been queued, we need to call them.
* Do not call select in this case, because it is possible that the caller
- * does not need a complete flush (as is the case for qemu_aio_wait loops).
+ * does not need a complete flush (as is the case for aio_poll loops).
*/
if (aio_bh_poll(ctx)) {
blocking = false;
diff --git a/aio-win32.c b/aio-win32.c
index 23f4e5b..c12f61e 100644
--- a/aio-win32.c
+++ b/aio-win32.c
@@ -102,7 +102,7 @@ bool aio_poll(AioContext *ctx, bool blocking)
/*
* If there are callbacks left that have been queued, we need to call then.
* Do not call select in this case, because it is possible that the caller
- * does not need a complete flush (as is the case for qemu_aio_wait loops).
+ * does not need a complete flush (as is the case for aio_poll loops).
*/
if (aio_bh_poll(ctx)) {
blocking = false;
@@ -115,7 +115,7 @@ bool aio_poll(AioContext *ctx, bool blocking)
/*
* Then dispatch any pending callbacks from the GSource.
*
- * We have to walk very carefully in case qemu_aio_set_fd_handler is
+ * We have to walk very carefully in case aio_set_fd_handler is
* called while we're walking.
*/
node = QLIST_FIRST(ctx-aio_handlers);
@@ -177,7 +177,7 @@ bool aio_poll(AioContext *ctx, bool blocking)
blocking = false;
/* we have to walk very carefully in case
- * qemu_aio_set_fd_handler is called while we're walking */
+ * aio_set_fd_handler is called while we're walking */
node = QLIST_FIRST(ctx-aio_handlers);
while (node) {
AioHandler *tmp;
diff --git a/include/block/aio.h b/include/block/aio.h
index a92511b..d81250c 100644
--- a/include/block/aio.h
+++ b/include/block/aio.h
@@ -220,7 +220,7 @@ bool aio_poll(AioContext *ctx, bool blocking);
#ifdef CONFIG_POSIX
/* Register a file descriptor and associated callbacks. Behaves very similarly
* to qemu_set_fd_handler2. Unlike qemu_set_fd_handler2, these callbacks will
- * be invoked when using qemu_aio_wait().
+ * be invoked when using aio_poll().
*
* Code that invokes AIO completion functions should rely on this function
* instead of qemu_set_fd_handler[2].
@@ -234,7 +234,7 @@ void aio_set_fd_handler(AioContext *ctx,
/* Register an event notifier and associated callbacks. Behaves very similarly
* to event_notifier_set_handler. Unlike event_notifier_set_handler, these
callbacks
- * will be invoked when using qemu_aio_wait().
+ * will be invoked when using aio_poll().
*
* Code that invokes AIO completion functions should rely on this function
* instead of event_notifier_set_handler.
@@ -251,19 +251,6 @@ GSource *aio_get_g_source(AioContext *ctx);
/* Return the ThreadPool bound to this AioContext */
struct ThreadPool *aio_get_thread_pool(AioContext *ctx);
-/* Functions to operate on the main QEMU AioContext. */
-
-bool qemu_aio_wait(void);
-void qemu_aio_set_event_notifier(EventNotifier *notifier,
- EventNotifierHandler *io_read);
-
-#ifdef CONFIG_POSIX
-void qemu_aio_set_fd_handler(int fd,
- IOHandler *io_read,
- IOHandler *io_write,
- void *opaque);
-#endif
-
/**
* aio_timer_new:
* @ctx: the aio context
diff --git a/include/block/blockjob.h b/include/block/blockjob.h
index f3cf63f..60aa835 100644
--- a/include/block/blockjob.h
+++ b/include/block/blockjob.h
@@ -74,7 +74,7 @@ struct BlockJob {
* Set to true if the job should cancel itself. The flag must
* always be tested just before toggling the busy flag from false
* to true. After a job has been cancelled, it should only yield
- * if #qemu_aio_wait will (sooner or later) reenter the coroutine.
+ *
[Qemu-devel] [PULL for-2.1 03/22] block: prefer aio_poll to qemu_aio_wait
From: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block.c| 2 +-
blockjob.c | 2 +-
qemu-io-cmds.c | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/block.c b/block.c
index c9629a4..510430d 100644
--- a/block.c
+++ b/block.c
@@ -471,7 +471,7 @@ int bdrv_create(BlockDriver *drv, const char* filename,
co = qemu_coroutine_create(bdrv_create_co_entry);
qemu_coroutine_enter(co, cco);
while (cco.ret == NOT_DONE) {
-qemu_aio_wait();
+aio_poll(qemu_get_aio_context(), true);
}
}
diff --git a/blockjob.c b/blockjob.c
index 67a64ea..ca0b4e2 100644
--- a/blockjob.c
+++ b/blockjob.c
@@ -187,7 +187,7 @@ int block_job_cancel_sync(BlockJob *job)
job-opaque = data;
block_job_cancel(job);
while (data.ret == -EINPROGRESS) {
-qemu_aio_wait();
+aio_poll(bdrv_get_aio_context(bs), true);
}
return (data.cancelled data.ret == 0) ? -ECANCELED : data.ret;
}
diff --git a/qemu-io-cmds.c b/qemu-io-cmds.c
index 60c1ceb..c503fc6 100644
--- a/qemu-io-cmds.c
+++ b/qemu-io-cmds.c
@@ -483,7 +483,7 @@ static int do_co_write_zeroes(BlockDriverState *bs, int64_t
offset, int count,
co = qemu_coroutine_create(co_write_zeroes_entry);
qemu_coroutine_enter(co, data);
while (!data.done) {
-qemu_aio_wait();
+aio_poll(bdrv_get_aio_context(bs), true);
}
if (data.ret 0) {
return data.ret;
@@ -2027,7 +2027,7 @@ static const cmdinfo_t resume_cmd = {
static int wait_break_f(BlockDriverState *bs, int argc, char **argv)
{
while (!bdrv_debug_is_suspended(bs, argv[1])) {
-qemu_aio_wait();
+aio_poll(bdrv_get_aio_context(bs), true);
}
return 0;
--
1.8.3.1
[Qemu-devel] [PULL for-2.1 01/22] block/backup: Fix hang for unaligned image size
When doing a block backup of an image with an unaligned size (with
respect to the BACKUP_CLUSTER_SIZE), qemu would check the allocation
status of sectors after the end of the image. bdrv_is_allocated()
returns a result that is valid for 0 sectors in this case, so the backup
job ran into an endless loop.
Stop looping when seeing a result valid for 0 sectors, we're at EOF then.
The test case looks somewhat unrelated at first sight because I
originally tried to reproduce a different suspected bug that turned out
to not exist. Still a good test case and it accidentally found this one.
Signed-off-by: Kevin Wolf kw...@redhat.com
Reviewed-by: Eric Blake ebl...@redhat.com
---
block/backup.c | 2 +-
tests/qemu-iotests/028 | 27 -
tests/qemu-iotests/028.out | 269 +
3 files changed, 296 insertions(+), 2 deletions(-)
diff --git a/block/backup.c b/block/backup.c
index 7978ae2..d0b0225 100644
--- a/block/backup.c
+++ b/block/backup.c
@@ -307,7 +307,7 @@ static void coroutine_fn backup_run(void *opaque)
BACKUP_SECTORS_PER_CLUSTER - i, n);
i += n;
-if (alloced == 1) {
+if (alloced == 1 || n == 0) {
break;
}
}
diff --git a/tests/qemu-iotests/028 b/tests/qemu-iotests/028
index a99e4fa..d5718c5 100755
--- a/tests/qemu-iotests/028
+++ b/tests/qemu-iotests/028
@@ -33,7 +33,8 @@ status=1 # failure is the default!
_cleanup()
{
- _cleanup_test_img
+rm -f ${TEST_IMG}.copy
+_cleanup_test_img
}
trap _cleanup; exit \$status 0 1 2 3 15
@@ -41,6 +42,7 @@ trap _cleanup; exit \$status 0 1 2 3 15
. ./common.rc
. ./common.filter
. ./common.pattern
+. ./common.qemu
# Any format supporting backing files except vmdk and qcow which do not support
# smaller backing files.
@@ -99,6 +101,29 @@ _check_test_img
# Rebase it on top of its base image
$QEMU_IMG rebase -b $TEST_IMG.base $TEST_IMG
+echo
+echo block-backup
+echo
+
+qemu_comm_method=monitor
+_launch_qemu -drive file=${TEST_IMG},cache=${CACHEMODE},id=disk
+h=$QEMU_HANDLE
+QEMU_COMM_TIMEOUT=1
+
+_send_qemu_cmd $h drive_backup disk ${TEST_IMG}.copy (qemu)
+qemu_cmd_repeat=20 _send_qemu_cmd $h info block-jobs No active jobs
+_send_qemu_cmd $h 'quit'
+
+# Base image sectors
+TEST_IMG=${TEST_IMG}.copy io readv $(( offset )) 512 1024 32
+
+# Image sectors
+TEST_IMG=${TEST_IMG}.copy io readv $(( offset + 512 )) 512 1024 64
+
+# Zero sectors beyond end of base image
+TEST_IMG=${TEST_IMG}.copy io_zero readv $(( offset + 32 * 1024 )) 512 1024 32
+
+
_check_test_img
# success, all done
diff --git a/tests/qemu-iotests/028.out b/tests/qemu-iotests/028.out
index 8affb7f..38099e4 100644
--- a/tests/qemu-iotests/028.out
+++ b/tests/qemu-iotests/028.out
@@ -465,5 +465,274 @@ read 512/512 bytes at offset 3221257728
read 512/512 bytes at offset 3221258752
512 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
No errors were found on the image.
+
+block-backup
+
+QEMU X.Y.Z monitor - type 'help' for more information
+(qemu)
d[K[Ddr[K[D[Ddri[K[D[D[Ddriv[K[D[D[D[Ddrive[K[D[D[D[D[Ddrive_[K[D[D[D[D[D[Ddrive_b[K[D[D[D[D[D[D[Ddrive_ba[K[D[D[D[D[D[D[D[Ddrive_bac[K[D[D[D[D[D[D[D[D[Ddrive_back[K[D[D[D[D[D[D[D[D[D[Ddrive_backu[K[D[D[D[D[D[D[D[D[D[D[Ddrive_backup[K[D[D[D[D[D[D[D[D[D[D[D[Ddrive_backup
[K[D[D[D[D[D[D[D[D[D[D[D[D[Ddrive_backup
d[K[D[D[D[D[D[D[D[D[D[D[D[D[D[Ddrive_backup
di[K[D[D[D[D[D[D[D[D[D[D[D[D[D[D[Ddrive_backup
dis[K[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[Ddrive_backup
disk[K[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[Ddrive_backup disk
[K[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[Ddrive_backup disk
/[K[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[Ddrive_backup disk
/h[K[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[Ddrive_backup
disk /ho[K[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D!
[D[Ddrive_backup disk
/hom[K[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[Ddrive_backup
disk
/home[K[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[Ddrive_backup
disk
/home/[K[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[Ddrive_backup
disk
/home/k[K[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[Ddrive_backup
disk
/home/kw[K[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[Ddrive_backup
disk
/home/kwo[K[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[Ddrive_backup
disk
/home/kwol[K[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[Ddrive_backup
disk
Re: [Qemu-devel] [PATCH] target-ppc: Fix number of threads per core limit
On 09.07.14 16:40, Alexey Kardashevskiy wrote: The number of threads per core is different for POWER6/7/8 CPUs. Guest systems do not expect to see more threads per core than a specific CPU supports so we need to limit this number. This limit is implemented by ppc_get_compat_smt_threads(). However it has a problem as it checks for PCR (Processor Compatibility Register) mask, 2.05 means 2 threads per core, 2.06 - 4 threads. For POWER8 one would expect PCR_COMPAT_2_07 bit set and ppc_get_compat_smt_threads() checking for it to return 8 threads per core. But the latest PowerISA spec now is 2.07 and there is no 2.07 compatibility mode defined, QEMU does not define it either (will be in PowerISA 2.08). Instead of relying on a PCR mask, this uses kvmppc_smt_threads() which returns the maximum supported threads number for KVM or 1 for TCG. Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru Thanks, applied to ppc-next (for 2.1). Alex
[Qemu-devel] [PATCH 128/156] block/vvfat: Plug memory leak in read_directory()
From: Markus Armbruster arm...@redhat.com
Has always been leaky. Spotted by Coverity.
Signed-off-by: Markus Armbruster arm...@redhat.com
Reviewed-by: Benoit Canet ben...@irqsave.net
Signed-off-by: Kevin Wolf kw...@redhat.com
(cherry picked from commit b122c3b6d020e529b203836efb8f611ece787293)
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
block/vvfat.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/block/vvfat.c b/block/vvfat.c
index e71d71e..e9e4fad 100644
--- a/block/vvfat.c
+++ b/block/vvfat.c
@@ -788,7 +788,9 @@ static int read_directory(BDRVVVFATState* s, int
mapping_index)
s-current_mapping-path=buffer;
s-current_mapping-read_only =
(st.st_mode (S_IWUSR | S_IWGRP | S_IWOTH)) == 0;
- }
+} else {
+g_free(buffer);
+}
}
closedir(dir);
--
1.9.1
[Qemu-devel] [PULL for-2.1 11/22] virtio-blk: avoid dataplane VirtIOBlockReq early free
From: Stefan Hajnoczi stefa...@redhat.com VirtIOBlockReq is freed later by virtio_blk_free_request() in hw/block/virtio-blk.c. Remove this extraneous g_slice_free(). This patch fixes the following segfault: 0x556373af in virtio_blk_rw_complete (opaque=0x565ff5e0, ret=0) at hw/block/virtio-blk.c:99 99 bdrv_acct_done(req-dev-bs, req-acct); (gdb) print req $1 = (VirtIOBlockReq *) 0x565ff5e0 (gdb) print req-dev $2 = (VirtIOBlock *) 0x0 (gdb) bt #0 0x556373af in virtio_blk_rw_complete (opaque=0x565ff5e0, ret=0) at hw/block/virtio-blk.c:99 #1 0x55840ebe in bdrv_co_em_bh (opaque=0x566152d0) at block.c:4675 #2 0x5583de77 in aio_bh_poll (ctx=ctx@entry=0x563a8150) at async.c:81 #3 0x5584b7a7 in aio_poll (ctx=0x563a8150, blocking=blocking@entry=true) at aio-posix.c:188 #4 0x556e520e in iothread_run (opaque=0x563a7fd8) at iothread.c:41 #5 0x742ba124 in start_thread () from /usr/lib/libpthread.so.0 #6 0x716d14bd in clone () from /usr/lib/libc.so.6 Reported-by: Max Reitz mre...@redhat.com Cc: Fam Zheng f...@redhat.com Signed-off-by: Stefan Hajnoczi stefa...@redhat.com Tested-by: Christian Borntraeger borntrae...@de.ibm.com Signed-off-by: Kevin Wolf kw...@redhat.com --- hw/block/dataplane/virtio-blk.c | 1 - 1 file changed, 1 deletion(-) diff --git a/hw/block/dataplane/virtio-blk.c b/hw/block/dataplane/virtio-blk.c index 4bc0729..bed9f13 100644 --- a/hw/block/dataplane/virtio-blk.c +++ b/hw/block/dataplane/virtio-blk.c @@ -68,7 +68,6 @@ static void complete_request_vring(VirtIOBlockReq *req, unsigned char status) vring_push(req-dev-dataplane-vring, req-elem, req-qiov.size + sizeof(*req-in)); notify_guest(req-dev-dataplane); -g_slice_free(VirtIOBlockReq, req); } static void handle_notify(EventNotifier *e) -- 1.8.3.1
[Qemu-devel] [PULL for-2.1 08/22] qcow2: Make qiov match request size until backing file EOF
If a qcow2 image has a shorter backing file and a read request to
unallocated clusters goes across EOF of the backing file, the backing
file sees a shortened request and the rest is filled with zeros.
However, the original too long qiov was used with the shortened request.
This patch makes the qiov size match the request size, avoiding a
potential buffer overflow in raw-posix.
Signed-off-by: Kevin Wolf kw...@redhat.com
Reviewed-by: Max Reitz mre...@redhat.com
---
block/qcow2.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/block/qcow2.c b/block/qcow2.c
index 67e55c9..b0faa69 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -1020,11 +1020,20 @@ static coroutine_fn int qcow2_co_readv(BlockDriverState
*bs, int64_t sector_num,
n1 = qcow2_backing_read1(bs-backing_hd, hd_qiov,
sector_num, cur_nr_sectors);
if (n1 0) {
+QEMUIOVector local_qiov;
+
+qemu_iovec_init(local_qiov, hd_qiov.niov);
+qemu_iovec_concat(local_qiov, hd_qiov, 0,
+ n1 * BDRV_SECTOR_SIZE);
+
BLKDBG_EVENT(bs-file, BLKDBG_READ_BACKING_AIO);
qemu_co_mutex_unlock(s-lock);
ret = bdrv_co_readv(bs-backing_hd, sector_num,
-n1, hd_qiov);
+n1, local_qiov);
qemu_co_mutex_lock(s-lock);
+
+qemu_iovec_destroy(local_qiov);
+
if (ret 0) {
goto fail;
}
--
1.8.3.1
[Qemu-devel] [PULL for-2.1 15/22] AioContext: do not rely on aio_poll(ctx, true) result to end a loop
From: Paolo Bonzini pbonz...@redhat.com
Currently, whenever aio_poll(ctx, true) has completed all pending
work it returns true *and* the next call to aio_poll(ctx, true)
will not block.
This invariant has its roots in qemu_aio_flush()'s implementation
as while (qemu_aio_wait()) {}. However, qemu_aio_flush() does
not exist anymore and bdrv_drain_all() is implemented differently;
and this invariant is complicated to maintain and subtly different
from the return value of GMainLoop's g_main_context_iteration.
All calls to aio_poll(ctx, true) except one are guarded by a
while() loop checking for a request to be incomplete, or a
BlockDriverState to be idle. The one remaining call (in
iothread.c) uses this to delay the aio_context_release/acquire
pair until the AioContext is quiescent, however:
- we can do the same just by using non-blocking aio_poll,
similar to how vl.c invokes main_loop_wait
- it is buggy, because it does not ensure that the AioContext
is released between an aio_notify and the next time the
iothread goes to sleep. This leads to hangs when stopping
the dataplane thread.
In the end, these semantics are a bad match for the current
users of AioContext. So modify that one exception in iothread.c,
which also fixes the hangs, as well as the testcase so that
it use the same idiom as the actual QEMU code.
Reported-by: Christian Borntraeger borntrae...@de.ibm.com
Tested-by: Christian Borntraeger borntrae...@de.ibm.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
include/block/aio.h | 6 +++---
iothread.c | 5 -
tests/test-aio.c| 25 +
3 files changed, 20 insertions(+), 16 deletions(-)
diff --git a/include/block/aio.h b/include/block/aio.h
index 433e7ff..c23de3c 100644
--- a/include/block/aio.h
+++ b/include/block/aio.h
@@ -214,9 +214,9 @@ bool aio_pending(AioContext *ctx);
/* Progress in completing AIO work to occur. This can issue new pending
* aio as a result of executing I/O completion or bh callbacks.
*
- * If there is no pending AIO operation or completion (bottom half),
- * return false. If there are pending AIO operations of bottom halves,
- * return true.
+ * Return whether any progress was made by executing AIO or bottom half
+ * handlers. If @blocking == true, this should always be true except
+ * if someone called aio_notify.
*
* If there are no pending bottom halves, but there are pending AIO
* operations, it may not be possible to make any progress without
diff --git a/iothread.c b/iothread.c
index 1fbf9f1..d9403cf 100644
--- a/iothread.c
+++ b/iothread.c
@@ -30,6 +30,7 @@ typedef ObjectClass IOThreadClass;
static void *iothread_run(void *opaque)
{
IOThread *iothread = opaque;
+bool blocking;
qemu_mutex_lock(iothread-init_done_lock);
iothread-thread_id = qemu_get_thread_id();
@@ -38,8 +39,10 @@ static void *iothread_run(void *opaque)
while (!iothread-stopping) {
aio_context_acquire(iothread-ctx);
-while (!iothread-stopping aio_poll(iothread-ctx, true)) {
+blocking = true;
+while (!iothread-stopping aio_poll(iothread-ctx, blocking)) {
/* Progress was made, keep going */
+blocking = false;
}
aio_context_release(iothread-ctx);
}
diff --git a/tests/test-aio.c b/tests/test-aio.c
index 264dab9..4c40a49 100644
--- a/tests/test-aio.c
+++ b/tests/test-aio.c
@@ -24,14 +24,6 @@ typedef struct {
bool auto_set;
} EventNotifierTestData;
-/* Wait until there are no more BHs or AIO requests */
-static void wait_for_aio(void)
-{
-while (aio_poll(ctx, true)) {
-/* Do nothing */
-}
-}
-
/* Wait until event notifier becomes inactive */
static void wait_until_inactive(EventNotifierTestData *data)
{
@@ -204,7 +196,9 @@ static void test_bh_schedule10(void)
g_assert(aio_poll(ctx, true));
g_assert_cmpint(data.n, ==, 2);
-wait_for_aio();
+while (data.n 10) {
+aio_poll(ctx, true);
+}
g_assert_cmpint(data.n, ==, 10);
g_assert(!aio_poll(ctx, false));
@@ -252,7 +246,9 @@ static void test_bh_delete_from_cb(void)
qemu_bh_schedule(data1.bh);
g_assert_cmpint(data1.n, ==, 0);
-wait_for_aio();
+while (data1.n data1.max) {
+aio_poll(ctx, true);
+}
g_assert_cmpint(data1.n, ==, data1.max);
g_assert(data1.bh == NULL);
@@ -287,7 +283,12 @@ static void test_bh_delete_from_cb_many(void)
g_assert_cmpint(data4.n, ==, 1);
g_assert(data1.bh == NULL);
-wait_for_aio();
+while (data1.n data1.max ||
+ data2.n data2.max ||
+ data3.n data3.max ||
+ data4.n data4.max) {
+aio_poll(ctx, true);
+}
g_assert_cmpint(data1.n, ==, data1.max);
g_assert_cmpint(data2.n, ==, data2.max);
g_assert_cmpint(data3.n, ==, data3.max);
@@ -306,7 +307,7 @@ static void test_bh_flush(void)
qemu_bh_schedule(data.bh);
[Qemu-devel] [PULL for-2.1 16/22] tests: Fix unterminated string output visitor enum human string
From: Andreas Färber afaer...@suse.de
The buffer was being allocated of size string length plus two.
Around the string two quotes were being added, but no terminating NUL.
It was then compared using g_assert_cmpstr(), resulting in fairly random
assertion failures:
ERROR:tests/test-string-output-visitor.c:213:test_visitor_out_enum: assertion
failed (str == str_human): (\value1\ == \value1\\001EE\0171)
There is no g_assert_cmpnstr() counterpart, so use g_strdup_printf()
for safely assembling the string in the first place.
Cc: Hu Tao hu...@cn.fujitsu.com
Cc: Michael S. Tsirkin m...@redhat.com
Suggested-by: Eric Blake ebl...@redhat.com
Fixes: b4900c0 tests: add human format test for string output visitor
Signed-off-by: Andreas Färber afaer...@suse.de
Reviewed-by: Eric Blake ebl...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
tests/test-string-output-visitor.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/tests/test-string-output-visitor.c
b/tests/test-string-output-visitor.c
index e89e43c..101fb27 100644
--- a/tests/test-string-output-visitor.c
+++ b/tests/test-string-output-visitor.c
@@ -196,16 +196,11 @@ static void test_visitor_out_enum(TestOutputVisitorData
*data,
for (i = 0; i ENUM_ONE_MAX; i++) {
char *str_human;
-int len;
visit_type_EnumOne(data-ov, i, unused, err);
g_assert(!err);
-len = strlen(EnumOne_lookup[i]) + 2;
-str_human = g_malloc0(len);
-str_human[0] = '';
-strncpy(str_human + 1, EnumOne_lookup[i], strlen(EnumOne_lookup[i]));
-str_human[len - 1] = '';
+str_human = g_strdup_printf(\%s\, EnumOne_lookup[i]);
str = string_output_get_string(data-sov);
g_assert(str != NULL);
--
1.8.3.1
Re: [Qemu-devel] [PATCH v5 00/12] KVM Support for MIPS32 Processors
Il 10/07/2014 14:17, Peter Maydell ha scritto: More generally, there doesn't really seem to be provision in the KVM KVM_EXIT_MMIO API for returning this access failed. I guess in theory userspace could do all the figure out how to adjust CPU state to do exception entry and then run VCPU, but that seems like quite a lot of work which the kernel already knows how to do; is there some way to provide a simpler API that lets userspace just inform the kernel that it needs to fault the access? There are 3 free padding bytes in struct kvm_run's mmio field. It's possible to add a per-VM capability and have the kernel check one of these bytes when the capability is set. Paolo
Re: [Qemu-devel] [PATCH 00/46] Postcopy implementation
On 07/10/2014 05:29 AM, Dr. David Alan Gilbert wrote: * Paolo Bonzini (pbonz...@redhat.com) wrote: Il 07/07/2014 16:02, Dr. David Alan Gilbert ha scritto: Could you have instead a migrate_start_postcopy command, and leave the policy to management instead? Hmm; yes that is probably possible - although with the migration_set_parameter configuration you get the best of both worlds: 1) You can set the parameter to say a few seconds and let QEMU handle it 2) You can set the parameter really large, but (I need to check) you could drop the parameter later and then cause it to kick in. I also did it this way because it was similar to the way the auto-throttling mechanism. Auto-throttling doesn't let you configure when it kicks in (it doesn't even need support from the destination side). For postcopy you would still have a capability, like auto-throttling, just not the argument. The reason why I prefer a manual step from management, is because postcopy is a one-way street. Suppose a newer version of management software has started migration with postcopy configured, and then an older version is started. It is probably an invalid thing to do, but the confusion in the older version could be fatal and it's nice if there's an easy way to prevent it. Actually the 'migrate_start_postcopy' idea is growing on me; Eric is that also your preferred way of doing it? If we did this I'd: 1) Remove the migration_set_parameter code I added 2) and the x-postcopy_ram_start_time parameter 3) Add a new command migrate_start_postcopy that just sets a flag which is tested in the same place as I currently check the timeout. If it's issued after a migration has finished it doesn't fail because that would be racy. If issued before a migration starts that's OK as long as postcopy is enabled and means to start postcopy mode immediately. So to make sure I understand, the idea is that the management starts migration as normal, then after enough time has elapsed, issues a migrate_start_postcopy to tell qemu that it is okay to switch to postcopy at the next convenient opportunity? Is there any need for an event telling libvirt that enough pre-copy has occurred to make a postcopy worthwhile? And of course, I _still_ want an event for when normal precopy migration is ready (instead of the current solution of libvirt having to poll to track progress). But in answer to your question, yes, it sounds like adding a new command (actually, per QMP conventions it should probably be migrate-start-postcopy with dashes instead of underscore) for management to determine if/when to allow postcopy to kick in seems okay. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
[Qemu-devel] [PATCH 041/156] hw/pci/pcie_aer.c: fix buffer overruns on invalid state load
From: Michael S. Tsirkin m...@redhat.com
4) CVE-2013-4529
hw/pci/pcie_aer.cpcie aer log can overrun the buffer if log_num is
too large
There are two issues in this file:
1. log_max from remote can be larger than on local
then buffer will overrun with data coming from state file.
2. log_num can be larger then we get data corruption
again with an overflow but not adversary controlled.
Fix both issues.
Reported-by: Anthony Liguori anth...@codemonkey.ws
Reported-by: Michael S. Tsirkin m...@redhat.com
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Reviewed-by: Dr. David Alan Gilbert dgilb...@redhat.com
Signed-off-by: Juan Quintela quint...@redhat.com
(cherry picked from commit 5f691ff91d323b6f97c6600405a7f9dc115a0ad1)
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
hw/pci/pcie_aer.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/hw/pci/pcie_aer.c b/hw/pci/pcie_aer.c
index 991502e..535be2c 100644
--- a/hw/pci/pcie_aer.c
+++ b/hw/pci/pcie_aer.c
@@ -795,6 +795,13 @@ static const VMStateDescription vmstate_pcie_aer_err = {
}
};
+static bool pcie_aer_state_log_num_valid(void *opaque, int version_id)
+{
+PCIEAERLog *s = opaque;
+
+return s-log_num = s-log_max;
+}
+
const VMStateDescription vmstate_pcie_aer_log = {
.name = PCIE_AER_ERROR_LOG,
.version_id = 1,
@@ -802,7 +809,8 @@ const VMStateDescription vmstate_pcie_aer_log = {
.minimum_version_id_old = 1,
.fields = (VMStateField[]) {
VMSTATE_UINT16(log_num, PCIEAERLog),
-VMSTATE_UINT16(log_max, PCIEAERLog),
+VMSTATE_UINT16_EQUAL(log_max, PCIEAERLog),
+VMSTATE_VALIDATE(log_num = log_max, pcie_aer_state_log_num_valid),
VMSTATE_STRUCT_VARRAY_POINTER_UINT16(log, PCIEAERLog, log_num,
vmstate_pcie_aer_err, PCIEAERErr),
VMSTATE_END_OF_LIST()
--
1.9.1
Re: [Qemu-devel] [PATCH/RFC 0/5] s390x/kvm: track the logical cpu state in QEMU and propagate it to kvm
This is the qemu part of kernel series Let user space control the cpu states Christian Borntraeger (1): update linux headers with with cpustate changes David Hildenbrand (4): s390x/kvm: introduce proper states for s390 cpus s390x/kvm: proper use of the cpu states OPERATING and STOPPED s390x/kvm: test whether a cpu is STOPPED when checking has_work s390x/kvm: propagate s390 cpu state to kvm hw/s390x/ipl.c| 2 +- hw/s390x/s390-virtio.c| 32 -- linux-headers/linux/kvm.h | 7 ++- target-s390x/cpu.c| 106 +++--- target-s390x/cpu.h| 33 +-- target-s390x/helper.c | 11 ++--- target-s390x/kvm.c| 49 ++--- trace-events | 6 +++ 8 files changed, 179 insertions(+), 67 deletions(-) Looks good to me.
Re: [Qemu-devel] [PATCH/RFC 0/5] s390x/kvm: track the logical cpu state in QEMU and propagate it to kvm
This is the qemu part of kernel series Let user space control the cpu states Christian Borntraeger (1): update linux headers with with cpustate changes David Hildenbrand (4): s390x/kvm: introduce proper states for s390 cpus s390x/kvm: proper use of the cpu states OPERATING and STOPPED s390x/kvm: test whether a cpu is STOPPED when checking has_work s390x/kvm: propagate s390 cpu state to kvm hw/s390x/ipl.c| 2 +- hw/s390x/s390-virtio.c| 32 -- linux-headers/linux/kvm.h | 7 ++- target-s390x/cpu.c| 106 +++--- target-s390x/cpu.h| 33 +-- target-s390x/helper.c | 11 ++--- target-s390x/kvm.c| 49 ++--- trace-events | 6 +++ 8 files changed, 179 insertions(+), 67 deletions(-) Looks good to me
Re: [Qemu-devel] [PATCH/RFC 0/5] s390x/kvm: track the logical cpu state in QEMU and propagate it to kvm
This is the qemu part of kernel series Let user space control the cpu states Christian Borntraeger (1): update linux headers with with cpustate changes David Hildenbrand (4): s390x/kvm: introduce proper states for s390 cpus s390x/kvm: proper use of the cpu states OPERATING and STOPPED s390x/kvm: test whether a cpu is STOPPED when checking has_work s390x/kvm: propagate s390 cpu state to kvm hw/s390x/ipl.c| 2 +- hw/s390x/s390-virtio.c| 32 -- linux-headers/linux/kvm.h | 7 ++- target-s390x/cpu.c| 106 +++--- target-s390x/cpu.h| 33 +-- target-s390x/helper.c | 11 ++--- target-s390x/kvm.c| 49 ++--- trace-events | 6 +++ 8 files changed, 179 insertions(+), 67 deletions(-) Looks good to me -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html @all thought it was the final internal review :)
Re: [Qemu-devel] [PATCH 00/46] Postcopy implementation
* Eric Blake (ebl...@redhat.com) wrote: On 07/10/2014 05:29 AM, Dr. David Alan Gilbert wrote: * Paolo Bonzini (pbonz...@redhat.com) wrote: Il 07/07/2014 16:02, Dr. David Alan Gilbert ha scritto: Could you have instead a migrate_start_postcopy command, and leave the policy to management instead? Hmm; yes that is probably possible - although with the migration_set_parameter configuration you get the best of both worlds: 1) You can set the parameter to say a few seconds and let QEMU handle it 2) You can set the parameter really large, but (I need to check) you could drop the parameter later and then cause it to kick in. I also did it this way because it was similar to the way the auto-throttling mechanism. Auto-throttling doesn't let you configure when it kicks in (it doesn't even need support from the destination side). For postcopy you would still have a capability, like auto-throttling, just not the argument. The reason why I prefer a manual step from management, is because postcopy is a one-way street. Suppose a newer version of management software has started migration with postcopy configured, and then an older version is started. It is probably an invalid thing to do, but the confusion in the older version could be fatal and it's nice if there's an easy way to prevent it. Actually the 'migrate_start_postcopy' idea is growing on me; Eric is that also your preferred way of doing it? If we did this I'd: 1) Remove the migration_set_parameter code I added 2) and the x-postcopy_ram_start_time parameter 3) Add a new command migrate_start_postcopy that just sets a flag which is tested in the same place as I currently check the timeout. If it's issued after a migration has finished it doesn't fail because that would be racy. If issued before a migration starts that's OK as long as postcopy is enabled and means to start postcopy mode immediately. So to make sure I understand, the idea is that the management starts migration as normal, then after enough time has elapsed, issues a migrate_start_postcopy to tell qemu that it is okay to switch to postcopy at the next convenient opportunity? Yep, that's the idea. Is there any need for an event telling libvirt that enough pre-copy has occurred to make a postcopy worthwhile? I'm not sure that qemu knows much more than management does at that point; any such decision you can make based on an arbitrary cut off (i.e. migration is taking too long) or you could consider something based on some of the other stats that migration already exposes (like the dirty pages stats); if we've got any more stats that you need we can always expose them. And of course, I _still_ want an event for when normal precopy migration is ready (instead of the current solution of libvirt having to poll to track progress). Agreed; although we can just do that independently of this big patch set. But in answer to your question, yes, it sounds like adding a new command (actually, per QMP conventions it should probably be migrate-start-postcopy with dashes instead of underscore) for management to determine if/when to allow postcopy to kick in seems okay. OK, I'll do it. Dave -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
[Qemu-devel] [PATCH 1/6 v6] ppc: debug stub: Get trap instruction opcode from KVM
Get trap instruction opcode from KVM and this opcode will be used for setting software breakpoint in following patch Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com --- v5-v6 - no change target-ppc/kvm.c | 4 1 file changed, 4 insertions(+) diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c index 2d87108..4df23dd 100644 --- a/target-ppc/kvm.c +++ b/target-ppc/kvm.c @@ -72,6 +72,8 @@ static int cap_papr; static int cap_htab_fd; static int cap_fixup_hcalls; +static uint32_t debug_inst_opcode; + /* XXX We have a race condition where we actually have a level triggered * interrupt, but the infrastructure can't expose that yet, so the guest * takes but ignores it, goes to sleep and never gets notified that there's @@ -436,6 +438,8 @@ int kvm_arch_init_vcpu(CPUState *cs) break; } +kvm_get_one_reg(cs, KVM_REG_PPC_DEBUG_INST, debug_inst_opcode); + return ret; } -- 1.9.3
[Qemu-devel] [PATCH] scripts: qapi-event.py: support vendor extension
The event code generator barfs when it sees a dot in an event
argument, this makes it impossible to support vendor extensions
in event arguments as they always contain dots. Fix this by
replacing dots by hyphens in the generated code.
PS: Event names and QMP command arguments may suffer from the
same issue, but I'm not checking/fixing them today.
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
scripts/qapi-event.py | 8
scripts/qapi.py | 4
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/scripts/qapi-event.py b/scripts/qapi-event.py
index 601e307..485694b 100644
--- a/scripts/qapi-event.py
+++ b/scripts/qapi-event.py
@@ -23,11 +23,11 @@ def _generate_event_api_name(event_name, params):
if params:
for argname, argentry, optional, structured in parse_args(params):
if optional:
-api_name += bool has_%s,\n % c_var(argname)
+api_name += bool has_%s,\n % c_arg(argname)
api_name += .ljust(l)
api_name += %s %s,\n % (c_type(argentry, is_param=True),
- c_var(argname))
+ c_arg(argname))
api_name += .ljust(l)
api_name += Error **errp)
@@ -98,7 +98,7 @@ def generate_event_implement(api_name, event_name, params):
ret += mcgen(
if (has_%(var)s) {
,
- var = c_var(argname))
+ var = c_arg(argname))
push_indent()
if argentry == str:
@@ -113,7 +113,7 @@ def generate_event_implement(api_name, event_name, params):
}
,
var_type = var_type,
- var = c_var(argname),
+ var = c_arg(argname),
type = type_name(argentry),
name = argname)
diff --git a/scripts/qapi.py b/scripts/qapi.py
index f2c6d1f..ddab14d 100644
--- a/scripts/qapi.py
+++ b/scripts/qapi.py
@@ -434,6 +434,10 @@ def c_var(name, protect=True):
def c_fun(name, protect=True):
return c_var(name, protect).replace('.', '_')
+# Should be used where vendor extensions are supported
+def c_arg(name):
+ return c_var(name).replace('.', '_')
+
def c_list_type(name):
return '%sList' % name
--
1.9.3
Re: [Qemu-devel] [PATCH v6 1/5] block: Support Archipelago as a QEMU block backend
On 07/10/2014 01:04 PM, Chrysostomos Nanakos wrote: On 07/10/2014 03:23 AM, Jeff Cody wrote: On Fri, Jun 27, 2014 at 11:24:08AM +0300, Chrysostomos Nanakos wrote: VM Image on Archipelago volume is specified like this: file.driver=archipelago,file.volume=volumename[,file.mport=mapperd_port[, file.vport=vlmcd_port][,file.segment=segment_name]] 'archipelago' is the protocol. 'mport' is the port number on which mapperd is listening. This is optional and if not specified, QEMU will make Archipelago to use the default port. 'vport' is the port number on which vlmcd is listening. This is optional and if not specified, QEMU will make Archipelago to use the default port. 'segment' is the name of the shared memory segment Archipelago stack is using. This is optional and if not specified, QEMU will make Archipelago to use the default value, 'archipelago'. Examples: file.driver=archipelago,file.volume=my_vm_volume file.driver=archipelago,file.volume=my_vm_volume,file.mport=123 file.driver=archipelago,file.volume=my_vm_volume,file.mport=123, file.vport=1234 file.driver=archipelago,file.volume=my_vm_volume,file.mport=123, file.vport=1234,file.segment=my_segment Signed-off-by: Chrysostomos Nanakos cnana...@grnet.gr This is just a superficial review, because I don't have a good idea of what archipelago or libxseg really does (I didn't even compile it or these patches). But I scanned through this patch, and found a few things, and had a few questions. No worries, every review is more than welcome. --- MAINTAINERS |6 + block/Makefile.objs |2 + block/archipelago.c | 819 +++ configure | 40 +++ 4 files changed, 867 insertions(+) create mode 100644 block/archipelago.c diff --git a/MAINTAINERS b/MAINTAINERS index 9b93edd..58ef1e3 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -999,3 +999,9 @@ SSH M: Richard W.M. Jones rjo...@redhat.com S: Supported F: block/ssh.c + +ARCHIPELAGO +M: Chrysostomos Nanakos cnana...@grnet.gr +M: Chrysostomos Nanakos ch...@include.gr +S: Maintained +F: block/archipelago.c diff --git a/block/Makefile.objs b/block/Makefile.objs index fd88c03..858d2b3 100644 --- a/block/Makefile.objs +++ b/block/Makefile.objs @@ -17,6 +17,7 @@ block-obj-$(CONFIG_LIBNFS) += nfs.o block-obj-$(CONFIG_CURL) += curl.o block-obj-$(CONFIG_RBD) += rbd.o block-obj-$(CONFIG_GLUSTERFS) += gluster.o +block-obj-$(CONFIG_ARCHIPELAGO) += archipelago.o block-obj-$(CONFIG_LIBSSH2) += ssh.o endif @@ -35,5 +36,6 @@ gluster.o-cflags := $(GLUSTERFS_CFLAGS) gluster.o-libs := $(GLUSTERFS_LIBS) ssh.o-cflags := $(LIBSSH2_CFLAGS) ssh.o-libs := $(LIBSSH2_LIBS) +archipelago.o-libs := $(ARCHIPELAGO_LIBS) qcow.o-libs:= -lz linux-aio.o-libs := -laio diff --git a/block/archipelago.c b/block/archipelago.c new file mode 100644 index 000..c56826a --- /dev/null +++ b/block/archipelago.c @@ -0,0 +1,819 @@ +/* + * QEMU Block driver for Archipelago + * + * Copyright 2014 GRNET S.A. All rights reserved. + * + * Redistribution and use in source and binary forms, with or + * without modification, are permitted provided that the following + * conditions are met: + * + * 1. Redistributions of source code must retain the above + * copyright notice, this list of conditions and the following + * disclaimer. + * 2. Redistributions in binary form must reproduce the above + * copyright notice, this list of conditions and the following + * disclaimer in the documentation and/or other materials + * provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY GRNET S.A. ``AS IS'' AND ANY EXPRESS + * OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR + * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL GRNET S.A OR + * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF + * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED + * AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN + * ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE + * POSSIBILITY OF SUCH DAMAGE. + * + * The views and conclusions contained in the software and + * documentation are those of the authors and should not be + * interpreted as representing official policies, either expressed + * or implied, of GRNET S.A. + */ + +/* +* VM Image on Archipelago volume is specified like this: +* +* file.driver=archipelago,file.volume=volumename[,file.mport=mapperd_port[, +* file.vport=vlmcd_port][,file.segment=segment_name]] +* +* 'archipelago' is the protocol. +* +* 'mport' is the port number on which mapperd is listening. This is optional +* and if not specified, QEMU will
[Qemu-devel] [PATCH v3 4/4] virtio-blk: embed VirtQueueElement in VirtIOBlockReq
The memory allocation between hw/block/virtio-blk.c,
hw/block/dataplane/virtio-blk.c, and hw/virtio/dataplane/vring.c is
messy. Structs are allocated in different files than they are freed in.
This is risky and makes memory leaks easier.
Embed VirtQueueElement in VirtIOBlockReq to reduce the amount of memory
allocation we need to juggle. This also makes vring.c and virtio.c
slightly more similar.
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
---
hw/block/dataplane/virtio-blk.c | 29 +++
hw/block/virtio-blk.c | 46 ++---
hw/virtio/dataplane/vring.c | 17 +-
include/hw/virtio/dataplane/vring.h | 2 +-
include/hw/virtio/virtio-blk.h | 6 -
5 files changed, 48 insertions(+), 52 deletions(-)
diff --git a/hw/block/dataplane/virtio-blk.c b/hw/block/dataplane/virtio-blk.c
index bed9f13..227bb15 100644
--- a/hw/block/dataplane/virtio-blk.c
+++ b/hw/block/dataplane/virtio-blk.c
@@ -65,7 +65,7 @@ static void complete_request_vring(VirtIOBlockReq *req,
unsigned char status)
{
stb_p(req-in-status, status);
-vring_push(req-dev-dataplane-vring, req-elem,
+vring_push(req-dev-dataplane-vring, req-elem,
req-qiov.size + sizeof(*req-in));
notify_guest(req-dev-dataplane);
}
@@ -74,33 +74,32 @@ static void handle_notify(EventNotifier *e)
{
VirtIOBlockDataPlane *s = container_of(e, VirtIOBlockDataPlane,
host_notifier);
-
-VirtQueueElement *elem;
-VirtIOBlockReq *req;
-int ret;
-MultiReqBuffer mrb = {
-.num_writes = 0,
-};
+VirtIOBlock *vblk = VIRTIO_BLK(s-vdev);
event_notifier_test_and_clear(s-host_notifier);
bdrv_io_plug(s-blk-conf.bs);
for (;;) {
+MultiReqBuffer mrb = {
+.num_writes = 0,
+};
+int ret;
+
/* Disable guest-host notifies to avoid unnecessary vmexits */
vring_disable_notification(s-vdev, s-vring);
for (;;) {
-ret = vring_pop(s-vdev, s-vring, elem);
+VirtIOBlockReq *req = virtio_blk_alloc_request(vblk);
+
+ret = vring_pop(s-vdev, s-vring, req-elem);
if (ret 0) {
-assert(elem == NULL);
+virtio_blk_free_request(req);
break; /* no more requests */
}
-trace_virtio_blk_data_plane_process_request(s, elem-out_num,
-elem-in_num,
elem-index);
+trace_virtio_blk_data_plane_process_request(s, req-elem.out_num,
+req-elem.in_num,
+req-elem.index);
-req = g_slice_new(VirtIOBlockReq);
-req-dev = VIRTIO_BLK(s-vdev);
-req-elem = elem;
virtio_blk_handle_request(req, mrb);
}
diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
index b06a56d..02cd6b0 100644
--- a/hw/block/virtio-blk.c
+++ b/hw/block/virtio-blk.c
@@ -29,20 +29,18 @@
#include hw/virtio/virtio-bus.h
#include hw/virtio/virtio-access.h
-static VirtIOBlockReq *virtio_blk_alloc_request(VirtIOBlock *s)
+VirtIOBlockReq *virtio_blk_alloc_request(VirtIOBlock *s)
{
VirtIOBlockReq *req = g_slice_new(VirtIOBlockReq);
req-dev = s;
req-qiov.size = 0;
req-next = NULL;
-req-elem = g_slice_new(VirtQueueElement);
return req;
}
-static void virtio_blk_free_request(VirtIOBlockReq *req)
+void virtio_blk_free_request(VirtIOBlockReq *req)
{
if (req) {
-g_slice_free(VirtQueueElement, req-elem);
g_slice_free(VirtIOBlockReq, req);
}
}
@@ -56,7 +54,7 @@ static void virtio_blk_complete_request(VirtIOBlockReq *req,
trace_virtio_blk_req_complete(req, status);
stb_p(req-in-status, status);
-virtqueue_push(s-vq, req-elem, req-qiov.size + sizeof(*req-in));
+virtqueue_push(s-vq, req-elem, req-qiov.size + sizeof(*req-in));
virtio_notify(vdev, s-vq);
}
@@ -121,7 +119,7 @@ static VirtIOBlockReq *virtio_blk_get_request(VirtIOBlock
*s)
{
VirtIOBlockReq *req = virtio_blk_alloc_request(s);
-if (!virtqueue_pop(s-vq, req-elem)) {
+if (!virtqueue_pop(s-vq, req-elem)) {
virtio_blk_free_request(req);
return NULL;
}
@@ -254,7 +252,7 @@ static void virtio_blk_handle_scsi(VirtIOBlockReq *req)
{
int status;
-status = virtio_blk_handle_scsi_req(req-dev, req-elem);
+status = virtio_blk_handle_scsi_req(req-dev, req-elem);
virtio_blk_req_complete(req, status);
virtio_blk_free_request(req);
}
@@ -351,12 +349,12 @@ static void virtio_blk_handle_read(VirtIOBlockReq *req)
void virtio_blk_handle_request(VirtIOBlockReq *req, MultiReqBuffer *mrb)
{
uint32_t type;
-struct iovec *in_iov = req-elem-in_sg;
-struct iovec *iov = req-elem-out_sg;
-unsigned in_num = req-elem-in_num;
-
Re: [Qemu-devel] [PATCH 1/6 v6] ppc: debug stub: Get trap instruction opcode from KVM
On 10 July 2014 11:57, Bharat Bhushan bharat.bhus...@freescale.com wrote: Get trap instruction opcode from KVM and this opcode will be used for setting software breakpoint in following patch Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com --- v5-v6 - no change target-ppc/kvm.c | 4 1 file changed, 4 insertions(+) diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c index 2d87108..4df23dd 100644 --- a/target-ppc/kvm.c +++ b/target-ppc/kvm.c @@ -72,6 +72,8 @@ static int cap_papr; static int cap_htab_fd; static int cap_fixup_hcalls; +static uint32_t debug_inst_opcode; + /* XXX We have a race condition where we actually have a level triggered * interrupt, but the infrastructure can't expose that yet, so the guest * takes but ignores it, goes to sleep and never gets notified that there's @@ -436,6 +438,8 @@ int kvm_arch_init_vcpu(CPUState *cs) break; } +kvm_get_one_reg(cs, KVM_REG_PPC_DEBUG_INST, debug_inst_opcode); + Presumably the kernel guarantees that this is always the same value for every CPU in the system? thanks -- PMM
Re: [Qemu-devel] [PATCH] scripts: qapi-event.py: support vendor extension
Luiz Capitulino lcapitul...@redhat.com writes:
The event code generator barfs when it sees a dot in an event
argument, this makes it impossible to support vendor extensions
in event arguments as they always contain dots. Fix this by
replacing dots by hyphens in the generated code.
Code replaces by underbar, not hyphen.
PS: Event names and QMP command arguments may suffer from the
same issue, but I'm not checking/fixing them today.
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
scripts/qapi-event.py | 8
scripts/qapi.py | 4
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/scripts/qapi-event.py b/scripts/qapi-event.py
index 601e307..485694b 100644
--- a/scripts/qapi-event.py
+++ b/scripts/qapi-event.py
@@ -23,11 +23,11 @@ def _generate_event_api_name(event_name, params):
if params:
for argname, argentry, optional, structured in parse_args(params):
if optional:
-api_name += bool has_%s,\n % c_var(argname)
+api_name += bool has_%s,\n % c_arg(argname)
api_name += .ljust(l)
api_name += %s %s,\n % (c_type(argentry, is_param=True),
- c_var(argname))
+ c_arg(argname))
api_name += .ljust(l)
api_name += Error **errp)
@@ -98,7 +98,7 @@ def generate_event_implement(api_name, event_name, params):
ret += mcgen(
if (has_%(var)s) {
,
- var = c_var(argname))
+ var = c_arg(argname))
push_indent()
if argentry == str:
@@ -113,7 +113,7 @@ def generate_event_implement(api_name, event_name,
params):
}
,
var_type = var_type,
- var = c_var(argname),
+ var = c_arg(argname),
type = type_name(argentry),
name = argname)
diff --git a/scripts/qapi.py b/scripts/qapi.py
index f2c6d1f..ddab14d 100644
--- a/scripts/qapi.py
+++ b/scripts/qapi.py
@@ -434,6 +434,10 @@ def c_var(name, protect=True):
def c_fun(name, protect=True):
return c_var(name, protect).replace('.', '_')
+# Should be used where vendor extensions are supported
+def c_arg(name):
+ return c_var(name).replace('.', '_')
+
def c_list_type(name):
return '%sList' % name
Can anybody think of a use of c_var() that needs '.' preserved?
Re: [Qemu-devel] dataplane degradation in 2.1
On Wed, Jul 09, 2014 at 08:50:43PM +0400, Andrey Korolyov wrote: I`ve observed an immediate crash running tagged -rc1 with virtio-blk(675879f6f3c9463e103735a4e41e9deb0bee9b39). Please take a look on attached backtrace, hope that the fix still can made its way to 2.1. 1.6 works well with same config, so it`s clearly a regression. It will be fixed in -rc2. You can already apply the patches here: https://lists.nongnu.org/archive/html/qemu-devel/2014-07/msg01521.html Stefan pgpdvwGV8rey_.pgp Description: PGP signature
Re: [Qemu-devel] [RFC PATCH V5 1/3] xen: pass kernel initrd to qemu
On Mon, 2014-07-07 at 14:34 +0800, Chunyan Liu wrote: xen side patch to support xen HVM direct kernel boot: support 'kernel', 'ramdisk', 'cmdline' (and 'root', 'extra' as well which would be deprecated later) in HVM config file, parse config file, pass -kernel, -initrd, -append parameters to qemu. It's working with qemu-xen when using the default BIOS (seabios). [HVM config example] name=sles11_sp2 description=None uuid=5c84adcc-bd59-788a-96d2-195f9b599cfe memory=512 maxmem=512 vcpus=4 on_poweroff=destroy on_reboot=restart on_crash=destroy localtime=0 keymap=en-us builder=hvm device_model_override=/home/cyliu/git/qemu/x86_64-softmmu/qemu-system-x86_64 kernel=/mnt/vmlinuz-3.0.13-0.27-default ramdisk=/mnt/initrd-3.0.13-0.27-default root=/dev/hda2 extra=console=tty0 console=ttyS0 disk=[ 'file:/mnt/images/sles11_sp2/disk0.raw,hda,w', ] vif=[ 'mac=00:16:3e:56:af:69,bridge=br0,type=netfront', ] stdvga=0 vnc=1 vncunused=1 viridian=0 acpi=1 pae=1 serial=pty Signed-off-by: Chunyan Liu cy...@suse.com Acked-by: Ian Campbell ian.campb...@citrix.com
Re: [Qemu-devel] [PULL for-2.1 v2 00/10] KVM changes (+ misc small fixes) for 2.1
On 9 July 2014 17:18, Paolo Bonzini pbonz...@redhat.com wrote: The following changes since commit 9d9de254c2b81b68cd48f2324cc753a570a4cdd8: MAINTAINERS: seccomp: change email contact for Eduardo Otubo (2014-07-03 12:36:15 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git uq/master for you to fetch changes up to dbb832225a40fdc4f518466a6e34817ee6e59988: qtest: fix vhost-user-test compilation with old GLib (2014-07-09 18:17:08 +0200) Miroslav Rezanina (1): Enforce stack protector usage I'm afraid this patch causes the shell to complain when running configure: ../../configure: 1506: test: unexpected operator That's the line if test $stack_protector == yes ; then There is no == operator in POSIX sh; you want a single = for string comparison. thanks -- PMM
Re: [Qemu-devel] [RFC PATCH V5 2/3] xl.cfg: add 'cmdline' in config file
On Mon, 2014-07-07 at 14:34 +0800, Chunyan Liu wrote: Currently in xl.cfg, use 'root' and 'extra' to generate the command line. 'cmdline' could be a more generic equivalent. So, add 'cmdline' in xl.cfg and let it be preferred. 'root' and 'extra' still works. But when 'cmdline' is specified, 'root' and 'extra' will be ignored. [HVM config example] [snip] builder=hvm device_model_override=/home/cyliu/git/qemu/x86_64-softmmu/qemu-system-x86_64 kernel=/mnt/vmlinuz-3.0.13-0.27-default ramdisk=/mnt/initrd-3.0.13-0.27-default root=/dev/hda2 extra=console=tty0 console=ttyS0 [snip] or: [snip] builder=hvm device_model_override=/home/cyliu/git/qemu/x86_64-softmmu/qemu-system-x86_64 kernel=/mnt/vmlinuz-3.0.13-0.27-default ramdisk=/mnt/initrd-3.0.13-0.27-default cmdline=root=/dev/hda2 console=tty0 console=ttyS0 [snip] Signed-off-by: Chunyan Liu cy...@suse.com Acked-by: Ian Campbell ian.campb...@citrix.com
[Qemu-devel] [PATCH v3 0/2] spapr: Enable huge pages again
This does small RMA allocation rework and enables huge pages. Please comment, especially commit logs. Thanks! Changes: v3: * split to 2 patches, one mechanical * tested on PPC970 v2: * moved RMA memory region out of KVM code Alexey Kardashevskiy (2): spapr: Move RMA memory region registration code spapr: Enable use of huge pages hw/ppc/spapr.c | 19 --- target-ppc/kvm.c | 13 +++-- target-ppc/kvm_ppc.h | 2 +- 3 files changed, 16 insertions(+), 18 deletions(-) -- 2.0.0
[Qemu-devel] [PATCH] ppc: memory: Replace memory_region_init_ram with memory_region_allocate_system_memory
Commit 0b183fc871:memory: move mem_path handling to memory_region_allocate_system_memory split memory_region_init_ram and memory_region_init_ram_from_file. Also it moved mem-path handling a step up from memory_region_init_ram to memory_region_allocate_system_memory. Therefore for any board that uses memory_region_init_ram directly, -mem-path is not supported. Fix this by replacing memory_region_init_ram with memory_region_allocate_system_memory. Signed-off-by: Shreyas B. Prabhu shre...@linux.vnet.ibm.com --- hw/ppc/e500.c | 3 +-- hw/ppc/mac_newworld.c | 7 +++ hw/ppc/mac_oldworld.c | 8 hw/ppc/ppc405_boards.c | 21 + hw/ppc/ppc405_uc.c | 5 +++-- hw/ppc/ppc4xx_devs.c | 5 +++-- hw/ppc/prep.c | 3 +-- hw/ppc/spapr.c | 4 ++-- hw/ppc/virtex_ml507.c | 3 +-- 9 files changed, 27 insertions(+), 32 deletions(-) diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c index bb2e75f..1a5b30d 100644 --- a/hw/ppc/e500.c +++ b/hw/ppc/e500.c @@ -701,8 +701,7 @@ void ppce500_init(MachineState *machine, PPCE500Params *params) machine-ram_size = ram_size; /* Register Memory */ -memory_region_init_ram(ram, NULL, mpc8544ds.ram, ram_size); -vmstate_register_ram_global(ram); +memory_region_allocate_system_memory(ram, NULL, mpc8544ds.ram, ram_size); memory_region_add_subregion(address_space_mem, 0, ram); dev = qdev_create(NULL, e500-ccsr); diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c index 89d3cad..7e97af4 100644 --- a/hw/ppc/mac_newworld.c +++ b/hw/ppc/mac_newworld.c @@ -200,13 +200,12 @@ static void ppc_core99_init(MachineState *machine) } /* allocate RAM */ -memory_region_init_ram(ram, NULL, ppc_core99.ram, ram_size); -vmstate_register_ram_global(ram); +memory_region_allocate_system_memory(ram, NULL, ppc_core99.ram, ram_size); memory_region_add_subregion(get_system_memory(), 0, ram); /* allocate and load BIOS */ -memory_region_init_ram(bios, NULL, ppc_core99.bios, BIOS_SIZE); -vmstate_register_ram_global(bios); +memory_region_allocate_system_memory(bios, NULL, ppc_core99.bios, + BIOS_SIZE); if (bios_name == NULL) bios_name = PROM_FILENAME; filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name); diff --git a/hw/ppc/mac_oldworld.c b/hw/ppc/mac_oldworld.c index 4b5e905..afae825 100644 --- a/hw/ppc/mac_oldworld.c +++ b/hw/ppc/mac_oldworld.c @@ -130,13 +130,13 @@ static void ppc_heathrow_init(MachineState *machine) exit(1); } -memory_region_init_ram(ram, NULL, ppc_heathrow.ram, ram_size); -vmstate_register_ram_global(ram); +memory_region_allocate_system_memory(ram, NULL, ppc_heathrow.ram, + ram_size); memory_region_add_subregion(sysmem, 0, ram); /* allocate and load BIOS */ -memory_region_init_ram(bios, NULL, ppc_heathrow.bios, BIOS_SIZE); -vmstate_register_ram_global(bios); +memory_region_allocate_system_memory(bios, NULL, ppc_heathrow.bios, + BIOS_SIZE); if (bios_name == NULL) bios_name = PROM_FILENAME; filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name); diff --git a/hw/ppc/ppc405_boards.c b/hw/ppc/ppc405_boards.c index 98ad2d7..6b566cd 100644 --- a/hw/ppc/ppc405_boards.c +++ b/hw/ppc/ppc405_boards.c @@ -199,8 +199,8 @@ static void ref405ep_init(MachineState *machine) MemoryRegion *sysmem = get_system_memory(); /* XXX: fix this */ -memory_region_init_ram(ram_memories[0], NULL, ef405ep.ram, 0x0800); -vmstate_register_ram_global(ram_memories[0]); +memory_region_allocate_system_memory(ram_memories[0], NULL, ef405ep.ram, + 0x0800); ram_bases[0] = 0; ram_sizes[0] = 0x0800; memory_region_init(ram_memories[1], NULL, ef405ep.ram1, 0); @@ -214,8 +214,7 @@ static void ref405ep_init(MachineState *machine) , pic, kernel_filename == NULL ? 0 : 1); /* allocate SRAM */ sram_size = 512 * 1024; -memory_region_init_ram(sram, NULL, ef405ep.sram, sram_size); -vmstate_register_ram_global(sram); +memory_region_allocate_system_memory(sram, NULL, ef405ep.sram, sram_size); memory_region_add_subregion(sysmem, 0xFFF0, sram); /* allocate and load BIOS */ #ifdef DEBUG_BOARD_INIT @@ -246,8 +245,8 @@ static void ref405ep_init(MachineState *machine) printf(Load BIOS from file\n); #endif bios = g_new(MemoryRegion, 1); -memory_region_init_ram(bios, NULL, ef405ep.bios, BIOS_SIZE); -vmstate_register_ram_global(bios); +memory_region_allocate_system_memory(bios, NULL, ef405ep.bios, + BIOS_SIZE); if (bios_name == NULL) bios_name = BIOS_FILENAME; filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name); @@
Re: [Qemu-devel] [PATCH 00/46] Postcopy implementation
On Thu, Jul 10, 2014 at 02:37:43PM +0100, Dr. David Alan Gilbert wrote: * Eric Blake (ebl...@redhat.com) wrote: Is there any need for an event telling libvirt that enough pre-copy has occurred to make a postcopy worthwhile? I'm not sure that qemu knows much more than management does at that point; any such decision you can make based on an arbitrary cut off (i.e. migration is taking too long) or you could consider something based on some of the other stats that migration already exposes (like the dirty pages stats); if we've got any more stats that you need we can always expose them. Agreed; although we can just do that independently of this big patch set. It can be independent yes, but I think such event is needed (and once we add such event I hope we can get rid of the polling libvirt is doing for pure precopy too). I think for very large guests what should happen is a single _lazy_ pass of precopy and then immediately postcopy. That's why I think an event that notifies libvirt when it should issue the postcopy command is good, to be able to implement the single _lazy_ pass and nothing more than that. qemu should stop precopy and the source guest just before sending the event, so then libvirt can assign all storage to the destination just before issuing the postcopy commmand. By the time the event has been raised by qemu, the guest in the source qemu must never run anymore. So it is actually the same event needed in pure precopy too (except when using precopy+postcopy the precopy complete event will fire much sooner). We'll still need a parameter to precopy to tell qemu when precopy should stop. The single precopy lazy pass would consist of clearing the dirty bitmap, starting precopy, then if any page is found dirty by the time precopy tries to send it, we skip it. We only send those pages in precopy that haven't been modified yet by the time we reach them in precopy. Pages heavily modified will be sent purely through postcopy. Ultimately postcopy will be a page sorting feature to massively decrease the downtime latency, and to reduce to 2*ramsize the maximum amount of data transferred on the network without having to slow down the guest artificially. We'll also know exactly the maximum time in advance that it takes to migrate a large host no matter the load in it (2*ramsize divided by the network bandwidth available at the migration time). It'll be totally deterministic, no black magic slowdowns anymore.
[Qemu-devel] [PATCH v2 06/10] linux-user/main.c: __kernel_cmpxchg set env-CF directly
As we only need to manipulate the single flag do it directly though env.
Signed-off-by: Alex Bennée alex.ben...@linaro.org
---
v2:
- remove unused cpsr
- the direct flag setting seems a little hacky?
diff --git a/linux-user/main.c b/linux-user/main.c
index 8848e15..9101541 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -468,7 +468,7 @@ void cpu_loop(CPUX86State *env)
static void arm_kernel_cmpxchg64_helper(CPUARMState *env)
{
uint64_t oldval, newval, val;
-uint32_t addr, cpsr;
+uint32_t addr;
target_siginfo_t info;
/* Based on the 32 bit code in do_kernel_trap */
@@ -478,7 +478,6 @@ static void arm_kernel_cmpxchg64_helper(CPUARMState *env)
operations. However things like ldrex/strex are much harder so
there's not much point trying. */
start_exclusive();
-cpsr = cpsr_read(env);
addr = env-regs[2];
if (get_user_u64(oldval, env-regs[0])) {
@@ -505,12 +504,11 @@ static void arm_kernel_cmpxchg64_helper(CPUARMState *env)
};
env-regs[0] = 0;
-cpsr |= CPSR_C;
+env-CF = 1;
} else {
env-regs[0] = -1;
-cpsr = ~CPSR_C;
+env-CF = 0;
}
-cpsr_write(env, cpsr, CPSR_C);
end_exclusive();
return;
@@ -533,7 +531,6 @@ static int
do_kernel_trap(CPUARMState *env)
{
uint32_t addr;
-uint32_t cpsr;
uint32_t val;
switch (env-regs[15]) {
@@ -546,7 +543,6 @@ do_kernel_trap(CPUARMState *env)
operations. However things like ldrex/strex are much harder so
there's not much point trying. */
start_exclusive();
-cpsr = save_state_to_spsr(env);
addr = env-regs[2];
/* FIXME: This should SEGV if the access fails. */
if (get_user_u32(val, addr))
@@ -556,12 +552,11 @@ do_kernel_trap(CPUARMState *env)
/* FIXME: Check for segfaults. */
put_user_u32(val, addr);
env-regs[0] = 0;
-cpsr |= CPSR_C;
+env-CF = 1;
} else {
env-regs[0] = -1;
-cpsr = ~CPSR_C;
+env-CF = 0;
}
-cpsr_write(env, cpsr, CPSR_C);
end_exclusive();
break;
case 0x0fe0: /* __kernel_get_tls */
--
2.0.1
[Qemu-devel] [PATCH v2 02/10] target-arm/cpu.h: common pstate save/restore
This adds a universal program state save and restore function. This is
intended to simplify the migration serialisation functionality and avoid
special casing depending on the mode of the CPU at serialisation time.
Signed-off-by: Alex Bennée alex.ben...@linaro.org
---
v2:
- reword commentary for restore_state_from_spsr
- rm commented out code
- add set_condition_codes for flags
- add xpsr_read functionality
v3:
- rebase
- checkpatch.pl issues
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index c2312d0..fe4d4f3 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -453,19 +453,24 @@ int arm_cpu_handle_mmu_fault(CPUState *cpu, vaddr
address, int rw,
#define PSTATE_SP (1U)
#define PSTATE_M (0xFU)
#define PSTATE_nRW (1U 4)
+#define PSTATE_T (1U 5)
#define PSTATE_F (1U 6)
#define PSTATE_I (1U 7)
#define PSTATE_A (1U 8)
#define PSTATE_D (1U 9)
#define PSTATE_IL (1U 20)
#define PSTATE_SS (1U 21)
+#define PSTATE_Q (1U 27)
#define PSTATE_V (1U 28)
#define PSTATE_C (1U 29)
#define PSTATE_Z (1U 30)
#define PSTATE_N (1U 31)
#define PSTATE_NZCV (PSTATE_N | PSTATE_Z | PSTATE_C | PSTATE_V)
-#define PSTATE_DAIF (PSTATE_D | PSTATE_A | PSTATE_I | PSTATE_F)
-#define CACHED_PSTATE_BITS (PSTATE_NZCV | PSTATE_DAIF)
+#define PSTATE_AIF (PSTATE_A | PSTATE_I | PSTATE_F)
+#define PSTATE_DAIF (PSTATE_D | PSTATE_AIF)
+#define AARCH64_CACHED_PSTATE_BITS (PSTATE_NZCV | PSTATE_DAIF)
+#define AARCH32_CACHED_PSTATE_BITS (PSTATE_NZCV | PSTATE_Q | PSTATE_AIF \
+| CACHED_CPSR_BITS)
/* Mode values for AArch64 */
#define PSTATE_MODE_EL3h 13
#define PSTATE_MODE_EL3t 12
@@ -508,7 +513,7 @@ static inline void pstate_write(CPUARMState *env, uint32_t
val)
env-CF = (val 29) 1;
env-VF = (val 3) 0x8000;
env-daif = val PSTATE_DAIF;
-env-pstate = val ~CACHED_PSTATE_BITS;
+env-pstate = val ~AARCH64_CACHED_PSTATE_BITS;
}
/* ARMv7-AR ARM B1.3.3 Current Program Status Register, CPSR
@@ -698,6 +703,137 @@ static inline bool arm_el_is_aa64(CPUARMState *env, int
el)
return arm_feature(env, ARM_FEATURE_AARCH64);
}
+/* ARMv8 ARM D1.6.4, Saved Program Status Registers
+ *
+ * These are formats used to save program status when exceptions are
+ * taken. There are two forms:
+ *
+ * AArch64 - AArch64 Exception
+ * 31 30 28 29 27 22 21 20 19 10 9 8 7 6 5 4 3 0
+ * +---+---+---+---+--+++--+---+---+---+---+---++
+ * | N | Z | C | V | RES0 | SS | IL | RES0 | D | A | I | F | 0 | 0 | M[3:0] |
+ * +---+---+---+---+--+++--+---+---+---+---+---++
+ *
+ * AArch32 - AArch64 Exception
+ * (see also ARMv7-AR ARM B1.3.3 CSPR/SPSR formats)
+ * 31 30 29 28 27 26 25 24 23 22 21 20 19 16
+ * +---+---+---+---+---+-+---+--+++-+
+ * | N | Z | C | V | Q | IT[1:0] | J | RES0 | SS | IL | GE[3:0] |
+ * +---+---+---+---+---+-+---+--+++-+
+ * 15 10 9 8 7 6 5 4 3 0
+ * +-+---+---+---+---+---+---++
+ * | IT[7:2] | E | A | I | F | T | 1 | M[3:0] |
+ * +-+---+---+---+---+---+---++
+ *
+ * M[4] = nRW - 0 = 64bit, 1 = 32bit
+ * Bit definitions for ARMv8 SPSR (PSTATE) format.
+ * Only these are valid when in AArch64 mode; in
+ * AArch32 mode SPSRs are basically CPSR-format.
+ *
+ * Also ARMv7-M ARM B1.4.2, special purpose program status register xPSR
+ */
+
+/* Save the program state */
+static inline uint32_t save_state_to_spsr(CPUARMState *env)
+{
+uint32_t final_spsr = 0;
+
+/* Calculate integer flags */
+final_spsr |= (env-NF 0x8000) ? PSTATE_N : 0; /* bit 31 */
+final_spsr |= (env-ZF == 0) ? PSTATE_Z : 0;
+final_spsr |= env-CF ? PSTATE_C : 0;/* or env-CF 29 */
+final_spsr |= (env-VF 0x8000) ? PSTATE_V : 0; /* bit 31 */
+
+if (is_a64(env)) {
+/* SS - Software Step */
+/* IL - Illegal execution state */
+/* DAIF flags - should we mask?*/
+final_spsr |= (env-daif PSTATE_DAIF);
+/* And the final un-cached bits */
+final_spsr |= (env-pstate ~AARCH64_CACHED_PSTATE_BITS);
+} else {
+/* condexec_bits is split over two parts */
+final_spsr |= ((env-condexec_bits 3) 25);
+final_spsr |= ((env-condexec_bits 0xfc) 8);
+
+if (arm_feature(env, ARM_FEATURE_M)) {
+final_spsr |= (env-thumb 24); /* alt pos */
+final_spsr |= env-v7m.exception;
+} else {
+final_spsr |= env-QF ? PSTATE_Q : 0;
+/* GE needs shifting into place */
+final_spsr |= (env-GE 16);
+/* AIF is a a subset of DAIF */
+final_spsr |= (env-daif PSTATE_AIF);
+final_spsr |= env-thumb ? PSTATE_T : 0;
+
+final_spsr |= PSTATE_nRW;
+
+/* And the final un-cached bits */
+final_spsr |= (env-uncached_cpsr
[Qemu-devel] [PATCH v2 07/10] target-arm: remove last users of cpsr_write
And use the new machinery to to save and restore program state. The old
cpsr_write function did some special handling for mode switches which
has been moved into the helper function.
Signed-off-by: Alex Bennée alex.ben...@linaro.org
---
v2:
- rebase
- add mask helper function
- checkpatch fixes
diff --git a/linux-user/main.c b/linux-user/main.c
index 9101541..5f7cc31 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -4184,7 +4184,7 @@ int main(int argc, char **argv, char **envp)
#elif defined(TARGET_ARM)
{
int i;
-cpsr_write(env, regs-uregs[16], 0x);
+restore_state_from_spsr(env, regs-uregs[16]);
for(i = 0; i 16; i++) {
env-regs[i] = regs-uregs[i];
}
diff --git a/linux-user/signal.c b/linux-user/signal.c
index 9c6727b..b6f9ef4 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -1599,38 +1599,39 @@ get_sigframe(struct target_sigaction *ka, CPUARMState
*regs, int framesize)
static void
setup_return(CPUARMState *env, struct target_sigaction *ka,
-abi_ulong *rc, abi_ulong frame_addr, int usig, abi_ulong rc_addr)
+ abi_ulong *rc, abi_ulong frame_addr, int usig, abi_ulong rc_addr)
{
- abi_ulong handler = ka-_sa_handler;
- abi_ulong retcode;
- int thumb = handler 1;
- uint32_t cpsr = save_state_to_spsr(env);
+abi_ulong handler = ka-_sa_handler;
+abi_ulong retcode;
+int thumb = handler 1;
+uint32_t cpsr = save_state_to_spsr(env);
- cpsr = ~CPSR_IT;
- if (thumb) {
- cpsr |= CPSR_T;
- } else {
- cpsr = ~CPSR_T;
- }
+cpsr = ~CPSR_IT;
+if (thumb) {
+cpsr |= CPSR_T;
+} else {
+cpsr = ~CPSR_T;
+}
- if (ka-sa_flags TARGET_SA_RESTORER) {
- retcode = ka-sa_restorer;
- } else {
- unsigned int idx = thumb;
+if (ka-sa_flags TARGET_SA_RESTORER) {
+retcode = ka-sa_restorer;
+} else {
+unsigned int idx = thumb;
- if (ka-sa_flags TARGET_SA_SIGINFO)
- idx += 2;
+if (ka-sa_flags TARGET_SA_SIGINFO) {
+idx += 2;
+}
-__put_user(retcodes[idx], rc);
+__put_user(retcodes[idx], rc);
- retcode = rc_addr + thumb;
- }
+retcode = rc_addr + thumb;
+}
- env-regs[0] = usig;
- env-regs[13] = frame_addr;
- env-regs[14] = retcode;
- env-regs[15] = handler (thumb ? ~1 : ~3);
- cpsr_write(env, cpsr, 0x);
+env-regs[0] = usig;
+env-regs[13] = frame_addr;
+env-regs[14] = retcode;
+env-regs[15] = handler (thumb ? ~1 : ~3);
+restore_state_from_spsr(env, cpsr);
}
static abi_ulong *setup_sigframe_v2_vfp(abi_ulong *regspace, CPUARMState *env)
@@ -1858,12 +1859,14 @@ restore_sigcontext(CPUARMState *env, struct
target_sigcontext *sc)
__get_user(env-regs[15], sc-arm_pc);
#ifdef TARGET_CONFIG_CPU_32
__get_user(cpsr, sc-arm_cpsr);
-cpsr_write(env, cpsr, CPSR_USER | CPSR_EXEC);
+restore_state_from_masked_spsr(env,
+ (CPSR_USER | CPSR_EXEC),
+ cpsr);
#endif
- err |= !valid_user_regs(env);
+err |= !valid_user_regs(env);
- return err;
+return err;
}
static long do_sigreturn_v1(CPUARMState *env)
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index 3f23167..b56f1a8 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -795,6 +795,15 @@ static inline void restore_state_from_spsr(CPUARMState
*env,
}
}
+/* Restore a few masked bits of the program state */
+static inline void restore_state_from_masked_spsr(CPUARMState *env,
+ uint32_t mask,
+ uint32_t saved_state)
+{
+uint32_t spsr = (save_state_to_spsr(env) ~mask);
+spsr |= (saved_state mask);
+return restore_state_from_spsr(env, spsr);
+}
void arm_cpu_list(FILE *f, fprintf_function cpu_fprintf);
diff --git a/target-arm/gdbstub.c b/target-arm/gdbstub.c
index ec25f30..5e60589 100644
--- a/target-arm/gdbstub.c
+++ b/target-arm/gdbstub.c
@@ -93,8 +93,12 @@ int arm_cpu_gdb_write_register(CPUState *cs, uint8_t
*mem_buf, int n)
}
return 4;
case 25:
-/* CPSR */
-cpsr_write(env, tmp, 0x);
+/* CPSR
+ * FIXME?: as restore_state_from_spsr() doesn't do aarch32
+ * special mode fixups this may break. However GDB doesn't
+ * seem to be able to handle tracing over a mode switch anyway
+ */
+restore_state_from_spsr(env, tmp);
return 4;
}
/* Unknown register. */
diff --git a/target-arm/helper.c b/target-arm/helper.c
index 030bcdd..6d755c0
Re: [Qemu-devel] Help on possible hang in drive-mirror / query-block-jobs
Il 10/07/2014 17:53, Daniel P. Berrange ha scritto: Can you install a custom QEMU? How many megabytes of stdout can your test rig tolerate? Any chance you can collect other files (traces)? I can possibly come up with some gross hack to wget a qemu binary from an external host at the start of the test. Can generate 100MB of test logs without it being an issue. What sort of info would be helpful to collect. I can't easily get arbitrary files out of the test hosts, but if there's a way to get the debug info into QEMU's stdout/stderr logs then we're collecting those already. If you can compile a custom QEMU, then yes it's possible. Paolo
[Qemu-devel] [PULL 10/10] qtest: fix vhost-user-test compilation with old GLib
From: Nikolay Nikolaev n.nikol...@virtualopensystems.com Mising G_TIME_SPAN_SECOND definition breaks the RHEL6 compilation as GLib version before 2.26 does not have it. In such case just define it. Reported-by: Kevin Wolf kw...@redhat.com Signed-off-by: Nikolay Nikolaev n.nikol...@virtualopensystems.com Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- tests/vhost-user-test.c | 4 1 file changed, 4 insertions(+) diff --git a/tests/vhost-user-test.c b/tests/vhost-user-test.c index 2af2381..406ba70 100644 --- a/tests/vhost-user-test.c +++ b/tests/vhost-user-test.c @@ -22,6 +22,10 @@ #include qemu/sockets.h /* GLIB version compatibility flags */ +#if !GLIB_CHECK_VERSION(2, 26, 0) +#define G_TIME_SPAN_SECOND (G_GINT64_CONSTANT(100)) +#endif + #if GLIB_CHECK_VERSION(2, 28, 0) #define HAVE_MONOTONIC_TIME #endif -- 1.8.3.1
Re: [Qemu-devel] [PATCH 16/46] Add migration-capability boolean for postcopy-ram.
Il 07/07/2014 22:23, Dr. David Alan Gilbert ha scritto: I think what I need to do for that is: 1) As for precopy add the option not to start the destination CPU on entry to postcopy; I think that's OK, because we can carry on in postcopy mode even if the destination CPU isn't running, we just won't generate page requests. Admittedly I don't quite understand how (1) is supposed to interact with device state. This is just passing -S on the destination side. Device state is treated the same as without -S and can still generate page requests. The only difference is whether you have a vm_start() or not. I think it should be possible to restart the VM on the source side after postcopy migration, as long as migration has failed or has been canceled. Whether that makes sense or causes dire disk corruption depends on the particular scenario, but then the same holds for precopy and we don't try at all to prevent cont at the end of migration. It makes it much easier for libvirt to restart the source if it cannot continue on the destination. Paolo
[Qemu-devel] [PULL 05/10] watchdog: fix deadlock with -watchdog-action pause
qemu_clock_enable says: /* Disabling the clock will wait for related timerlists to stop * executing qemu_run_timers. Thus, this functions should not * be used from the callback of a timer that is based on @clock. * Doing so would cause a deadlock. */ and it indeed does: vm_stop uses qemu_clock_enable on QEMU_CLOCK_VIRTUAL and watchdogs are based on QEMU_CLOCK_VIRTUAL, and we get a deadlock. Use qemu_system_vmstop_request_prepare()/qemu_system_vmstop_request() instead; yet another alternative could be a BH. I checked other occurrences of vm_stop and they should not have this problem. RUN_STATE_IO_ERROR could in principle (it depends on the code in the drivers) but it has been fixed by commit 2bd3bce, block: asynchronously stop the VM on I/O errors, 2014-06-05. Tested-by: Luiz Capitulino lcapitul...@redhat.com Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- hw/watchdog/watchdog.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/hw/watchdog/watchdog.c b/hw/watchdog/watchdog.c index 9f607d4..c307f9b 100644 --- a/hw/watchdog/watchdog.c +++ b/hw/watchdog/watchdog.c @@ -122,8 +122,12 @@ void watchdog_perform_action(void) exit(0); case WDT_PAUSE: /* same as 'stop' command in monitor */ +/* In a timer callback, when vm_stop calls qemu_clock_enable + * you would get a deadlock. Bypass the problem. + */ +qemu_system_vmstop_request_prepare(); qapi_event_send_watchdog(WATCHDOG_EXPIRATION_ACTION_PAUSE, error_abort); -vm_stop(RUN_STATE_WATCHDOG); +qemu_system_vmstop_request(RUN_STATE_WATCHDOG); break; case WDT_DEBUG: -- 1.8.3.1
[Qemu-devel] [PULL for-2.1 13/22] virtio-blk: avoid g_slice_new0() for VirtIOBlockReq and VirtQueueElement
From: Stefan Hajnoczi stefa...@redhat.com
In commit de6c8042ec55da18702fa51f09072fcaa315edc3 (virtio-blk: Avoid
zeroing every request structure) we avoided the 40 KB memset when
allocating VirtIOBlockReq.
The memset was reintroduced in commit
671ec3f056559f22a2531a91dce3a258b9b5eb8a (virtio-blk: Convert
VirtIOBlockReq.elem to pointer).
It must be fixed again to avoid a performance regression.
Cc: Fam Zheng f...@redhat.com
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
hw/block/virtio-blk.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
index aec3146..b06a56d 100644
--- a/hw/block/virtio-blk.c
+++ b/hw/block/virtio-blk.c
@@ -31,9 +31,11 @@
static VirtIOBlockReq *virtio_blk_alloc_request(VirtIOBlock *s)
{
-VirtIOBlockReq *req = g_slice_new0(VirtIOBlockReq);
+VirtIOBlockReq *req = g_slice_new(VirtIOBlockReq);
req-dev = s;
-req-elem = g_slice_new0(VirtQueueElement);
+req-qiov.size = 0;
+req-next = NULL;
+req-elem = g_slice_new(VirtQueueElement);
return req;
}
--
1.8.3.1
[Qemu-devel] [PULL for-2.1 05/22] test-aio: fix GSource-based timer test
From: Paolo Bonzini pbonz...@redhat.com
The current test depends too much on the implementation of the AioContext
GSource. Just iterate on the main loop until the callback has been invoked
the right number of times.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
tests/test-aio.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/tests/test-aio.c b/tests/test-aio.c
index e5f8b55..264dab9 100644
--- a/tests/test-aio.c
+++ b/tests/test-aio.c
@@ -806,17 +806,16 @@ static void test_source_timer_schedule(void)
g_usleep(1 * G_USEC_PER_SEC);
g_assert_cmpint(data.n, ==, 0);
-g_assert(g_main_context_iteration(NULL, false));
+g_assert(g_main_context_iteration(NULL, true));
g_assert_cmpint(data.n, ==, 1);
+expiry += data.ns;
-/* The comment above was not kidding when it said this wakes up itself */
-do {
-g_assert(g_main_context_iteration(NULL, true));
-} while (qemu_clock_get_ns(data.clock_type) = expiry);
-g_usleep(1 * G_USEC_PER_SEC);
-g_main_context_iteration(NULL, false);
+while (data.n 2) {
+g_main_context_iteration(NULL, true);
+}
g_assert_cmpint(data.n, ==, 2);
+g_assert(qemu_clock_get_ns(data.clock_type) expiry);
aio_set_fd_handler(ctx, pipefd[0], NULL, NULL, NULL);
close(pipefd[0]);
--
1.8.3.1
Re: [Qemu-devel] [PATCH v2] libxl: change default QEMU machine to pc-i440fx-1.6
ping?
On Thu, 12 Jun 2014, Stefano Stabellini wrote:
Choose pc-i440fx-1.6 instead of pc for HVM guests, so that we know for
sure what is the machine that we are emulating.
Use pc-i440fx-1.6 regardless of the xen_platform_pci option. Add the
xen-platform device if requested. Move the machine options earlier,
before any emulated devices options so that QEMU will assign slot 2 to
the xen-platform device, maintaining compatibility with current
installations.
In case of Intel graphic passthrough, slot 2 might be needed by the
grafics card. However it is easy to change the position of the
xen-platform device on the PCI bus if graphic passthrough is enabled, by
passing addr=desired_slot_number.
Specify PIIX4_PM.acpi-pci-hotplug-with-bridge-support=off, because
differently from xenfv, the other QEMU machines do not have that option
off by default.
This patch does not change the emulated environment in the guest, unless
soundhw='hda' is specified, in that case the xen-platform device is
moved to slot 3 (used to be always slot 2). This change might cause
problems to guests with soundhw='hda', migrating from 4.4 to 4.5.
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
---
Changes in v2:
- note the dependency on QEMU = 1.6.1 in the README;
- move the -machine options even earlier and drop the explicit
,slot=0x2.
diff --git a/README b/README
index 9bbe734..cb66893 100644
--- a/README
+++ b/README
@@ -73,6 +73,10 @@ disabled at compile time:
* markdown
* figlet (for generating the traditional Xen start of day banner)
+As a runtime requirement, you need a QEMU binary newer than v1.6.1,
+compiled with Xen support. By default the Xen build system will clone
+and build one for you.
+
Second, you need to acquire a suitable kernel for use in domain 0. If
possible you should use a kernel provided by your OS distributor. If
no suitable kernel is available from your OS distributor then refer to
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 51ab2bf..b5a0beb 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -403,6 +403,27 @@ static char **
libxl__build_device_model_args_new(libxl__gc *gc,
-xen-domid,
libxl__sprintf(gc, %d, guest_domid), NULL);
+switch (b_info-type) {
+case LIBXL_DOMAIN_TYPE_PV:
+flexarray_append_pair(dm_args, -machine, xenpv);
+for (i = 0; b_info-extra_pv b_info-extra_pv[i] != NULL; i++)
+flexarray_append(dm_args, b_info-extra_pv[i]);
+break;
+case LIBXL_DOMAIN_TYPE_HVM:
+flexarray_append_pair(dm_args, -machine,
pc-i440fx-1.6,accel=xen);
+flexarray_append_pair(dm_args, -global,
+PIIX4_PM.acpi-pci-hotplug-with-bridge-support=off);
+if (libxl_defbool_val(b_info-u.hvm.xen_platform_pci)) {
+flexarray_append(dm_args, -device);
+flexarray_append(dm_args, xen-platform);
+}
+for (i = 0; b_info-extra_hvm b_info-extra_hvm[i] != NULL; i++)
+flexarray_append(dm_args, b_info-extra_hvm[i]);
+break;
+default:
+abort();
+}
+
flexarray_append(dm_args, -chardev);
flexarray_append(dm_args,
libxl__sprintf(gc, socket,id=libxl-cmd,
@@ -646,29 +667,6 @@ static char **
libxl__build_device_model_args_new(libxl__gc *gc,
for (i = 0; b_info-extra b_info-extra[i] != NULL; i++)
flexarray_append(dm_args, b_info-extra[i]);
-flexarray_append(dm_args, -machine);
-switch (b_info-type) {
-case LIBXL_DOMAIN_TYPE_PV:
-flexarray_append(dm_args, xenpv);
-for (i = 0; b_info-extra_pv b_info-extra_pv[i] != NULL; i++)
-flexarray_append(dm_args, b_info-extra_pv[i]);
-break;
-case LIBXL_DOMAIN_TYPE_HVM:
-if (!libxl_defbool_val(b_info-u.hvm.xen_platform_pci)) {
-/* Switching here to the machine pc which does not add
- * the xen-platform device instead of the default xenfv
machine.
- */
-flexarray_append(dm_args, pc,accel=xen);
-} else {
-flexarray_append(dm_args, xenfv);
-}
-for (i = 0; b_info-extra_hvm b_info-extra_hvm[i] != NULL; i++)
-flexarray_append(dm_args, b_info-extra_hvm[i]);
-break;
-default:
-abort();
-}
-
ram_size = libxl__sizekb_to_mb(b_info-max_memkb - b_info-video_memkb);
flexarray_append(dm_args, -m);
flexarray_append(dm_args, libxl__sprintf(gc, %PRId64, ram_size));
[Qemu-devel] [PATCH 131/156] linux-user: Don't overrun guest buffer in sched_getaffinity
From: Peter Maydell peter.mayd...@linaro.org
If the guest's long type is smaller than the host's, then
our sched_getaffinity wrapper needs to round the buffer size
up to a multiple of the host sizeof(long). This means that when
we copy the data back from the host buffer to the guest's
buffer there might be more than we can fit. Rather than
overflowing the guest's buffer, handle this case by returning
EINVAL or ignoring the unused extra space, as appropriate.
Note that only guests using the syscall interface directly might
run into this bug -- the glibc wrappers around it will always
use a buffer whose size is a multiple of 8 regardless of guest
architecture.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
Signed-off-by: Riku Voipio riku.voi...@linaro.org
(cherry picked from commit be3bd286bc06bb68cdc71748d9dd4edcd57b2b24)
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
linux-user/syscall.c | 16
1 file changed, 16 insertions(+)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 81f79f9..de8918d 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -7479,6 +7479,22 @@ abi_long do_syscall(void *cpu_env, int num, abi_long
arg1,
ret = get_errno(sys_sched_getaffinity(arg1, mask_size, mask));
if (!is_error(ret)) {
+if (ret arg2) {
+/* More data returned than the caller's buffer will fit.
+ * This only happens if sizeof(abi_long) sizeof(long)
+ * and the caller passed us a buffer holding an odd number
+ * of abi_longs. If the host kernel is actually using the
+ * extra 4 bytes then fail EINVAL; otherwise we can just
+ * ignore them and only copy the interesting part.
+ */
+int numcpus = sysconf(_SC_NPROCESSORS_CONF);
+if (numcpus arg2 * 8) {
+ret = -TARGET_EINVAL;
+break;
+}
+ret = arg2;
+}
+
if (copy_to_user(arg3, mask, ret)) {
goto efault;
}
--
1.9.1
Re: [Qemu-devel] [PATCH] scripts: qapi-event.py: support vendor extension
On 07/10/2014 08:31 AM, Markus Armbruster wrote:
Luiz Capitulino lcapitul...@redhat.com writes:
The event code generator barfs when it sees a dot in an event
argument, this makes it impossible to support vendor extensions
in event arguments as they always contain dots. Fix this by
replacing dots by hyphens in the generated code.
Code replaces by underbar, not hyphen.
PS: Event names and QMP command arguments may suffer from the
same issue, but I'm not checking/fixing them today.
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
+# Should be used where vendor extensions are supported
+def c_arg(name):
+return c_var(name).replace('.', '_')
+
def c_list_type(name):
return '%sList' % name
Can anybody think of a use of c_var() that needs '.' preserved?
If the generator spits out any comments, those comments should refer to
the QMP wire name, including the '.'. But right now, generated code
doesn't seem to do that.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v2] libxl: change default QEMU machine to pc-i440fx-1.6
Stefano Stabellini writes (Re: [PATCH v2] libxl: change default QEMU machine to pc-i440fx-1.6): ping? On Thu, 12 Jun 2014, Stefano Stabellini wrote: ... This patch does not change the emulated environment in the guest, unless soundhw='hda' is specified, in that case the xen-platform device is moved to slot 3 (used to be always slot 2). This change might cause problems to guests with soundhw='hda', migrating from 4.4 to 4.5. Is there a way for someone who experiences this problem to make it go back to the way it was ? Ian.
Re: [Qemu-devel] dataplane degradation in 2.1
Il 10/07/2014 17:10, Andrey Korolyov ha scritto: Cool, thanks Stefan. Nearly missed this set in patchwork because it came a bit earlier than the latest fix addressed to the segfault I mentioned. By the way, do you plan to add I/O throttlers to the iothread model in next release cycles? Throttling per-BlockDriverState is already supported by dataplane. Paolo
Re: [Qemu-devel] [PATCH v2 2.1 4/4] ide: Treat read/write beyond end as invalid
Kevin Wolf kw...@redhat.com writes:
Am 04.07.2014 um 15:32 hat Markus Armbruster geschrieben:
The block layer fails such reads and writes just fine. However, they
then get treated like valid operations that fail: the error action
gets executed. Unwanted; reporting the error to the guest is the only
sensible action.
Reject them before passing them to the block layer. This bypasses the
error action and, for PIO but not DMA, I/O accounting. Tolerable,
because I/O accounting is an inconsistent mess anyway.
Signed-off-by: Markus Armbruster arm...@redhat.com
---
hw/ide/core.c | 28
1 file changed, 28 insertions(+)
diff --git a/hw/ide/core.c b/hw/ide/core.c
index 3a38f1e..63a500d 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -499,6 +499,18 @@ static void ide_rw_error(IDEState *s) {
ide_set_irq(s-bus);
}
+static bool ide_sect_range_ok(IDEState *s,
+ uint64_t sector, uint64_t nb_sectors)
+{
+uint64_t total_sectors;
+
+bdrv_get_geometry(s-bs, total_sectors);
+if (sector total_sectors || nb_sectors total_sectors - sector) {
+return false;
+}
+return true;
+}
+
static void ide_sector_read_cb(void *opaque, int ret)
{
IDEState *s = opaque;
@@ -554,6 +566,11 @@ void ide_sector_read(IDEState *s)
printf(sector=% PRId64 \n, sector_num);
#endif
+if (!ide_sect_range_ok(s, sector_num, n)) {
+ide_rw_error(s);
+return;
+}
+
s-iov.iov_base = s-io_buffer;
s-iov.iov_len = n * BDRV_SECTOR_SIZE;
qemu_iovec_init_external(s-qiov, s-iov, 1);
@@ -671,6 +688,12 @@ void ide_dma_cb(void *opaque, int ret)
sector_num, n, s-dma_cmd);
#endif
+if (!ide_sect_range_ok(s, sector_num, n)) {
+dma_buf_commit(s);
+ide_dma_error(s);
+goto eot;
Are you sure that this should be 'goto eot' rather than just 'return'?
When jumping to eot, we do the I/O accounting (which we said we don't
care about) and call ide_set_inactive() for a second time. The condition
for setting BM_STATUS_DMAING is never met when coming from here.
I am worried about ide_set_inactive() doing double request cleanup.
You're right; I missed the fact that ide_dma_error() calls
ide_set_inactive() already.
Immediate return also skips the other things happening after eot, but
that's okay, because:
* skipping the bdrv_acct_done() merely changes I/O accounting to be
busted somewhat differently, and
* stay_active is certainly false, so we don't actually skip anything
there.
Respin sent.
Re: [Qemu-devel] [RFC] alpha qemu arithmetic exceptions
On Tue, Jul 08, 2014 at 05:33:16PM +0100, Peter Maydell wrote: Incidentally, combination of --enable-gprof and (default) --enable-pie won't build - it dies with ld(1) complaining about relocs in gcrt1.o. This sounds like a toolchain bug to me :-) Debian stable/amd64, gcc 4.7.2, binutils 2.22. And google search finds this, for example: http://osdir.com/ml/qemu-devel/2013-05/msg00710.html. That one has gcc 4.4.3. Anyway, adding --disable-pie to --enable-gprof gets it to build, but as I said, gprof is no better than perf and oprofile - same problem. Stats I quoted were from qemu-system-alpha booting debian/lenny (5.10) and going through their kernel package build. I have perf report in front of me right now; the top ones are 41.77% qemu-system-alp perf-24701.map [.] 0x7fbbee558930 11.78% qemu-system-alp qemu-system-alpha[.] cpu_alpha_exec 4.95% qemu-system-alp [vdso] [.] 0x7fffdd7ff8de 2.40% qemu-system-alp qemu-system-alpha[.] phys_page_find 1.49% qemu-system-alp qemu-system-alpha[.] address_space_translate_internal 1.34% qemu-system-alp [kernel.kallsyms][k] read_hpet 1.26% qemu-system-alp qemu-system-alpha[.] tlb_set_page 1.23% qemu-system-alp qemu-system-alpha[.] find_next_bit 1.04% qemu-system-alp qemu-system-alpha[.] get_page_addr_code 1.01% qemu-system-alp libpthread-2.13.so [.] pthread_mutex_lock 0.88% qemu-system-alp qemu-system-alpha[.] helper_cmpbge 0.80% qemu-system-alp libc-2.13.so [.] __memset_sse2 0.72% qemu-system-alp libpthread-2.13.so [.] __pthread_mutex_unlock_usercnt 0.70% qemu-system-alp qemu-system-alpha[.] get_physical_address 0.69% qemu-system-alp qemu-system-alpha[.] address_space_translate 0.68% qemu-system-alp qemu-system-alpha[.] tcg_optimize 0.67% qemu-system-alp qemu-system-alpha[.] ldq_phys 0.63% qemu-system-alp qemu-system-alpha[.] qemu_get_ram_ptr 0.62% qemu-system-alp qemu-system-alpha[.] helper_le_ldq_mmu 0.57% qemu-system-alp qemu-system-alpha[.] memory_region_is_ram and cpu_alpha_exec() spends most of the time in inlined tb_find_fast(). It might be worth checking the actual distribution of the hash of virt address used by that sucker - I wonder if dividing its argument by 4 wouldn't improve the things, but I don't have stats on actual frequency of conflicts, etc. In any case, the first lump (42%) seems to be tastier ;-) There are all kinds of microoptimizations possible (e.g. helper_cmpbge() could be done by a couple of MMX insns on amd64 host[1]), but it would be nice to have some details on what we spend the time on in tcg output... [1] The reason why helper_cmpbge() shows up is that string functions on alpha use that insn a lot; it _might_ be worth optimizing.
[Qemu-devel] [PATCH 109/156] block: Limit request size (CVE-2014-0143)
From: Kevin Wolf kw...@redhat.com
Limiting the size of a single request to INT_MAX not only fixes a
direct integer overflow in bdrv_check_request() (which would only
trigger bad behaviour with ridiculously huge images, as in close to
2^64 bytes), but can also prevent overflows in all block drivers.
Signed-off-by: Kevin Wolf kw...@redhat.com
Reviewed-by: Max Reitz mre...@redhat.com
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
(cherry picked from commit 8f4754ede56e3f9ea3fd7207f4a7c4453e59285b)
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
block.c | 4
1 file changed, 4 insertions(+)
diff --git a/block.c b/block.c
index 68651a9..202d817 100644
--- a/block.c
+++ b/block.c
@@ -2277,6 +2277,10 @@ static int bdrv_check_byte_request(BlockDriverState *bs,
int64_t offset,
static int bdrv_check_request(BlockDriverState *bs, int64_t sector_num,
int nb_sectors)
{
+if (nb_sectors INT_MAX / BDRV_SECTOR_SIZE) {
+return -EIO;
+}
+
return bdrv_check_byte_request(bs, sector_num * BDRV_SECTOR_SIZE,
nb_sectors * BDRV_SECTOR_SIZE);
}
--
1.9.1
[Qemu-devel] [RFC 12/25] accel: Move accel init/allowed code to separate function
Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
hw/core/accel.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/hw/core/accel.c b/hw/core/accel.c
index 9aa853f..85e60eb 100644
--- a/hw/core/accel.c
+++ b/hw/core/accel.c
@@ -57,6 +57,17 @@ static AccelClass *accel_find(const char *opt_name)
return ac;
}
+static int accel_init(AccelClass *acc, MachineClass *mc)
+{
+int ret;
+*(acc-allowed) = true;
+ret = acc-init(mc);
+if (ret 0) {
+*(acc-allowed) = false;
+}
+return ret;
+}
+
int configure_accelerator(MachineClass *mc)
{
const char *p;
@@ -87,14 +98,12 @@ int configure_accelerator(MachineClass *mc)
acc-name);
continue;
}
-*(acc-allowed) = true;
-ret = acc-init(mc);
+ret = accel_init(acc, mc);
if (ret 0) {
init_failed = true;
fprintf(stderr, failed to initialize %s: %s\n,
acc-name,
strerror(-ret));
-*(acc-allowed) = false;
} else {
accel_initialised = true;
}
--
1.9.3
[Qemu-devel] [PATCH 129/156] block/sheepdog: Plug memory leak in sd_snapshot_create()
From: Markus Armbruster arm...@redhat.com Has always been leaky. Spotted by Coverity. Signed-off-by: Markus Armbruster arm...@redhat.com Reviewed-by: Benoit Canet ben...@irqsave.net Signed-off-by: Kevin Wolf kw...@redhat.com (cherry picked from commit 2df5fee2dbd56a9c34afd6d7df6744da2d951ccb) Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com --- block/sheepdog.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/block/sheepdog.c b/block/sheepdog.c index ef387de..43a23df 100644 --- a/block/sheepdog.c +++ b/block/sheepdog.c @@ -2082,6 +2082,7 @@ static int sd_snapshot_create(BlockDriverState *bs, QEMUSnapshotInfo *sn_info) strncpy(s-inode.tag, sn_info-name, sizeof(s-inode.tag)); /* we don't need to update entire object */ datalen = SD_INODE_SIZE - sizeof(s-inode.data_vdi_id); +inode = g_malloc(datalen); /* refresh inode. */ fd = connect_to_sdog(s); @@ -2105,8 +2106,6 @@ static int sd_snapshot_create(BlockDriverState *bs, QEMUSnapshotInfo *sn_info) goto cleanup; } -inode = (SheepdogInode *)g_malloc(datalen); - ret = read_object(fd, (char *)inode, vid_to_vdi_oid(new_vid), s-inode.nr_copies, datalen, 0, s-cache_flags); @@ -2120,6 +2119,7 @@ static int sd_snapshot_create(BlockDriverState *bs, QEMUSnapshotInfo *sn_info) s-inode.name, s-inode.snap_id, s-inode.vdi_id); cleanup: +g_free(inode); closesocket(fd); return ret; } -- 1.9.1
[Qemu-devel] [PATCH 095/156] qcow2: Zero-initialise first cluster for new images
From: Kevin Wolf kw...@redhat.com
Strictly speaking, this is only required for has_zero_init() == false,
but it's easy enough to just do a cluster-aligned write that is padded
with zeros after the header.
This fixes that after 'qemu-img create' header extensions are attempted
to be parsed that are really just random leftover data.
Cc: qemu-sta...@nongnu.org
Signed-off-by: Kevin Wolf kw...@redhat.com
Reviewed-by: Fam Zheng f...@redhat.com
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
(cherry picked from commit f8413b3c23b08a547ce18609acc6fae5fd04ed5c)
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
block/qcow2.c | 36
1 file changed, 20 insertions(+), 16 deletions(-)
diff --git a/block/qcow2.c b/block/qcow2.c
index 3e620f2..3daf019 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -1586,7 +1586,7 @@ static int qcow2_create2(const char *filename, int64_t
total_size,
* size for any qcow2 image.
*/
BlockDriverState* bs;
-QCowHeader header;
+QCowHeader *header;
uint8_t* refcount_table;
Error *local_err = NULL;
int ret;
@@ -1604,30 +1604,34 @@ static int qcow2_create2(const char *filename, int64_t
total_size,
}
/* Write the header */
-memset(header, 0, sizeof(header));
-header.magic = cpu_to_be32(QCOW_MAGIC);
-header.version = cpu_to_be32(version);
-header.cluster_bits = cpu_to_be32(cluster_bits);
-header.size = cpu_to_be64(0);
-header.l1_table_offset = cpu_to_be64(0);
-header.l1_size = cpu_to_be32(0);
-header.refcount_table_offset = cpu_to_be64(cluster_size);
-header.refcount_table_clusters = cpu_to_be32(1);
-header.refcount_order = cpu_to_be32(3 + REFCOUNT_SHIFT);
-header.header_length = cpu_to_be32(sizeof(header));
+QEMU_BUILD_BUG_ON((1 MIN_CLUSTER_BITS) sizeof(*header));
+header = g_malloc0(cluster_size);
+*header = (QCowHeader) {
+.magic = cpu_to_be32(QCOW_MAGIC),
+.version= cpu_to_be32(version),
+.cluster_bits = cpu_to_be32(cluster_bits),
+.size = cpu_to_be64(0),
+.l1_table_offset= cpu_to_be64(0),
+.l1_size= cpu_to_be32(0),
+.refcount_table_offset = cpu_to_be64(cluster_size),
+.refcount_table_clusters= cpu_to_be32(1),
+.refcount_order = cpu_to_be32(3 + REFCOUNT_SHIFT),
+.header_length = cpu_to_be32(sizeof(*header)),
+};
if (flags BLOCK_FLAG_ENCRYPT) {
-header.crypt_method = cpu_to_be32(QCOW_CRYPT_AES);
+header-crypt_method = cpu_to_be32(QCOW_CRYPT_AES);
} else {
-header.crypt_method = cpu_to_be32(QCOW_CRYPT_NONE);
+header-crypt_method = cpu_to_be32(QCOW_CRYPT_NONE);
}
if (flags BLOCK_FLAG_LAZY_REFCOUNTS) {
-header.compatible_features |=
+header-compatible_features |=
cpu_to_be64(QCOW2_COMPAT_LAZY_REFCOUNTS);
}
-ret = bdrv_pwrite(bs, 0, header, sizeof(header));
+ret = bdrv_pwrite(bs, 0, header, cluster_size);
+g_free(header);
if (ret 0) {
error_setg_errno(errp, -ret, Could not write qcow2 header);
goto out;
--
1.9.1
Re: [Qemu-devel] [RFC PATCH V5 0/3] Support xen HVM direct kernel boot
On Mon, 2014-07-07 at 14:34 +0800, Chunyan Liu wrote: Updated current patch series for working with qemu-xen and default BIOS (seabios), to make it in good shape. Stubdom support will be continued. This series is all acked and hasn't really felt RFC for a few iterations now. I suppose the xen side stuff really ought to wait for the qemu side to be accepted, which in turn is waiting for qemu's freeze to finish and a new development cycle to open. Does that sound right? Ian.
[Qemu-devel] [RFC 06/25] accel: Use QOM classes for accel types
Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
hw/core/accel.c| 117 ++---
include/hw/accel.h | 27 +
2 files changed, 120 insertions(+), 24 deletions(-)
diff --git a/hw/core/accel.c b/hw/core/accel.c
index 7f9b715..b42335c 100644
--- a/hw/core/accel.c
+++ b/hw/core/accel.c
@@ -30,6 +30,7 @@
#include sysemu/kvm.h
#include sysemu/qtest.h
#include hw/xen/xen.h
+#include qom/object.h
int tcg_tb_size;
static bool tcg_allowed = true;
@@ -40,32 +41,20 @@ static int tcg_init(MachineClass *mc)
return 0;
}
-typedef struct AccelType {
-const char *opt_name;
-const char *name;
-int (*available)(void);
-int (*init)(MachineClass *mc);
-bool *allowed;
-} AccelType;
-
-static AccelType accel_list[] = {
-{ tcg, tcg, tcg_available, tcg_init, tcg_allowed },
-{ xen, Xen, xen_available, xen_init, xen_allowed },
-{ kvm, KVM, kvm_available, kvm_init, kvm_allowed },
-{ qtest, QTest, qtest_available, qtest_init_accel, qtest_allowed },
+static const TypeInfo accel_type = {
+.name = TYPE_ACCEL,
+.parent = TYPE_OBJECT,
+.class_size = sizeof(AccelClass),
+.instance_size = sizeof(AccelState),
};
-/* Lookup AccelType from opt_name. Returns NULL if not found */
-static AccelType *accel_find(const char *opt_name)
+/* Lookup AccelClass from opt_name. Returns NULL if not found */
+static AccelClass *accel_find(const char *opt_name)
{
-int i;
-for (i = 0; i ARRAY_SIZE(accel_list); i++) {
-AccelType *acc = accel_list[i];
-if (acc-opt_name strcmp(acc-opt_name, opt_name) == 0) {
-return acc;
-}
-}
-return NULL;
+char *class_name = g_strdup_printf(%s-accel, opt_name);
+AccelClass *ac = ACCEL_CLASS(object_class_by_name(class_name));
+g_free(class_name);
+return ac;
}
int configure_accelerator(MachineClass *mc)
@@ -75,7 +64,7 @@ int configure_accelerator(MachineClass *mc)
int ret;
bool accel_initialised = false;
bool init_failed = false;
-AccelType *acc = NULL;
+AccelClass *acc = NULL;
p = qemu_opt_get(qemu_get_machine_opts(), accel);
if (p == NULL) {
@@ -124,3 +113,83 @@ int configure_accelerator(MachineClass *mc)
return !accel_initialised;
}
+
+
+static void tcg_accel_class_init(ObjectClass *oc, void *data)
+{
+AccelClass *ac = ACCEL_CLASS(oc);
+ac-name = tcg;
+ac-available = tcg_available;
+ac-init = tcg_init;
+ac-allowed = tcg_allowed;
+}
+
+#define TYPE_TCG_ACCEL tcg-accel
+
+static const TypeInfo tcg_accel_type = {
+.name = TYPE_TCG_ACCEL,
+.parent = TYPE_ACCEL,
+.class_init = tcg_accel_class_init,
+};
+
+static void xen_accel_class_init(ObjectClass *oc, void *data)
+{
+AccelClass *ac = ACCEL_CLASS(oc);
+ac-name = Xen;
+ac-available = xen_available;
+ac-init = xen_init;
+ac-allowed = xen_allowed;
+}
+
+#define TYPE_XEN_ACCEL xen-accel
+
+static const TypeInfo xen_accel_type = {
+.name = TYPE_XEN_ACCEL,
+.parent = TYPE_ACCEL,
+.class_init = xen_accel_class_init,
+};
+
+static void kvm_accel_class_init(ObjectClass *oc, void *data)
+{
+AccelClass *ac = ACCEL_CLASS(oc);
+ac-name = KVM;
+ac-available = kvm_available;
+ac-init = kvm_init;
+ac-allowed = kvm_allowed;
+}
+
+#define TYPE_KVM_ACCEL kvm-accel
+
+static const TypeInfo kvm_accel_type = {
+.name = TYPE_KVM_ACCEL,
+.parent = TYPE_ACCEL,
+.class_init = kvm_accel_class_init,
+};
+
+static void qtest_accel_class_init(ObjectClass *oc, void *data)
+{
+AccelClass *ac = ACCEL_CLASS(oc);
+ac-name = QTest;
+ac-available = qtest_available;
+ac-init = qtest_init_accel;
+ac-allowed = qtest_allowed;
+}
+
+#define TYPE_QTEST_ACCEL qtest-accel
+
+static const TypeInfo qtest_accel_type = {
+.name = TYPE_QTEST_ACCEL,
+.parent = TYPE_ACCEL,
+.class_init = qtest_accel_class_init,
+};
+
+static void register_accel_types(void)
+{
+type_register_static(accel_type);
+type_register_static(tcg_accel_type);
+type_register_static(xen_accel_type);
+type_register_static(kvm_accel_type);
+type_register_static(qtest_accel_type);
+}
+
+type_init(register_accel_types);
diff --git a/include/hw/accel.h b/include/hw/accel.h
index 5537d74..01f9831 100644
--- a/include/hw/accel.h
+++ b/include/hw/accel.h
@@ -24,6 +24,33 @@
#define HW_ACCEL_H
#include qemu/typedefs.h
+#include qom/object.h
+
+typedef struct AccelState {
+/* private */
+Object parent_obj;
+} AccelState;
+
+typedef struct AccelClass {
+/* private */
+ObjectClass parent_class;
+/* public */
+
+const char *opt_name;
+const char *name;
+int (*available)(void);
+int (*init)(MachineClass *mc);
+bool *allowed;
+} AccelClass;
+
+#define TYPE_ACCEL accel
+
+#define ACCEL_CLASS(klass) \
+OBJECT_CLASS_CHECK(AccelClass, (klass), TYPE_ACCEL)
+#define ACCEL(obj) \
+OBJECT_CHECK(AccelState, (obj), TYPE_ACCEL)
+#define
[Qemu-devel] [PATCH 087/156] qcow2: Check header_length (CVE-2014-0144)
From: Kevin Wolf kw...@redhat.com
This fixes an unbounded allocation for s-unknown_header_fields.
Signed-off-by: Kevin Wolf kw...@redhat.com
Reviewed-by: Max Reitz mre...@redhat.com
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
(cherry picked from commit 24342f2cae47d03911e346fe1e520b00dc2818e0)
Conflicts:
tests/qemu-iotests/group
*fixed context mismatches in group file
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
block/qcow2.c | 34 +++---
tests/qemu-iotests/080 | 61 ++
tests/qemu-iotests/080.out | 9 +++
tests/qemu-iotests/group | 1 +
4 files changed, 96 insertions(+), 9 deletions(-)
create mode 100755 tests/qemu-iotests/080
create mode 100644 tests/qemu-iotests/080.out
diff --git a/block/qcow2.c b/block/qcow2.c
index f2897b6..e4280a2 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -463,6 +463,18 @@ static int qcow2_open(BlockDriverState *bs, QDict
*options, int flags,
s-qcow_version = header.version;
+/* Initialise cluster size */
+if (header.cluster_bits MIN_CLUSTER_BITS ||
+header.cluster_bits MAX_CLUSTER_BITS) {
+error_setg(errp, Unsupported cluster size: 2^%i,
header.cluster_bits);
+ret = -EINVAL;
+goto fail;
+}
+
+s-cluster_bits = header.cluster_bits;
+s-cluster_size = 1 s-cluster_bits;
+s-cluster_sectors = 1 (s-cluster_bits - 9);
+
/* Initialise version 3 header fields */
if (header.version == 2) {
header.incompatible_features= 0;
@@ -476,6 +488,18 @@ static int qcow2_open(BlockDriverState *bs, QDict
*options, int flags,
be64_to_cpus(header.autoclear_features);
be32_to_cpus(header.refcount_order);
be32_to_cpus(header.header_length);
+
+if (header.header_length 104) {
+error_setg(errp, qcow2 header too short);
+ret = -EINVAL;
+goto fail;
+}
+}
+
+if (header.header_length s-cluster_size) {
+error_setg(errp, qcow2 header exceeds cluster size);
+ret = -EINVAL;
+goto fail;
}
if (header.header_length sizeof(header)) {
@@ -532,12 +556,6 @@ static int qcow2_open(BlockDriverState *bs, QDict
*options, int flags,
}
s-refcount_order = header.refcount_order;
-if (header.cluster_bits MIN_CLUSTER_BITS ||
-header.cluster_bits MAX_CLUSTER_BITS) {
-error_setg(errp, Unsupported cluster size: 2^%i,
header.cluster_bits);
-ret = -EINVAL;
-goto fail;
-}
if (header.crypt_method QCOW_CRYPT_AES) {
error_setg(errp, Unsupported encryption method: %i,
header.crypt_method);
@@ -548,9 +566,7 @@ static int qcow2_open(BlockDriverState *bs, QDict *options,
int flags,
if (s-crypt_method_header) {
bs-encrypted = 1;
}
-s-cluster_bits = header.cluster_bits;
-s-cluster_size = 1 s-cluster_bits;
-s-cluster_sectors = 1 (s-cluster_bits - 9);
+
s-l2_bits = s-cluster_bits - 3; /* L2 is always one cluster */
s-l2_size = 1 s-l2_bits;
bs-total_sectors = header.size / 512;
diff --git a/tests/qemu-iotests/080 b/tests/qemu-iotests/080
new file mode 100755
index 000..6512701
--- /dev/null
+++ b/tests/qemu-iotests/080
@@ -0,0 +1,61 @@
+#!/bin/bash
+#
+# qcow2 format input validation tests
+#
+# Copyright (C) 2013 Red Hat, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see http://www.gnu.org/licenses/.
+#
+
+# creator
+owner=kw...@redhat.com
+
+seq=`basename $0`
+echo QA output created by $seq
+
+here=`pwd`
+tmp=/tmp/$$
+status=1 # failure is the default!
+
+_cleanup()
+{
+ _cleanup_test_img
+}
+trap _cleanup; exit \$status 0 1 2 3 15
+
+# get standard environment, filters and checks
+. ./common.rc
+. ./common.filter
+
+_supported_fmt qcow2
+_supported_proto generic
+_supported_os Linux
+
+header_size=104
+offset_header_size=100
+offset_ext_magic=$header_size
+offset_ext_size=$((header_size + 4))
+
+echo
+echo == Huge header size ==
+_make_test_img 64M
+poke_file $TEST_IMG $offset_header_size \xff\xff\xff\xff
+{ $QEMU_IO -c read 0 512 $TEST_IMG; } 21 | _filter_qemu_io |
_filter_testdir
+poke_file $TEST_IMG $offset_header_size \x7f\xff\xff\xff
+{ $QEMU_IO -c read 0 512 $TEST_IMG; } 21 | _filter_qemu_io |
_filter_testdir
+
+# success, all done
+echo *** done
+rm -f $seq.full
+status=0
diff
[Qemu-devel] [PULL for-2.1 02/22] block: Fix bdrv_is_allocated() return value
bdrv_is_allocated() should return either 0 or 1 in successful cases.
We're lucky that currently, the callers that rely on this (e.g. because
they check for ret == 1) don't seem to break badly. They just might skip
some optimisation or in the case of qemu-io 'map' print separate lines
where a single line would suffice. In theory, a wrong allocation status
could lead to image corruption with certain operations, so let's fix
this quickly.
Signed-off-by: Kevin Wolf kw...@redhat.com
Reviewed-by: Eric Blake ebl...@redhat.com
---
block.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block.c b/block.c
index 8800a6b..c9629a4 100644
--- a/block.c
+++ b/block.c
@@ -4040,7 +4040,7 @@ int coroutine_fn bdrv_is_allocated(BlockDriverState *bs,
int64_t sector_num,
if (ret 0) {
return ret;
}
-return (ret BDRV_BLOCK_ALLOCATED);
+return !!(ret BDRV_BLOCK_ALLOCATED);
}
/*
--
1.8.3.1
[Qemu-devel] [PATCH v2 05/10] arm/nwfps: replace cpsr_write with set_condition_codes
This is a pre-cursor to removing the cpsr_write function completely from
the code base. set_condition_codes() only affects the integer condition
flags.
Signed-off-by: Alex Bennée alex.ben...@linaro.org
---
v2
- fix nwfpe set_condition_codes
diff --git a/linux-user/arm/nwfpe/fpa11.h b/linux-user/arm/nwfpe/fpa11.h
index bb9ac65..c7883d0 100644
--- a/linux-user/arm/nwfpe/fpa11.h
+++ b/linux-user/arm/nwfpe/fpa11.h
@@ -108,7 +108,7 @@ static inline void writeRegister(unsigned int x, unsigned
int y)
static inline void writeConditionCodes(unsigned int x)
{
-cpsr_write(user_registers,x,CPSR_NZCV);
+set_condition_codes(user_registers, x);
}
#define ARM_REG_PC 15
--
2.0.1
Re: [Qemu-devel] [PATCH 16/46] Add migration-capability boolean for postcopy-ram.
* Paolo Bonzini (pbonz...@redhat.com) wrote: Il 07/07/2014 22:23, Dr. David Alan Gilbert ha scritto: I think what I need to do for that is: 1) As for precopy add the option not to start the destination CPU on entry to postcopy; I think that's OK, because we can carry on in postcopy mode even if the destination CPU isn't running, we just won't generate page requests. Admittedly I don't quite understand how (1) is supposed to interact with device state. This is just passing -S on the destination side. Device state is treated the same as without -S and can still generate page requests. The only difference is whether you have a vm_start() or not. Good, that sounds easy enough. I think it should be possible to restart the VM on the source side after postcopy migration, as long as migration has failed or has been canceled. Whether that makes sense or causes dire disk corruption depends on the particular scenario, but then the same holds for precopy and we don't try at all to prevent cont at the end of migration. It makes it much easier for libvirt to restart the source if it cannot continue on the destination. Interesting; Andrea fell into accidentally starting his source and was somewhat surprised. I was just going to add the RAN_STATE_MEMORY_STALE that Lei Li added in the exec-migration patchset. Dave Paolo -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
[Qemu-devel] [PATCH 3/4 v7] ppc: Add software breakpoint support
This patch allow insert/remove software breakpoint.
When QEMU is not able to handle debug exception then we inject program
exception to guest because for software breakpoint QEMU uses a ehpriv-1
instruction;
So there cannot be any reason that we are in qemu with exit reason
KVM_EXIT_DEBUG for guest set debug exception, only possibility is
guest executed ehpriv-1 privilege instruction and that's why we are
injecting program exception.
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
v6-v7
- Moved exception injection to this patch
- Inject the fault directly
target-ppc/kvm.c | 87 +++-
1 file changed, 73 insertions(+), 14 deletions(-)
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index e00a20f..afa2291 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -1275,6 +1275,69 @@ static int kvmppc_handle_dcr_write(CPUPPCState *env,
uint32_t dcrn, uint32_t dat
return 0;
}
+int kvm_arch_insert_sw_breakpoint(CPUState *cs, struct kvm_sw_breakpoint *bp)
+{
+/* Mixed endian case is not handled */
+uint32_t sc = debug_inst_opcode;
+
+if (cpu_memory_rw_debug(cs, bp-pc, (uint8_t *)bp-saved_insn,
+sizeof(sc), 0) ||
+cpu_memory_rw_debug(cs, bp-pc, (uint8_t *)sc, sizeof(sc), 1)) {
+return -EINVAL;
+}
+
+return 0;
+}
+
+int kvm_arch_remove_sw_breakpoint(CPUState *cs, struct kvm_sw_breakpoint *bp)
+{
+uint32_t sc;
+
+if (cpu_memory_rw_debug(cs, bp-pc, (uint8_t *)sc, sizeof(sc), 0) ||
+sc != debug_inst_opcode ||
+cpu_memory_rw_debug(cs, bp-pc, (uint8_t *)bp-saved_insn,
+sizeof(sc), 1)) {
+return -EINVAL;
+}
+
+return 0;
+}
+
+void kvm_arch_update_guest_debug(CPUState *cs, struct kvm_guest_debug *dbg)
+{
+/* Software Breakpoint updates */
+if (kvm_sw_breakpoints_active(cs)) {
+dbg-control |= KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_SW_BP;
+}
+}
+
+static int kvm_handle_debug(PowerPCCPU *cpu, struct kvm_run *run)
+{
+CPUState *cs = CPU(cpu);
+CPUPPCState *env = cpu-env;
+struct kvm_debug_exit_arch *arch_info = run-debug.arch;
+int handle = 0;
+
+if (kvm_find_sw_breakpoint(cs, arch_info-address)) {
+handle = 1;
+} else {
+/* QEMU is not able to handle debug exception, so inject
+ * program exception to guest;
+ * Yes program exception NOT debug exception !!
+ * For software breakpoint QEMU uses a ehpriv-1 instruction;
+ * So there cannot be any reason that we are here for guest
+ * set debug exception, only possibility is guest executed a
+ * privilege instruction and that's why we are injecting
+ * program exception.
+ */
+ cs-exception_index = POWERPC_EXCP_PROGRAM;
+ env-error_code = POWERPC_EXCP_INVAL;
+ ppc_cpu_do_interrupt(cs);
+}
+
+return handle;
+}
+
int kvm_arch_handle_exit(CPUState *cs, struct kvm_run *run)
{
PowerPCCPU *cpu = POWERPC_CPU(cs);
@@ -1315,6 +1378,16 @@ int kvm_arch_handle_exit(CPUState *cs, struct kvm_run
*run)
ret = 0;
break;
+case KVM_EXIT_DEBUG:
+DPRINTF(handle debug exception\n);
+if (kvm_handle_debug(cpu, run)) {
+ret = EXCP_DEBUG;
+break;
+}
+/* re-enter, this exception was guest-internal */
+ret = 0;
+break;
+
default:
fprintf(stderr, KVM: unknown exit reason %d\n, run-exit_reason);
ret = -1;
@@ -2003,16 +2076,6 @@ void kvm_arch_init_irq_routing(KVMState *s)
{
}
-int kvm_arch_insert_sw_breakpoint(CPUState *cpu, struct kvm_sw_breakpoint *bp)
-{
-return -EINVAL;
-}
-
-int kvm_arch_remove_sw_breakpoint(CPUState *cpu, struct kvm_sw_breakpoint *bp)
-{
-return -EINVAL;
-}
-
int kvm_arch_insert_hw_breakpoint(target_ulong addr, target_ulong len, int
type)
{
return -EINVAL;
@@ -2027,10 +2090,6 @@ void kvm_arch_remove_all_hw_breakpoints(void)
{
}
-void kvm_arch_update_guest_debug(CPUState *cpu, struct kvm_guest_debug *dbg)
-{
-}
-
struct kvm_get_htab_buf {
struct kvm_get_htab_header header;
/*
--
1.9.3
[Qemu-devel] [PATCH 096/156] qcow2: Don't rely on free_cluster_index in alloc_refcount_block() (CVE-2014-0147)
From: Kevin Wolf kw...@redhat.com
free_cluster_index is only correct if update_refcount() was called from
an allocation function, and even there it's brittle because it's used to
protect unfinished allocations which still have a refcount of 0 - if it
moves in the wrong place, the unfinished allocation can be corrupted.
So not using it any more seems to be a good idea. Instead, use the
first requested cluster to do the calculations. Return -EAGAIN if
unfinished allocations could become invalid and let the caller restart
its search for some free clusters.
The context of creating a snapsnot is one situation where
update_refcount() is called outside of a cluster allocation. For this
case, the change fixes a buffer overflow if a cluster is referenced in
an L2 table that cannot be represented by an existing refcount block.
(new_table[refcount_table_index] was out of bounds)
[Bump the qemu-iotests 026 refblock_alloc.write leak count from 10 to
11.
--Stefan]
Signed-off-by: Kevin Wolf kw...@redhat.com
Reviewed-by: Max Reitz mre...@redhat.com
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
(cherry picked from commit b106ad9185f35fc4ad669555ad0e79e276083bd7)
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
block/qcow2-refcount.c | 72 --
block/qcow2.c | 11 +++
tests/qemu-iotests/026.out | 6 ++--
tests/qemu-iotests/044.out | 2 +-
tests/qemu-iotests/080 | 11 +++
tests/qemu-iotests/080.out | 7 +
6 files changed, 65 insertions(+), 44 deletions(-)
diff --git a/block/qcow2-refcount.c b/block/qcow2-refcount.c
index 6c212c9..22dfb2d 100644
--- a/block/qcow2-refcount.c
+++ b/block/qcow2-refcount.c
@@ -193,10 +193,11 @@ static int alloc_refcount_block(BlockDriverState *bs,
* they can describe them themselves.
*
* - We need to consider that at this point we are inside update_refcounts
- * and doing the initial refcount increase. This means that some clusters
- * have already been allocated by the caller, but their refcount isn't
- * accurate yet. free_cluster_index tells us where this allocation ends
- * as long as we don't overwrite it by freeing clusters.
+ * and potentially doing an initial refcount increase. This means that
+ * some clusters have already been allocated by the caller, but their
+ * refcount isn't accurate yet. If we allocate clusters for metadata, we
+ * need to return -EAGAIN to signal the caller that it needs to restart
+ * the search for free clusters.
*
* - alloc_clusters_noref and qcow2_free_clusters may load a different
* refcount block into the cache
@@ -281,7 +282,10 @@ static int alloc_refcount_block(BlockDriverState *bs,
}
s-refcount_table[refcount_table_index] = new_block;
-return 0;
+
+/* The new refcount block may be where the caller intended to put its
+ * data, so let it restart the search. */
+return -EAGAIN;
}
ret = qcow2_cache_put(bs, s-refcount_block_cache, (void**)
refcount_block);
@@ -304,8 +308,7 @@ static int alloc_refcount_block(BlockDriverState *bs,
/* Calculate the number of refcount blocks needed so far */
uint64_t refcount_block_clusters = 1 (s-cluster_bits - REFCOUNT_SHIFT);
-uint64_t blocks_used = (s-free_cluster_index +
-refcount_block_clusters - 1) / refcount_block_clusters;
+uint64_t blocks_used = DIV_ROUND_UP(cluster_index,
refcount_block_clusters);
/* And now we need at least one block more for the new metadata */
uint64_t table_size = next_refcount_table_size(s, blocks_used + 1);
@@ -338,8 +341,6 @@ static int alloc_refcount_block(BlockDriverState *bs,
uint16_t *new_blocks = g_malloc0(blocks_clusters * s-cluster_size);
uint64_t *new_table = g_malloc0(table_size * sizeof(uint64_t));
-assert(meta_offset = (s-free_cluster_index * s-cluster_size));
-
/* Fill the new refcount table */
memcpy(new_table, s-refcount_table,
s-refcount_table_size * sizeof(uint64_t));
@@ -402,18 +403,19 @@ static int alloc_refcount_block(BlockDriverState *bs,
s-refcount_table_size = table_size;
s-refcount_table_offset = table_offset;
-/* Free old table. Remember, we must not change free_cluster_index */
-uint64_t old_free_cluster_index = s-free_cluster_index;
+/* Free old table. */
qcow2_free_clusters(bs, old_table_offset, old_table_size *
sizeof(uint64_t),
QCOW2_DISCARD_OTHER);
-s-free_cluster_index = old_free_cluster_index;
ret = load_refcount_block(bs, new_block, (void**) refcount_block);
if (ret 0) {
return ret;
}
-return 0;
+/* If we were trying to do the initial refcount update for some cluster
+ * allocation, we might have used the same clusters to store newly
+ * allocated metadata. Make the caller search some new space. */
+return -EAGAIN;
