Re: [Qemu-devel] [PATCH] numa: fix comment
On Tue, 24 Jun 2014 08:51:23 +0300
Michael S. Tsirkin m...@redhat.com wrote:
s/if given for/is given for/;
Reported-by: Hu Tao hu...@cn.fujitsu.com
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
numa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/numa.c b/numa.c
index 47049a5..6c2eae7 100644
--- a/numa.c
+++ b/numa.c
@@ -161,7 +161,7 @@ void set_numa_nodes(void)
nb_numa_nodes = MAX_NODES;
}
-/* If no memory size if given for any node, assume the default case
+/* If no memory size is given for any node, assume the default case
* and distribute the available memory equally across all nodes
*/
for (i = 0; i nb_numa_nodes; i++) {
Reviewed-by: Igor Mammedov imamm...@redhat.com
Re: [Qemu-devel] [RFC] Functions bus_foreach and device_find from libqos virtio API
On Mon, 06/23 16:55, Marc Marí wrote:
diff --git a/tests/Makefile b/tests/Makefile
index 4caf7de..b85a036 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -282,6 +282,7 @@ libqos-obj-y += tests/libqos/i2c.o
libqos-pc-obj-y = $(libqos-obj-y) tests/libqos/pci-pc.o
libqos-pc-obj-y += tests/libqos/malloc-pc.o
libqos-omap-obj-y = $(libqos-obj-y) tests/libqos/i2c-omap.o
+libqos-virtio-obj-y = $(libqos-obj-y) $(libqos-pc-obj-y)
tests/libqos/virtio-pci.o
$(libqos-pc-obj-y) has $(libqos-obj-y) itself, two lines above. So no need to
add again.
diff --git a/tests/libqos/virtio-pci.c b/tests/libqos/virtio-pci.c
new file mode 100644
index 000..62c238f
--- /dev/null
+++ b/tests/libqos/virtio-pci.c
@@ -0,0 +1,123 @@
+/*
+ * libqos virtio definitions
PCI
+ *
+ * Copyright (c) 2014 Marc Marí
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
diff --git a/tests/libqos/virtio-pci.h b/tests/libqos/virtio-pci.h
new file mode 100644
index 000..d92bcf2
--- /dev/null
+++ b/tests/libqos/virtio-pci.h
@@ -0,0 +1,40 @@
+/*
+ * libqos virtio PCI definitions
+ *
+ * Copyright (c) 2014 Marc Marí
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#ifndef LIBQOS_VIRTIO_PCI_H
+#define LIBQOS_VIRTIO_PCI_H
+
+#include libqos/virtio.h
+
+void qvirtio_pci_notify(QVirtioDevice *d, uint16_t vector);
+void qvirtio_pci_get_config(QVirtioDevice *d, void *config);
+void qvirtio_pci_set_config(QVirtioDevice *d, void *config);
+uint32_t qvirtio_pci_get_features(QVirtioDevice *d);
+uint8_t qvirtio_pci_get_status(QVirtioDevice *d);
+void qvirtio_pci_set_status(QVirtioDevice *d, uint8_t val);
+void qvirtio_pci_reset(QVirtioDevice *d);
+uint8_t qvirtio_pci_query_isr(QVirtioDevice *d);
+void qvirtio_pci_foreach(uint16_t device_id,
+void (*func)(QVirtioDevice *d, void *data), void *data);
+QVirtioDevice *qvirtio_pci_device_find(uint16_t device_id);
+
+const QVirtioBus qvirtio_pci = {
+.notify = qvirtio_pci_notify,
+.get_config = qvirtio_pci_get_config,
+.set_config = qvirtio_pci_set_config,
+.get_features = qvirtio_pci_get_features,
+.get_status = qvirtio_pci_get_status,
+.set_status = qvirtio_pci_set_status,
+.reset = qvirtio_pci_reset,
+.query_isr = qvirtio_pci_query_isr,
+.bus_foreach = qvirtio_pci_foreach,
+.device_find = qvirtio_pci_device_find,
+};
Each source file to include this header will define its own copy of
qvirtio_pci. Please move this to tests/libqos/virtio-pci.c. And can you make
the implementation functions static, because they are already accessed through
members of qvirtio_pci?
+
+#endif
diff --git a/tests/libqos/virtio.h b/tests/libqos/virtio.h
new file mode 100644
index 000..838aae4
--- /dev/null
+++ b/tests/libqos/virtio.h
snip
+/*QVirtioBus *qvirtio_pci_init();
+QVirtioBus *qvirtio_mmio_init();
+QVirtioBus *qvirtio_ccw_init();*/
When you drop RFC, please drop this,
+
+/*
+I'm not sure what implementation of VirtQueue is better, QEMU's or Linux's. I
+think QEMU implementation is better, because it will be easier to connect the
+QEMU Virtqueue with the Libaos VirtQueue.
+
+The functions to use the VirtQueue are the ones I think necessary in Libqos,
but
+probably there are some missing and some others that are not necessary.
+*/
and this,
diff --git a/tests/virtio-blk-test.c b/tests/virtio-blk-test.c
index d53f875..4f5b1e0 100644
--- a/tests/virtio-blk-test.c
+++ b/tests/virtio-blk-test.c
@@ -2,6 +2,7 @@
* QTest testcase for VirtIO Block Device
*
* Copyright (c) 2014 SUSE LINUX Products GmbH
+ * Copyright (c) 2014 Marc Marí
*
* This work is licensed under the terms of the GNU GPL, version 2 or later.
* See the COPYING file in the top-level directory.
@@ -9,26 +10,51 @@
#include glib.h
#include string.h
+#include stdlib.h
+#include unistd.h
+#include stdio.h
#include libqtest.h
-#include qemu/osdep.h
+#include libqos/virtio.h
+/*#include qemu/osdep.h*/
and this.
-/* Tests only initialization so far. TODO: Replace with functional tests */
-static void pci_nop(void)
+#define TEST_IMAGE_SIZE (64 * 1024 * 1024)
+
+static char tmp_path[] = /tmp/qtest.XX;
+extern QVirtioBus qvirtio_pci;
+
+static void pci_basic(void)
{
+QVirtioDevice *dev;
+dev = qvirtio_pci.device_find(VIRTIO_BLK_DEVICE_ID);
+fprintf(stderr, Device: %x %x %x\n,
+dev-device_id, dev-location, dev-device_type);
}
int main(int argc, char **argv)
{
int ret;
+int fd;
+char test_start[100];
Depending on length of tmp_path, this looks quite close to an overflow ...
g_test_init(argc, argv, NULL);
-qtest_add_func(/virtio/blk/pci/nop, pci_nop);
+qtest_add_func(/virtio/blk/pci/basic,
Re: [Qemu-devel] [PATCH] openrisc: fix comment
On Tue, 24 Jun 2014 07:46:43 +0300 Michael S. Tsirkin m...@redhat.com wrote: Fix English in comment: s/the each/each/ s/ \*\// \*\// Signed-off-by: Michael S. Tsirkin m...@redhat.com --- target-openrisc/translate.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/target-openrisc/translate.c b/target-openrisc/translate.c index b728718..55ff935 100644 --- a/target-openrisc/translate.c +++ b/target-openrisc/translate.c @@ -531,14 +531,14 @@ static void dec_calc(DisasContext *dc, uint32_t insn) TCGv_i64 high = tcg_temp_new_i64(); TCGv_i32 sr_ove = tcg_temp_local_new_i32(); int lab = gen_new_label(); -/* Calculate the each result. */ +/* Calculate each result. */ tcg_gen_extu_i32_i64(tra, cpu_R[ra]); tcg_gen_extu_i32_i64(trb, cpu_R[rb]); tcg_gen_mul_i64(result, tra, trb); tcg_temp_free_i64(tra); tcg_temp_free_i64(trb); tcg_gen_shri_i64(high, result, TARGET_LONG_BITS); -/* Overflow or not. */ +/* Overflow or not. */ tcg_gen_brcondi_i64(TCG_COND_EQ, high, 0x, lab); tcg_gen_ori_tl(cpu_sr, cpu_sr, (SR_OV | SR_CY)); tcg_gen_andi_tl(sr_ove, cpu_sr, SR_OVE); Reviewed-by: Igor Mammedov imamm...@redhat.com
[Qemu-devel] [PATCH v1 1/1] char: cadence_uart: Convert to realize()
SysBusDevice::init is deprecated. Convert to Object::init and
Device::realize as prescribed by QOM conventions.
Signed-off-by: Alistair Francis alistair.fran...@xilinx.com
---
hw/char/cadence_uart.c | 29 -
1 files changed, 16 insertions(+), 13 deletions(-)
diff --git a/hw/char/cadence_uart.c b/hw/char/cadence_uart.c
index bf0c853..5a22a72 100644
--- a/hw/char/cadence_uart.c
+++ b/hw/char/cadence_uart.c
@@ -468,27 +468,30 @@ static void cadence_uart_reset(DeviceState *dev)
uart_update_status(s);
}
-static int cadence_uart_init(SysBusDevice *dev)
+static void candence_uart_realize(DeviceState *dev, Error **errp)
{
UartState *s = CADENCE_UART(dev);
-memory_region_init_io(s-iomem, OBJECT(s), uart_ops, s, uart, 0x1000);
-sysbus_init_mmio(dev, s-iomem);
-sysbus_init_irq(dev, s-irq);
-
-s-fifo_trigger_handle = timer_new_ns(QEMU_CLOCK_VIRTUAL,
-(QEMUTimerCB *)fifo_trigger_update, s);
-
-s-char_tx_time = (get_ticks_per_sec() / 9600) * 10;
-
s-chr = qemu_char_get_next_serial();
if (s-chr) {
qemu_chr_add_handlers(s-chr, uart_can_receive, uart_receive,
uart_event, s);
}
+}
-return 0;
+static void cadence_uart_init(Object *obj)
+{
+UartState *s = CADENCE_UART(obj);
+
+memory_region_init_io(s-iomem, obj, uart_ops, s, uart, 0x1000);
+sysbus_init_mmio(SYS_BUS_DEVICE(obj), s-iomem);
+sysbus_init_irq(SYS_BUS_DEVICE(obj), s-irq);
+
+s-fifo_trigger_handle = timer_new_ns(QEMU_CLOCK_VIRTUAL,
+(QEMUTimerCB *)fifo_trigger_update, s);
+
+s-char_tx_time = (get_ticks_per_sec() / 9600) * 10;
}
static int cadence_uart_post_load(void *opaque, int version_id)
@@ -520,9 +523,8 @@ static const VMStateDescription vmstate_cadence_uart = {
static void cadence_uart_class_init(ObjectClass *klass, void *data)
{
DeviceClass *dc = DEVICE_CLASS(klass);
-SysBusDeviceClass *sdc = SYS_BUS_DEVICE_CLASS(klass);
-sdc-init = cadence_uart_init;
+dc-realize = candence_uart_realize;
dc-vmsd = vmstate_cadence_uart;
dc-reset = cadence_uart_reset;
}
@@ -531,6 +533,7 @@ static const TypeInfo cadence_uart_info = {
.name = TYPE_CADENCE_UART,
.parent= TYPE_SYS_BUS_DEVICE,
.instance_size = sizeof(UartState),
+.instance_init = cadence_uart_init,
.class_init= cadence_uart_class_init,
};
--
1.7.1
Re: [Qemu-devel] [PATCH 3/7] spapr: Refactor spapr_populate_memory()
On 06/24/2014 03:40 AM, Nishanth Aravamudan wrote:
On 21.06.2014 [13:06:53 +1000], Alexey Kardashevskiy wrote:
On 06/21/2014 08:55 AM, Nishanth Aravamudan wrote:
On 16.06.2014 [17:53:49 +1000], Alexey Kardashevskiy wrote:
Current QEMU does not support memoryless NUMA nodes.
This prepares SPAPR for that.
This moves 2 calls of spapr_populate_memory_node() into
the existing loop which handles nodes other than than
the first one.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
hw/ppc/spapr.c | 31 +++
1 file changed, 11 insertions(+), 20 deletions(-)
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index cb3a10a..666b676 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -689,28 +689,13 @@ static void spapr_populate_memory_node(void *fdt,
int nodeid, hwaddr start,
static int spapr_populate_memory(sPAPREnvironment *spapr, void *fdt)
{
-hwaddr node0_size, mem_start, node_size;
+hwaddr mem_start, node_size;
int i;
-/* memory node(s) */
-if (nb_numa_nodes 1 node_mem[0] ram_size) {
-node0_size = node_mem[0];
-} else {
-node0_size = ram_size;
-}
-
-/* RMA */
-spapr_populate_memory_node(fdt, 0, 0, spapr-rma_size);
-
-/* RAM: Node 0 */
-if (node0_size spapr-rma_size) {
-spapr_populate_memory_node(fdt, 0, spapr-rma_size,
- node0_size - spapr-rma_size);
-}
-
-/* RAM: Node 1 and beyond */
-mem_start = node0_size;
-for (i = 1; i nb_numa_nodes; i++) {
+for (i = 0, mem_start = 0; i nb_numa_nodes; ++i) {
+if (!node_mem[i]) {
+continue;
+}
Doesn't this skip memoryless nodes? What actually puts the memoryless
node in the device-tree?
It does skip.
And if you were to put them in, wouldn't spapr_populate_memory_node()
fail because we'd be creating two nodes with memory@XXX where XXX is the
same (starting address) for both?
I cannot do this now - there is no way to tell from the command line
where I want NUMA node memory start from so I'll end up with multiple
nodes with the same name and QEMU won't start. When NUMA fixes reach
upstream, I'll try to work out something on top of that.
So in mst's tree, which I've rebased your patches, we have a struct
defining each NUMA node, which has a size (and the index is the nodeid).
I've got patches working that allow for sparse indexing, but I'm curious
what you think we should do for the naming.
There should be no nodes for memory@xxx in the device tree for memoryless
NUMA nodes so no problem with naming.
I can send out the patches,
with the caveat that architectures still need to fix the remaining
issues for memoryless nodes?
? If we do not change the existing behavior and just extending it, why will
there be a problem?
--
Alexey
Re: [Qemu-devel] [PATCH 3/7] spapr: Refactor spapr_populate_memory()
On 06/24/2014 01:08 PM, Nishanth Aravamudan wrote:
On 21.06.2014 [13:06:53 +1000], Alexey Kardashevskiy wrote:
On 06/21/2014 08:55 AM, Nishanth Aravamudan wrote:
On 16.06.2014 [17:53:49 +1000], Alexey Kardashevskiy wrote:
Current QEMU does not support memoryless NUMA nodes.
This prepares SPAPR for that.
This moves 2 calls of spapr_populate_memory_node() into
the existing loop which handles nodes other than than
the first one.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
hw/ppc/spapr.c | 31 +++
1 file changed, 11 insertions(+), 20 deletions(-)
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index cb3a10a..666b676 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -689,28 +689,13 @@ static void spapr_populate_memory_node(void *fdt,
int nodeid, hwaddr start,
static int spapr_populate_memory(sPAPREnvironment *spapr, void *fdt)
{
-hwaddr node0_size, mem_start, node_size;
+hwaddr mem_start, node_size;
int i;
-/* memory node(s) */
-if (nb_numa_nodes 1 node_mem[0] ram_size) {
-node0_size = node_mem[0];
-} else {
-node0_size = ram_size;
-}
-
-/* RMA */
-spapr_populate_memory_node(fdt, 0, 0, spapr-rma_size);
-
-/* RAM: Node 0 */
-if (node0_size spapr-rma_size) {
-spapr_populate_memory_node(fdt, 0, spapr-rma_size,
- node0_size - spapr-rma_size);
-}
-
-/* RAM: Node 1 and beyond */
-mem_start = node0_size;
-for (i = 1; i nb_numa_nodes; i++) {
+for (i = 0, mem_start = 0; i nb_numa_nodes; ++i) {
+if (!node_mem[i]) {
+continue;
+}
Doesn't this skip memoryless nodes? What actually puts the memoryless
node in the device-tree?
It does skip.
And if you were to put them in, wouldn't spapr_populate_memory_node()
fail because we'd be creating two nodes with memory@XXX where XXX is the
same (starting address) for both?
I cannot do this now - there is no way to tell from the command line where
I want NUMA node memory start from so I'll end up with multiple nodes with
the same name and QEMU won't start. When NUMA fixes reach upstream, I'll
try to work out something on top of that.
Ah I got something here. With the patches I just sent to enable sparse
NUMA nodes, plus your series rebased on top, here's what I see in a
Linux LPAR:
qemu-system-ppc64 -machine pseries,accel=kvm,usb=off -m 4096 -realtime
mlock=off -numa node,nodeid=3,mem=4096,cpus=2-3 -numa
node,nodeid=2,mem=0,cpus=0-1 -smp 4
info numa
2 nodes
node 2 cpus: 0 1
node 2 size: 0 MB
node 3 cpus: 2 3
node 3 size: 4096 MB
numactl --hardware
available: 3 nodes (0,2-3)
node 0 cpus:
node 0 size: 0 MB
node 0 free: 0 MB
node 2 cpus: 0 1
node 2 size: 0 MB
node 2 free: 0 MB
node 3 cpus: 2 3
node 3 size: 4073 MB
node 3 free: 3830 MB
node distances:
node 0 2 3
0: 10 40 40
2: 40 10 40
3: 40 40 10
The trick, it seems, is if you have a memoryless node, it needs to
have CPUs assigned to it.
Yep. The device tree does not have NUMA nodes, it only has CPUs and
memory@xxx (memory banks?) and the guest kernel has to parse
ibm,associativity and reconstruct the NUMA topology. If some node is not
mentioned in any ibm,associativity, it does not exist.
The CPU's ibm,associativity property will
make Linux set up the proper NUMA topology.
Thoughts? Should there be a check that every present NUMA node at
least either has CPUs or memory.
May be, I'll wait for NUMA stuff in upstream, apply your patch(es), my
patches and see what I get :)
It seems like if neither are present,
we can just hotplug them later?
hotplug what? NUMA nodes?
Does qemu support topology for PCI devices?
Nope.
--
Alexey
Re: [Qemu-devel] [PATCH] migration: static variables will not be reset at second migration
-Original Message-
From: Juan Quintela [mailto:quint...@redhat.com]
Sent: Friday, March 21, 2014 9:26 PM
To: Gonglei (Arei)
Cc: qemu-devel@nongnu.org; owass...@redhat.com; pbonz...@redhat.com;
ebl...@redhat.com; dgilb...@redhat.com; chenliang (T)
Subject: Re: [PATCH] migration: static variables will not be reset at second
migration
arei.gong...@huawei.com wrote:
From: ChenLiang chenlian...@huawei.com
The static variables in migration_bitmap_sync will not be reset in
the case of a second attempted migration.
Signed-off-by: ChenLiang chenlian...@huawei.com
Signed-off-by: Gonglei arei.gong...@huawei.com
Good catch. Applied..
Hi, Juan? Ping... please :)
Best regards,
-Gonglei
---
arch_init.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index 60c975d..10516cb 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -468,15 +468,23 @@ static void
migration_bitmap_sync_range(ram_addr_t start, ram_addr_t length)
/* Needs iothread lock! */
+/* Fix me: there are too many global variables used in migration process.
*/
+static int64_t start_time;
+static int64_t bytes_xfer_prev;
+static int64_t num_dirty_pages_period;
+
+static void migration_bitmap_sync_init(void)
+{
+start_time = 0;
+bytes_xfer_prev = 0;
+num_dirty_pages_period = 0;
+}
static void migration_bitmap_sync(void)
{
RAMBlock *block;
uint64_t num_dirty_pages_init = migration_dirty_pages;
MigrationState *s = migrate_get_current();
-static int64_t start_time;
-static int64_t bytes_xfer_prev;
-static int64_t num_dirty_pages_period;
int64_t end_time;
int64_t bytes_xfer_now;
@@ -733,6 +741,7 @@ static int ram_save_setup(QEMUFile *f, void
*opaque)
migration_dirty_pages = ram_pages;
mig_throttle_on = false;
dirty_rate_high_cnt = 0;
+migration_bitmap_sync_init();
if (migrate_use_xbzrle()) {
qemu_mutex_lock_iothread();
Re: [Qemu-devel] [question] Will qemu-2.0.0 be a longterm stablebranch?
Hi, all Which version is best for commercial product, qemu-2.0.0 or other versions? Any advices? Thanks, Zhang Haoyu Use one of the downstreams: Red Hat, Fedora, Debian all ship QEMU and have active QEMU maintainers developing the distribution. How to get the latest qemu distribution shipped by RedHat? Thanks, Zhang Haoyu -- MST
[Qemu-devel] Writing into guest memory from qemu
Hello I am attempting to write into the guest memory state (before the guest is launched) using the cpu_physical_memory_write function. While some values are being correctly written into the guest memory (confirmed by a cpu_physical_memory_read just after the write), some are not. Is there an explanation for this behavior? Or am I using the wrong function to accomplish what I want? Thanks in advance. Shubham Gupta
Re: [Qemu-devel] [RFC PATCH] numa: enable sparse node numbering
On Mon, 23 Jun 2014 12:33:10 -0700
Nishanth Aravamudan n...@linux.vnet.ibm.com wrote:
Add a present field to NodeInfo which indicates if a given nodeid was
present on the command-line or not. Current code relies on a memory
value being passed for a node to indicate presence, which is
insufficient in the presence of memoryless nodes or sparse numbering.
Adjust the iteration of various NUMA loops to use the maximum known NUMA
ID rather than the number of NUMA nodes.
Why would you need sparse numbering?
What task exactly are you trying to solve?
numa.c::set_numa_nodes() has become a bit more convoluted for
round-robin'ing the CPUs over known nodes when not specified by the
user.
Note that architecture-specific code still needs changes (forthcoming)
for both sparse node numbering and memoryless nodes.
Examples:
(1) qemu-system-x86_64 -enable-kvm -m 4096 -numa node,nodeid=3 -numa
node,nodeid=2 -smp 16
Before:
node 0 cpus: 0 2 4 6 8 10 12 14
node 0 size: 2048 MB
node 1 cpus: 1 3 5 7 9 11 13 15
node 1 size: 2048 MB
After:
node 2 cpus: 0 2 4 6 8 10 12 14
|
node 2 size: 2048 MB
|
node 3 cpus: 1 3 5 7 9 11 13 15
|
node 3 size: 2048 MB
(2) qemu-system-x86_64 -enable-kvm -m 4096 -numa node,nodeid=0 -numa
node,nodeid=1 -numa node,nodeid=2 -numa node,nodeid=3 -smp 16
Before:
node 0 cpus: 0 4 8 12
|
node 0 size: 1024 MB
|
node 1 cpus: 1 5 9 13
|
node 1 size: 1024 MB
|
node 2 cpus: 2 6 10 14
|
node 2 size: 1024 MB
|
node 3 cpus: 3 7 11 15
|
node 3 size: 1024 MB
After:
node 0 cpus: 0 4 8 12
node 0 size: 1024 MB
node 1 cpus: 1 5 9 13
node 1 size: 1024 MB
node 2 cpus: 2 6 10 14
node 2 size: 1024 MB
node 3 cpus: 3 7 11 15
node 3 size: 1024 MB
Signed-off-by: Nishanth Aravamudan n...@linux.vnet.ibm.com
---
Based off mst's for_upstream tag, which has the NodeInfo changes.
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index 277230d..b90bf66 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -145,11 +145,13 @@ extern int mem_prealloc;
*/
#define MAX_CPUMASK_BITS 255
-extern int nb_numa_nodes;
+extern int nb_numa_nodes; /* Number of NUMA nodes */
+extern int max_numa_node; /* Highest specified NUMA node ID */
typedef struct node_info {
uint64_t node_mem;
DECLARE_BITMAP(node_cpu, MAX_CPUMASK_BITS);
struct HostMemoryBackend *node_memdev;
+bool present;
} NodeInfo;
extern NodeInfo numa_info[MAX_NODES];
void set_numa_nodes(void);
diff --git a/monitor.c b/monitor.c
index c7f8797..4721996 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2003,7 +2003,10 @@ static void do_info_numa(Monitor *mon, const QDict
*qdict)
CPUState *cpu;
monitor_printf(mon, %d nodes\n, nb_numa_nodes);
-for (i = 0; i nb_numa_nodes; i++) {
+for (i = 0; i max_numa_node; i++) {
+if (!numa_info[i].present) {
+continue;
+}
monitor_printf(mon, node %d cpus:, i);
CPU_FOREACH(cpu) {
if (cpu-numa_node == i) {
diff --git a/numa.c b/numa.c
index e471afe..c31857d 100644
--- a/numa.c
+++ b/numa.c
@@ -106,6 +106,10 @@ static void numa_node_parse(NumaNodeOptions *node,
QemuOpts *opts, Error **errp)
numa_info[nodenr].node_mem = object_property_get_int(o, size,
NULL);
numa_info[nodenr].node_memdev = MEMORY_BACKEND(o);
}
+numa_info[nodenr].present = true;
+if (nodenr = max_numa_node) {
+max_numa_node = nodenr + 1;
+}
}
int numa_init_func(QemuOpts *opts, void *opaque)
@@ -155,7 +159,7 @@ void set_numa_nodes(void)
{
if (nb_numa_nodes 0) {
uint64_t numa_total;
-int i;
+int i, j, last_j = -1;
if (nb_numa_nodes MAX_NODES) {
nb_numa_nodes = MAX_NODES;
@@ -164,27 +168,29 @@ void set_numa_nodes(void)
/* If no memory size if given for any node, assume the default case
* and distribute the available memory equally across all nodes
*/
-for (i = 0; i nb_numa_nodes; i++) {
-if (numa_info[i].node_mem != 0) {
+for (i = 0; i max_numa_node; i++) {
+if (numa_info[i].present numa_info[i].node_mem != 0) {
break;
}
}
-if (i == nb_numa_nodes) {
+if (i == max_numa_node) {
uint64_t usedmem = 0;
/* On
Re: [Qemu-devel] [RFC PATCH v2] numa: enable sparse node numbering
On Mon, Jun 23, 2014 at 05:48:25PM -0700, Nishanth Aravamudan wrote:
On 23.06.2014 [12:33:10 -0700], Nishanth Aravamudan wrote:
Add a present field to NodeInfo which indicates if a given nodeid was
present on the command-line or not. Current code relies on a memory
value being passed for a node to indicate presence, which is
insufficient in the presence of memoryless nodes or sparse numbering.
Adjust the iteration of various NUMA loops to use the maximum known NUMA
ID rather than the number of NUMA nodes.
numa.c::set_numa_nodes() has become a bit more convoluted for
round-robin'ing the CPUs over known nodes when not specified by the
user.
Sorry for the noise, but after staring at it for a bit, I think this
version is a bit cleaner for the set_numa_nodes() change.
Add a present field to NodeInfo which indicates if a given nodeid was
present on the command-line or not. Current code relies on a memory
value being passed for a node to indicate presence, which is
insufficient in the presence of memoryless nodes or sparse numbering.
Adjust the iteration of various NUMA loops to use the maximum known NUMA
ID rather than the number of NUMA nodes.
numa.c::set_numa_nodes() has become a bit more convoluted for
round-robin'ing the CPUs over known nodes when not specified by the
user.
Note that architecture-specific code still needs changes (forthcoming)
for both sparse node numbering and memoryless nodes.
Examples:
(1) qemu-system-x86_64 -enable-kvm -m 4096 -numa node,nodeid=3 -numa
node,nodeid=2 -smp 16
Before:
node 0 cpus: 0 2 4 6 8 10 12 14
node 0 size: 2048 MB
node 1 cpus: 1 3 5 7 9 11 13 15
node 1 size: 2048 MB
After:
node 2 cpus: 0 2 4 6 8 10 12 14
|
node 2 size: 2048 MB
|
node 3 cpus: 1 3 5 7 9 11 13 15
|
node 3 size: 2048 MB
(2) qemu-system-x86_64 -enable-kvm -m 4096 -numa node,nodeid=0 -numa
node,nodeid=1 -numa node,nodeid=2 -numa node,nodeid=3 -smp 16
node 0 cpus: 0 4 8 12
|
node 0 size: 1024 MB
|
node 1 cpus: 1 5 9 13
|
node 1 size: 1024 MB
|
node 2 cpus: 2 6 10 14
|
node 2 size: 1024 MB
|
node 3 cpus: 3 7 11 15
|
node 3 size: 1024 MB
(qemu) info numa
4 nodes
node 0 cpus: 0 4 8 12
node 0 size: 1024 MB
node 1 cpus: 1 5 9 13
node 1 size: 1024 MB
node 2 cpus: 2 6 10 14
node 2 size: 1024 MB
node 3 cpus: 3 7 11 15
node 3 size: 1024 MB
Signed-off-by: Nishanth Aravamudan n...@linux.vnet.ibm.com
Cc: Eduardo Habkost ehabk...@redhat.com
Cc: Alexey Kardashevskiy a...@ozlabs.ru
Cc: Michael S. Tsirkin m...@redhat.com
Cc: qemu-devel@nongnu.org
Thanks! The patch fixes sparse NUMA nodes problem for me.
Tested-by: Hu Tao hu...@cn.fujitsu.com
Some comments below:
---
Based off mst's for_upstream tag, which has the NodeInfo changes.
v1 - v2:
Modify set_numa_nodes loop for round-robin'ing CPUs.
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index 277230d..b90bf66 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -145,11 +145,13 @@ extern int mem_prealloc;
*/
#define MAX_CPUMASK_BITS 255
-extern int nb_numa_nodes;
+extern int nb_numa_nodes; /* Number of NUMA nodes */
+extern int max_numa_node; /* Highest specified NUMA node ID */
typedef struct node_info {
uint64_t node_mem;
DECLARE_BITMAP(node_cpu, MAX_CPUMASK_BITS);
struct HostMemoryBackend *node_memdev;
+bool present;
} NodeInfo;
extern NodeInfo numa_info[MAX_NODES];
void set_numa_nodes(void);
diff --git a/monitor.c b/monitor.c
index c7f8797..4721996 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2003,7 +2003,10 @@ static void do_info_numa(Monitor *mon, const QDict
*qdict)
CPUState *cpu;
monitor_printf(mon, %d nodes\n, nb_numa_nodes);
-for (i = 0; i nb_numa_nodes; i++) {
+for (i = 0; i max_numa_node; i++) {
+if (!numa_info[i].present) {
+continue;
+}
The same change can be applied to check against MAX_NODES in
memory_region_allocate_system_memory.
monitor_printf(mon, node %d cpus:, i);
CPU_FOREACH(cpu) {
if (cpu-numa_node == i) {
diff --git a/numa.c b/numa.c
index e471afe..2a4c577 100644
--- a/numa.c
+++ b/numa.c
@@ -106,6 +106,10 @@ static void numa_node_parse(NumaNodeOptions *node,
QemuOpts *opts, Error **errp)
numa_info[nodenr].node_mem = object_property_get_int(o, size,
NULL);
Re: [Qemu-devel] [RFC] Functions bus_foreach and device_find from libqos virtio API
Hello
+for (slot = 0; slot 32; slot++) {
+for (fn = 0; fn 8; fn++) {
+dev = g_malloc0(sizeof(*dev));
+dev-bus = bus;
+dev-devfn = QPCI_DEVFN(slot, fn);
+
+if (qpci_config_readw(dev, PCI_VENDOR_ID) == 0x) {
+g_free(dev);
+continue;
+}
+
+if (device_type != (uint16_t)-1
+qpci_config_readw(dev, PCI_SUBSYSTEM_ID) !=
device_type) {
+continue;
+}
+
+func(qpcidevice_to_qvirtiodevice(dev), data);
+}
+}
Can you reuse qpci_device_foreach() instead of duplicating this code?
I've been thinking and I don't know how to join this definition:
void qvirtio_pci_foreach(uint16_t device_id, void (*func)(QVirtioDevice
*d, void *data), void *data);
With this definition:
void qpci_device_foreach(QPCIBus *bus, int vendor_id, int device_id,
void (*func)(QPCIDevice *dev, int devfn, void *data), void *data)
The function parameter lacks one parameter (which is PCI specific)
Any idea?
+
+#endif
diff --git a/tests/virtio-blk-test.c b/tests/virtio-blk-test.c
index d53f875..4f5b1e0 100644
--- a/tests/virtio-blk-test.c
+++ b/tests/virtio-blk-test.c
@@ -2,6 +2,7 @@
* QTest testcase for VirtIO Block Device
*
* Copyright (c) 2014 SUSE LINUX Products GmbH
+ * Copyright (c) 2014 Marc Marí
*
* This work is licensed under the terms of the GNU GPL, version 2
or later.
* See the COPYING file in the top-level directory.
@@ -9,26 +10,51 @@
#include glib.h
#include string.h
+#include stdlib.h
+#include unistd.h
+#include stdio.h
#include libqtest.h
-#include qemu/osdep.h
+#include libqos/virtio.h
+/*#include qemu/osdep.h*/
-/* Tests only initialization so far. TODO: Replace with functional
tests */ -static void pci_nop(void)
+#define TEST_IMAGE_SIZE (64 * 1024 * 1024)
+
+static char tmp_path[] = /tmp/qtest.XX;
+extern QVirtioBus qvirtio_pci;
+
+static void pci_basic(void)
{
+QVirtioDevice *dev;
+dev = qvirtio_pci.device_find(VIRTIO_BLK_DEVICE_ID);
+fprintf(stderr, Device: %x %x %x\n,
+dev-device_id, dev-location,
dev-device_type); }
int main(int argc, char **argv)
{
int ret;
+int fd;
+char test_start[100];
g_test_init(argc, argv, NULL);
-qtest_add_func(/virtio/blk/pci/nop, pci_nop);
+qtest_add_func(/virtio/blk/pci/basic, pci_basic);
-qtest_start(-drive id=drv0,if=none,file=/dev/null
--device virtio-blk-pci,drive=drv0);
+/* Create a temporary raw image */
+fd = mkstemp(tmp_path);
+g_assert_cmpint(fd, =, 0);
+ret = ftruncate(fd, TEST_IMAGE_SIZE);
+g_assert_cmpint(ret, ==, 0);
+close(fd);
+
+sprintf(test_start, -drive if=none,id=drive0,file=%s
+-device virtio-blk-pci,drive=drive0,
tmp_path);
+qtest_start(test_start);
Every test case should probably start a fresh QEMU with a fresh disk
image. That way no device register state or disk image state can
affect later test cases.
Is it better to create a new temporary file (and so, re-run qemu), or
just truncate every time?
[Qemu-devel] [Bug 1308341] Re: Multiple CPUs causes blue screen on Windows guest (14.04 regression)
Re-installing 14.04 fixed my problem. Running with the same virtual machine configurations on the same hardware without any problems. No hyperv feature needed. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1308341 Title: Multiple CPUs causes blue screen on Windows guest (14.04 regression) Status in QEMU: New Status in “linux” package in Ubuntu: Confirmed Status in “qemu” package in Ubuntu: Confirmed Bug description: Configuring a Windows 7 guest using more than one CPU cases the guest to fail. This happens after a few hours after guest boot. This is the error on the blue screen: A clock interrupt was not received on a secondary processor within the allocated time interval After resetting, the guest will never boot and a new bluescreen with the error STOP: 0x005c appears. Shutting down the guest completely and restarting it will allow it to boot and run for a few hours again. The guest was created using virt-manager. The error happens with or without virtio devices and with both 32-bit and 64-bit Windows 7 guests. I am using Ubuntu 14.04 release candidate. qemu-kvm version 2.0.0~rc1+dfsg-0ubuntu3 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1308341/+subscriptions
[Qemu-devel] [Bug 1307473] Re: guest hang due to missing clock interrupt
Also, seems that these bugs are DUPs: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1308341 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1332409 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1307473 Title: guest hang due to missing clock interrupt Status in QEMU: New Status in “qemu” package in Ubuntu: Confirmed Bug description: I noticed on 2 different systems that after upgrade from precise to latest trusty VMs are crashing: - in case of Windows VMs I'm getting BSOD with error message: A clock interrupt was not received on a secondary processor within the allocated time interval. - On linux VMs I'm noticing hrtimer: interrupt took 2992229 ns messages - On some proprietary virtual appliances I'm noticing crashes an due to missing timer interrupts QEMU version is: QEMU emulator version 1.7.91 (Debian 2.0.0~rc1+dfsg-0ubuntu3) Full command line: qemu-system-x86_64 -enable-kvm -name win7eval -S -machine pc- i440fx-1.7,accel=kvm,usb=off -cpu host -m 4096 -realtime mlock=off -smp 4,sockets=1,cores=4,threads=1 -uuid 05e5089a- 4aa1-6bb2-ef06-ab4d020a -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/win7eval.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 -drive file=/var/vm/win7eval.qcow2,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio- disk0,id=virtio-disk0,bootindex=1 -drive file=/home/damarion/iso/7600.16385.090713-1255_x86fre_enterprise_en- us_EVAL_Eval_Enterprise-GRMCENEVAL_EN_DVD.iso,if=none,id=drive- ide0-0-0,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=0,drive =drive-ide0-0-0,id=ide0-0-0 -drive file=/home/damarion/iso/virtio- win-0.1-74.iso,if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=24,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=52:54:00:38:31:0a,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa- serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 127.0.0.1:1 -device VGA,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1307473/+subscriptions
[Qemu-devel] [Bug 1307473] Re: guest hang due to missing clock interrupt
I have the same symptoms with two trusty-amd64 virtual hosts: * win2003, linux guests hang for a period of time (~5 seconds, half of a minute and more) * win2008 blue screen with the same message This happens with kernels (host): Linux vsrv7 3.13.0-27-generic #50-Ubuntu SMP Thu May 15 18:06:16 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux Linux vsrv9 3.13.0-29-generic #53-Ubuntu SMP Wed Jun 4 21:00:20 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux Qemu version: 2.0.0+dfsg-2ubuntu1.1 Here are qemu params of guests that definately hang: * precise with 3.11: qemu-system-x86_64 -enable-kvm -name m -S -machine pc-i440fx-trusty,accel=kvm,usb=off -m 4096 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid ab7f1e0b-e82e-ddb7-b743-903b8732e333 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/m.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot order=c,menu=on,strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x4 -drive file=/dev/vg00/kvm_m_1,if=none,id=drive-scsi0-0-0-0,format=raw,cache=none,aio=native -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0 -netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=29 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:3a:76:ad,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -vnc 127.0.0.1:3 -device VGA,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 * win 2008 r2: qemu-system-x86_64 -enable-kvm -name ts2 -S -machine pc-1.0,accel=kvm,usb=off -m 1 -realtime mlock=off -smp 16,sockets=16,cores=1,threads=1 -uuid 4df29f97-7e47-8af3-0009-a5395c28e3c5 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/ts2.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -boot order=c,menu=on,strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x8 -drive file=/dev/vg00/kvm_ts2_1,if=none,id=drive-scsi0-0-0-0,format=raw,cache=none,aio=native -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0 -drive file=/dev/vg00/kvm_ts2_2,if=none,id=drive-scsi0-0-0-1,format=raw,cache=none,aio=native -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1 -drive file=/dev/vg00/kvm_ts2_3,if=none,id=drive-scsi0-0-0-2,format=raw,cache=none,aio=native -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=2,drive=drive-scsi0-0-0-2,id=scsi0-0-0-2 -netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=30 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:ac:28:3a,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -device VGA,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 * win 2003: qemu-system-x86_64 -enable-kvm -name ts4 -S -machine pc-i440fx-trusty,accel=kvm,usb=off -m 8192 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid d9f9b238-5cb6-59a8-f3aa-ccfc6656040a -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/ts4.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -boot order=c,menu=on,strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/dev/vg00/kvm_ts4_1,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 -netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=27 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:37:6b:8d,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 127.0.0.1:2 -device VGA,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1307473 Title: guest hang due to missing clock interrupt Status in QEMU: New Status in “qemu” package in Ubuntu: Confirmed Bug description: I noticed on 2 different systems that after upgrade from precise to latest trusty VMs are crashing: - in case of Windows VMs I'm getting BSOD with error message: A clock interrupt was not received on a secondary processor within the allocated time interval. - On linux VMs I'm noticing hrtimer: interrupt took 2992229 ns messages - On some proprietary virtual appliances I'm noticing crashes an due to missing timer interrupts QEMU version is: QEMU emulator version 1.7.91 (Debian 2.0.0~rc1+dfsg-0ubuntu3) Full command line: qemu-system-x86_64
[Qemu-devel] Clock Emulation
Can anyone help me out in finding how does QEMU provide emulated clock to guest operating system.. For instance, how does it increment x86's time stamp counter register??
[Qemu-devel] [Bug 1307473] Re: guest hang due to missing clock interrupt
** Attachment added: dmesg of precise guest while hanging https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1307473/+attachment/4137970/+files/dmesg.txt -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1307473 Title: guest hang due to missing clock interrupt Status in QEMU: New Status in “qemu” package in Ubuntu: Confirmed Bug description: I noticed on 2 different systems that after upgrade from precise to latest trusty VMs are crashing: - in case of Windows VMs I'm getting BSOD with error message: A clock interrupt was not received on a secondary processor within the allocated time interval. - On linux VMs I'm noticing hrtimer: interrupt took 2992229 ns messages - On some proprietary virtual appliances I'm noticing crashes an due to missing timer interrupts QEMU version is: QEMU emulator version 1.7.91 (Debian 2.0.0~rc1+dfsg-0ubuntu3) Full command line: qemu-system-x86_64 -enable-kvm -name win7eval -S -machine pc- i440fx-1.7,accel=kvm,usb=off -cpu host -m 4096 -realtime mlock=off -smp 4,sockets=1,cores=4,threads=1 -uuid 05e5089a- 4aa1-6bb2-ef06-ab4d020a -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/win7eval.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 -drive file=/var/vm/win7eval.qcow2,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio- disk0,id=virtio-disk0,bootindex=1 -drive file=/home/damarion/iso/7600.16385.090713-1255_x86fre_enterprise_en- us_EVAL_Eval_Enterprise-GRMCENEVAL_EN_DVD.iso,if=none,id=drive- ide0-0-0,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=0,drive =drive-ide0-0-0,id=ide0-0-0 -drive file=/home/damarion/iso/virtio- win-0.1-74.iso,if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=24,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=52:54:00:38:31:0a,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa- serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 127.0.0.1:1 -device VGA,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1307473/+subscriptions
Re: [Qemu-devel] Writing into guest memory from qemu
Hi, Maybe you are trying to write into read-only, device MMIO or unassigned address? You can launch qemu with '-S' and then try 'info mtree' qemu monitor command to see the memory mapping. // Sergey On 24.06.2014 11:20, Shubham Gupta wrote: Hello I am attempting to write into the guest memory state (before the guest is launched) using the cpu_physical_memory_write function. While some values are being correctly written into the guest memory (confirmed by a cpu_physical_memory_read just after the write), some are not. Is there an explanation for this behavior? Or am I using the wrong function to accomplish what I want? Thanks in advance. Shubham Gupta
[Qemu-devel] [Bug 1308341] Re: Multiple CPUs causes blue screen on Windows guest (14.04 regression)
Could it be DUP of https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1307473 ? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1308341 Title: Multiple CPUs causes blue screen on Windows guest (14.04 regression) Status in QEMU: New Status in “linux” package in Ubuntu: Confirmed Status in “qemu” package in Ubuntu: Confirmed Bug description: Configuring a Windows 7 guest using more than one CPU cases the guest to fail. This happens after a few hours after guest boot. This is the error on the blue screen: A clock interrupt was not received on a secondary processor within the allocated time interval After resetting, the guest will never boot and a new bluescreen with the error STOP: 0x005c appears. Shutting down the guest completely and restarting it will allow it to boot and run for a few hours again. The guest was created using virt-manager. The error happens with or without virtio devices and with both 32-bit and 64-bit Windows 7 guests. I am using Ubuntu 14.04 release candidate. qemu-kvm version 2.0.0~rc1+dfsg-0ubuntu3 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1308341/+subscriptions
Re: [Qemu-devel] machines and versions - why so many?
Alexey Kardashevskiy a...@ozlabs.ru writes: On 06/24/2014 03:15 PM, Paolo Bonzini wrote: Il 23/06/2014 23:35, Alexey Kardashevskiy ha scritto: nec-usb-xhci is off for PC_COMPAT_1_3 because of what? PIIX emulation was broken in 1.3? Or nec-usb-xhci? nec-usb-xhci is not off. Yes, my bad, I understood (but explained this wrong) that XHCI is enabled but without MSI. .driver = nec-usb-xhci,\ .property = msi,\ .value= off,\ What's off is MSI (and MSI-X), because it wasn't implemented. If it is the latter, why is the tweak limited by PC? Because at the time nobody cared about migration compatibility (even now only pSeries is starting to care). only pSeries? There are plenty of x86 machines already and if it is not for migration support, then what are they all for? :) At the time, nobody *else* cared. Only PC did. Back then gerd created a way to do the compatibility stuff without getting into the other target's hair: compat_props. They've served us well enough, but now that more targets get interested in migration, their shortcomings start to hurt. Having to duplicate device compatibility gunk in multiple places, all far away from the device, is decidedly suboptimal. Better ideas welcome. [...]
Re: [Qemu-devel] [PATCH] linux-user: fix ipc(SEMCTL, ...) argument handling
On 24 June 2014 00:53, Paul Burton p...@archlinuxmips.org wrote: Well I disagree with your logic, but perhaps that's primarily because of your claim that the semctl code is clearly bogus and obviously broken. Could you back that up? I know there's the one bogus line in the GETVAL/SETVAL case that was mentioned in another email, but is there anything else you consider broken? The type of the parameter we pass doesn't match what the kernel does, there's been at least one previous attempt to fix stuff in this area, and as you say the getval/setval stuff is broken. That's three things, which means (to my mind) that the first thing that needs to be done is examine the whole routine and determine how it ought to work, independent of what it happens to be doing now. Then you can implement the necessary fixes. I *don't* think this is a big job, or even that the code needs to be completely rewritten. I see your point on testing, but frankly this code is generic for all architectures in Linux. I don't have the time to test each architecture and I don't have the time to test all software that may have previously been working by fluke. So what's the bar you'd like to set here? Riku's the submaintainer here, so it's his decision in the end (and I think he has a set of tests he runs on patches as well), but one of the bars I have for reviewing patches is that I should be reasonably confident it won't regress existing behaviour for anybody. A simple patch to existing clear and correct code gives me that confidence; a set of patches that take a holistic approach to an obvious trouble spot do too; a pile of testing ditto. A tiny point fix added to something we know to be dubious doesn't give any confidence that it's going to interact correctly with the dubious code. But anyway, please do enlighten me: where are the bugs of which you speak? I'd like to see them fixed too :) You're essentially asking me to do the work for you. This is a recipe for me to say sorry, I don't think we should accept your patch -- it's you that has a reason to get this patch accepted, not me. thanks -- PMM
Re: [Qemu-devel] [RFC] Functions bus_foreach and device_find from libqos virtio API
Hello
-/* Tests only initialization so far. TODO: Replace with functional
tests */ -static void pci_nop(void)
+#define TEST_IMAGE_SIZE (64 * 1024 * 1024)
+
+static char tmp_path[] = /tmp/qtest.XX;
+extern QVirtioBus qvirtio_pci;
+
+static void pci_basic(void)
{
+QVirtioDevice *dev;
+dev = qvirtio_pci.device_find(VIRTIO_BLK_DEVICE_ID);
+fprintf(stderr, Device: %x %x %x\n,
+dev-device_id, dev-location,
dev-device_type); }
int main(int argc, char **argv)
{
int ret;
+int fd;
+char test_start[100];
Depending on length of tmp_path, this looks quite close to an
overflow ...
g_test_init(argc, argv, NULL);
-qtest_add_func(/virtio/blk/pci/nop, pci_nop);
+qtest_add_func(/virtio/blk/pci/basic, pci_basic);
-qtest_start(-drive id=drv0,if=none,file=/dev/null
--device virtio-blk-pci,drive=drv0);
+/* Create a temporary raw image */
+fd = mkstemp(tmp_path);
+g_assert_cmpint(fd, =, 0);
+ret = ftruncate(fd, TEST_IMAGE_SIZE);
+g_assert_cmpint(ret, ==, 0);
+close(fd);
+
+sprintf(test_start, -drive if=none,id=drive0,file=%s
+-device virtio-blk-pci,drive=drive0,
tmp_path);
... here. Also please use snprintf.
tmp_path is defined as global, and has always the same size
(/tmp/qtest.XX, where the X will be replaced by a temporary name).
But I'll change to snprintf for security.
Re: [Qemu-devel] [PATCH 0/3] target-sparc: fixed unused function warnings
On 24 June 2014 05:24, Richard Henderson r...@twiddle.net wrote: I think I would be happier if you changed the functions to not be marked as inline. I think that there's a large body of code that marks things inline exactly to prevent unused warnings with gcc. If we're going to play with the ifdeffery, we might as well just let any compiler warn if its unused. Makes sense. thanks -- PMM
[Qemu-devel] [Bug 1308341] Re: Multiple CPUs causes blue screen on Windows guest (14.04 regression)
I agree. This seems to me like a duplicate of bug 1307473. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1308341 Title: Multiple CPUs causes blue screen on Windows guest (14.04 regression) Status in QEMU: New Status in “linux” package in Ubuntu: Confirmed Status in “qemu” package in Ubuntu: Confirmed Bug description: Configuring a Windows 7 guest using more than one CPU cases the guest to fail. This happens after a few hours after guest boot. This is the error on the blue screen: A clock interrupt was not received on a secondary processor within the allocated time interval After resetting, the guest will never boot and a new bluescreen with the error STOP: 0x005c appears. Shutting down the guest completely and restarting it will allow it to boot and run for a few hours again. The guest was created using virt-manager. The error happens with or without virtio devices and with both 32-bit and 64-bit Windows 7 guests. I am using Ubuntu 14.04 release candidate. qemu-kvm version 2.0.0~rc1+dfsg-0ubuntu3 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1308341/+subscriptions
[Qemu-devel] [PATCHv2] block/nfs: add knob to set readahead
upcoming libnfs will feature internal readahead support.
Add a knob to pass the optional readahead value as a URL
parameter.
This patch fixes also the incorrect usage of strncmp and
atoi.
Signed-off-by: Peter Lieven p...@kamp.de
---
v1-v2: use strtol instead of atoi [Eric]
block/nfs.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/block/nfs.c b/block/nfs.c
index ec43201..9783483 100644
--- a/block/nfs.c
+++ b/block/nfs.c
@@ -309,12 +309,16 @@ static int64_t nfs_client_open(NFSClient *client, const
char *filename,
qp-p[i].name);
goto fail;
}
-if (!strncmp(qp-p[i].name, uid, 3)) {
-nfs_set_uid(client-context, atoi(qp-p[i].value));
-} else if (!strncmp(qp-p[i].name, gid, 3)) {
-nfs_set_gid(client-context, atoi(qp-p[i].value));
-} else if (!strncmp(qp-p[i].name, tcp-syncnt, 10)) {
-nfs_set_tcp_syncnt(client-context, atoi(qp-p[i].value));
+if (!strcmp(qp-p[i].name, uid)) {
+nfs_set_uid(client-context, strtol(qp-p[i].value, NULL, 0));
+} else if (!strcmp(qp-p[i].name, gid)) {
+nfs_set_gid(client-context, strtol(qp-p[i].value, NULL, 0));
+} else if (!strcmp(qp-p[i].name, tcp-syncnt)) {
+nfs_set_tcp_syncnt(client-context, strtol(qp-p[i].value, NULL,
0));
+#ifdef LIBNFS_FEATURE_READAHEAD
+} else if (!strcmp(qp-p[i].name, readahead)) {
+nfs_set_readahead(client-context, strtol(qp-p[i].value, NULL,
0));
+#endif
} else {
error_setg(errp, Unknown NFS parameter name: %s,
qp-p[i].name);
--
1.7.9.5
Re: [Qemu-devel] [PATCH] block/nfs: add knob to set readahead
On 23.06.2014 23:05, Eric Blake wrote:
On 06/23/2014 02:47 PM, Peter Lieven wrote:
+#ifdef LIBNFS_FEATURE_READAHEAD
+} else if (!strcmp(qp-p[i].name, readahead)) {
+nfs_set_readahead(client-context, atoi(qp-p[i].value));
+#endif
I'm not a fan of adding even more special-casing to the file-name URI
without also adding it to the QAPI schema for use in the blockdev-add
command. Of course, we don't have structured nfs options for
blockdev-add yet, but maybe it's time to start thinking about that
addition before we do this addition.
I would like to leave this for a follow-up and I promise to take care of this.
If you could give me a pointer of an existing driver that does this as a
reference
I would be grateful.
A good example of a recent conversion to structured options would be the
blkdebug and blkverify backends (look around commit 1bf20b82), or
proposed addition of new backends (such as archipelego,
https://lists.gnu.org/archive/html/qemu-devel/2014-06/msg05309.html).
It may be a bigger task than you anticipate, and certainly won't make
the 2.1 timeframe, but it's worth doing so if you're up to the task,
more power to you :)
For the read ahead parameter its likely not needed as (at least in my use case)
the read ahead makes only sense when converting a compressed QCOW2 Template File
which lives on an NFS Share to a RAW Device. So I use it with qemu-img.
For a Container File that is used as a VM hard drive I would likely not use
read ahead
as the operating system itself will implement some sort of read ahead already.
Even if qemu-img is likely to be the only one ever specifying the
option, it still makes sense to expose it via QMP, as we are gradually
trying to move qemu-img over to more exclusive use of QMP (or at least
the underlying functions reached by QMP) rather than ad-hoc code. For
example,
https://lists.gnu.org/archive/html/qemu-devel/2014-06/msg01822.html).
Ok, it looks like a bit of work. I will put it on my list for 2.2.
Thanks for the pointers,
Peter
Re: [Qemu-devel] [RFC PATCH] numa: enable sparse node numbering
On 06/24/2014 05:33 PM, Igor Mammedov wrote: On Mon, 23 Jun 2014 12:33:10 -0700 Nishanth Aravamudan n...@linux.vnet.ibm.com wrote: Add a present field to NodeInfo which indicates if a given nodeid was present on the command-line or not. Current code relies on a memory value being passed for a node to indicate presence, which is insufficient in the presence of memoryless nodes or sparse numbering. Adjust the iteration of various NUMA loops to use the maximum known NUMA ID rather than the number of NUMA nodes. Why would you need sparse numbering? What task exactly are you trying to solve? This is to reproduce+debug the real POWERPC hardware behavior. No practical use as far as I can tell. -- Alexey
Re: [Qemu-devel] machines and versions - why so many?
On 06/24/2014 06:17 PM, Markus Armbruster wrote: Alexey Kardashevskiy a...@ozlabs.ru writes: On 06/24/2014 03:15 PM, Paolo Bonzini wrote: Il 23/06/2014 23:35, Alexey Kardashevskiy ha scritto: nec-usb-xhci is off for PC_COMPAT_1_3 because of what? PIIX emulation was broken in 1.3? Or nec-usb-xhci? nec-usb-xhci is not off. Yes, my bad, I understood (but explained this wrong) that XHCI is enabled but without MSI. .driver = nec-usb-xhci,\ .property = msi,\ .value= off,\ What's off is MSI (and MSI-X), because it wasn't implemented. If it is the latter, why is the tweak limited by PC? Because at the time nobody cared about migration compatibility (even now only pSeries is starting to care). only pSeries? There are plenty of x86 machines already and if it is not for migration support, then what are they all for? :) At the time, nobody *else* cared. Only PC did. Ah. Misinterpret. My bad. Ok. Back then gerd created a way to do the compatibility stuff without getting into the other target's hair: compat_props. They've served us well enough, but now that more targets get interested in migration, their shortcomings start to hurt. Having to duplicate device compatibility gunk in multiple places, all far away from the device, is decidedly suboptimal. Better ideas welcome. I would suggest moving PC_COMPAT_X_Y things to platform-independent place but [RFC v2 00/39] Convert PC machine-types to QOM classes is already huge and complicated, and also pseries does not really need stuff below 1.6, may be it is not worth it... -- Alexey
Re: [Qemu-devel] [PATCH] linux-user: fix ipc(SEMCTL, ...) argument handling
On Tue, Jun 24, 2014 at 09:19:45AM +0100, Peter Maydell wrote: On 24 June 2014 00:53, Paul Burton p...@archlinuxmips.org wrote: Well I disagree with your logic, but perhaps that's primarily because of your claim that the semctl code is clearly bogus and obviously broken. Could you back that up? I know there's the one bogus line in the GETVAL/SETVAL case that was mentioned in another email, but is there anything else you consider broken? The type of the parameter we pass doesn't match what the kernel does, there's been at least one previous attempt to fix stuff in this area, and as you say the getval/setval stuff is broken. Thanks, that's useful. I'll change the code to use ulong instead of union target_semun if that'll make you happier, but that is simply moving casting down a level into do_semctl and won't change the way this runs. I'm not aware of GETVAL SETVAL being broken in the sense of not working when used by target programs. There's one bogus line in the code which as far as I can see is harmless with the exception of making the code unclear to readers. I'm happy to submit a patch to remove that line. I can see that the fact that someone previously attempted, incorrectly, to fix a bug in this code may make you doubt its correctness and be wary of further patches to the code. What I disagree with is the notion that a bug fix shouldn't be merged until the code has been thoroughly examined for further bugs. That's three things, which means (to my mind) that the first thing that needs to be done is examine the whole routine and determine how it ought to work, independent of what it happens to be doing now. Then you can implement the necessary fixes. I *don't* think this is a big job, or even that the code needs to be completely rewritten. I agree it's a good idea for that to be done, and I'll do it when I get the time. I disagree that it means this bug fix shouldn't be merged, but there's no sense arguing about it so I'll leave it there and Riku can do as he wishes. I see your point on testing, but frankly this code is generic for all architectures in Linux. I don't have the time to test each architecture and I don't have the time to test all software that may have previously been working by fluke. So what's the bar you'd like to set here? Riku's the submaintainer here, so it's his decision in the end (and I think he has a set of tests he runs on patches as well), but one of the bars I have for reviewing patches is that I should be reasonably confident it won't regress existing behaviour for anybody. A simple patch to existing clear and correct code gives me that confidence; a set of patches that take a holistic approach to an obvious trouble spot do too; a pile of testing ditto. A tiny point fix added to something we know to be dubious doesn't give any confidence that it's going to interact correctly with the dubious code. That's the thing, you say the code is known to be dubious (previously bogus and broken), but then when I ask you to back that up I get this: But anyway, please do enlighten me: where are the bugs of which you speak? I'd like to see them fixed too :) You're essentially asking me to do the work for you. That's not what I intend at all. I simply wanted to know why you consider the code bogus broken. Hopefully the reasons are addressed above. This is a recipe for me to say sorry, I don't think we should accept your patch -- it's you that has a reason to get this patch accepted, not me. The only reason I'd like it merged is that I want QEMU to work better, for the good of all who use it. I'd hope that's true of everyone working on it and in that sense I have no more investment in this patch being merged than anyone else. I'm not being paid to do this, and my build of QEMU works better than it did previously. Anyway things seem to be getting a little heated here which is probably not a productive path forwards, so I'll leave this alone until I write the GETVAL/SETVAL patch look through the rest of the code. Paul signature.asc Description: Digital signature
[Qemu-devel] [PATCH] migration: catch unknown flag combinations in ram_load
this patch extends commit db80fac by not only checking
for unknown flags, but also filtering out unknown flag
combinations.
Suggested-by: Eric Blake ebl...@redhat.com
Signed-off-by: Peter Lieven p...@kamp.de
---
arch_init.c | 62 ++-
1 file changed, 32 insertions(+), 30 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index 8ddaf35..fb06d07 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -1038,8 +1038,7 @@ void ram_handle_compressed(void *host, uint8_t ch,
uint64_t size)
static int ram_load(QEMUFile *f, void *opaque, int version_id)
{
-ram_addr_t addr;
-int flags, ret = 0;
+int flags = 0, ret = 0;
static uint64_t seq_iter;
seq_iter++;
@@ -1048,21 +1047,24 @@ static int ram_load(QEMUFile *f, void *opaque, int
version_id)
ret = -EINVAL;
}
-while (!ret) {
-addr = qemu_get_be64(f);
+while (!ret !(flags RAM_SAVE_FLAG_EOS)) {
+ram_addr_t addr, total_ram_bytes;
+void *host;
+uint8_t ch;
+addr = qemu_get_be64(f);
flags = addr ~TARGET_PAGE_MASK;
addr = TARGET_PAGE_MASK;
-if (flags RAM_SAVE_FLAG_MEM_SIZE) {
+switch (flags ~RAM_SAVE_FLAG_CONTINUE) {
+case RAM_SAVE_FLAG_MEM_SIZE:
/* Synchronize RAM block list */
-char id[256];
-ram_addr_t length;
-ram_addr_t total_ram_bytes = addr;
-
-while (total_ram_bytes) {
+total_ram_bytes = addr;
+while (!ret total_ram_bytes) {
RAMBlock *block;
uint8_t len;
+char id[256];
+ram_addr_t length;
len = qemu_get_byte(f);
qemu_get_buffer(f, (uint8_t *)id, len);
@@ -1086,16 +1088,11 @@ static int ram_load(QEMUFile *f, void *opaque, int
version_id)
accept migration, id);
ret = -EINVAL;
}
-if (ret) {
-break;
-}
total_ram_bytes -= length;
}
-} else if (flags RAM_SAVE_FLAG_COMPRESS) {
-void *host;
-uint8_t ch;
-
+break;
+case RAM_SAVE_FLAG_COMPRESS:
host = host_from_stream_offset(f, addr, flags);
if (!host) {
error_report(Illegal RAM offset RAM_ADDR_FMT, addr);
@@ -1105,9 +1102,8 @@ static int ram_load(QEMUFile *f, void *opaque, int
version_id)
ch = qemu_get_byte(f);
ram_handle_compressed(host, ch, TARGET_PAGE_SIZE);
-} else if (flags RAM_SAVE_FLAG_PAGE) {
-void *host;
-
+break;
+case RAM_SAVE_FLAG_PAGE:
host = host_from_stream_offset(f, addr, flags);
if (!host) {
error_report(Illegal RAM offset RAM_ADDR_FMT, addr);
@@ -1116,8 +1112,9 @@ static int ram_load(QEMUFile *f, void *opaque, int
version_id)
}
qemu_get_buffer(f, host, TARGET_PAGE_SIZE);
-} else if (flags RAM_SAVE_FLAG_XBZRLE) {
-void *host = host_from_stream_offset(f, addr, flags);
+break;
+case RAM_SAVE_FLAG_XBZRLE:
+host = host_from_stream_offset(f, addr, flags);
if (!host) {
error_report(Illegal RAM offset RAM_ADDR_FMT, addr);
ret = -EINVAL;
@@ -1130,17 +1127,22 @@ static int ram_load(QEMUFile *f, void *opaque, int
version_id)
ret = -EINVAL;
break;
}
-} else if (flags RAM_SAVE_FLAG_HOOK) {
-ram_control_load_hook(f, flags);
-} else if (flags RAM_SAVE_FLAG_EOS) {
-/* normal exit */
break;
-} else {
-error_report(Unknown migration flags: %#x, flags);
-ret = -EINVAL;
+case RAM_SAVE_FLAG_EOS:
+/* normal exit */
break;
+default:
+if (flags RAM_SAVE_FLAG_HOOK) {
+ram_control_load_hook(f, flags);
+} else {
+error_report(Unknown combination of migration flags: %#x,
+ flags);
+ret = -EINVAL;
+}
+}
+if (!ret) {
+ret = qemu_file_get_error(f);
}
-ret = qemu_file_get_error(f);
}
DPRINTF(Completed load of VM with exit code %d seq iteration
--
1.7.9.5
Re: [Qemu-devel] [PATCH v2 14/22] target-mips: add Addressing and PC-relative instructions
On 20/06/2014 21:50, Aurelien Jarno wrote:
The patch subject is a bit misleading, as it also includes the AUI family.
Thanks for pointing this out.
+#if defined(TARGET_MIPS64)
+case R6_OPC_LDPC: /* bits 18 and 19 are part of immediate */
+case R6_OPC_LDPC + (1 16):
+case R6_OPC_LDPC + (2 16):
+case R6_OPC_LDPC + (3 16):
+check_mips_64(ctx);
+offset = (((int32_t)ctx-opcode 14)) 11;
This will overflow the 32-bits type. I guess you want:
offset = (((int32_t)ctx-opcode 13)) 10;
I think original code is correct (LDPC offset's size is 18 bits so it
won't overflow). However, I just noticed that the comment is misleading
(there should be 'bits 16 and 17' instead of 'bits 18 and 19').
I do wonder if we shouldn't use sextract32() instead of open coding that
now that it is available:
offset = sextract32(ctx-opcode, 0, 19) 3;
This looks better, thanks for the suggestion (but since the offset's
size is 18, third argument will be 18, not 19).
+addr = addr_add(ctx, (ctx-pc ~0x7), offset);
Why do we need to mask the low 3 bits of the PC? It doesn't appear in
the manual version I have (MD00087 version 6.00).
It doesn't appear in LDPC pseudo-code, but few lines below there is a
restriction: LDPC is naturally aligned, by specification.
For load doubleword we need to make the address aligned to 8-byte boundary.
You can also refer to MIPS64 Volume-I (MD00083 version 6.01):
5.1.3.1 PC relative loads (Release 6)
LDPC: Loads a 64-bit doubleword from a PC relative address, formed by
adding the PC, aligned to 8-bytes by masking off the low 3 bits, to a
sign-extended 18-bit immediate, shifted left by 3 bits, for a 21-bit span.
+#if defined(TARGET_MIPS64)
+case OPC_DAHI:
+check_insn(ctx, ISA_MIPS32R6);
+check_mips_64(ctx);
+if (rs != 0) {
+tcg_gen_addi_i64(cpu_gpr[rs], cpu_gpr[rs], (int64_t)imm
32);
Small nitpicking: even if it is guarded by #ifdef, in theory the _tl
type should be used there, to match the register type.
I'll correct it.
Thanks,
Leon
Re: [Qemu-devel] [PATCH v2 14/22] target-mips: add Addressing and PC-relative instructions
On 24 June 2014 10:50, Leon Alrae leon.al...@imgtec.com wrote: On 20/06/2014 21:50, Aurelien Jarno wrote: I do wonder if we shouldn't use sextract32() instead of open coding that now that it is available: offset = sextract32(ctx-opcode, 0, 19) 3; This looks better, thanks for the suggestion (but since the offset's size is 18, third argument will be 18, not 19). This is undefined behaviour in C because of the shift into the sign bit. Better to shift first and then signextend: offset = sextract32(ctx-opcode 3, 0, 21); thanks -- PMM
Re: [Qemu-devel] [PULL] Merge ppc32/ppc64 tcg backends
On 23 June 2014 15:36, Richard Henderson r...@twiddle.net wrote: No change since v3, so eliding the patches. Thanks for the testing, Tom. r~ The following changes since commit d9c1647d896d3192cba9dbf98fb7efab876edde5: Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' into staging (2014-06-23 12:55:22 +0100) are available in the git repository at: git://github.com/rth7680/qemu.git tcg-ppc-merge-1 for you to fetch changes up to a84ac4cbbb4f4705305189ef007a8432b0b9f718: tcg-ppc: Use the return address as a base pointer (2014-06-23 07:32:33 -0700) Applied, thanks. -- PMM
Re: [Qemu-devel] extremely low IOPS performance of QCOW2 image format on an SSD RAID1
Am 24.06.2014 um 09:25 hat lihuiba geschrieben: Can you confirm that making L2_CACHE_SIZE much bigger solves the problem? Yes, it is confirmed. When I run fio randread with a 7GB or 8GB size, result is close to that of raw image. But when the size is increased to 9GB, the result drops dramatically. And I have modified qcow2-cache.c to print a log when cache misses. When testing the 9GB size, there are lots of cache misses shown. You also have the optional of specifying the cluster size when creating the qcow2 image file. A larger cluster size reduces the amount of metadata overhead and therefore increases cache hits. I didn't find any command-line option to increase the size of the cache, so I increased cluster_size to 1MB or 2MB. This worked very well for me. BTW qemu-img of version 1.7.1 has bug when creating qcow2 image with options preallocation=metadata and cluster_size 64K. It reports: # qemu-img create -f qcow2 -o preallocation=metadata,cluster_size=1M asdf.qcow2 100G Formatting 'asdf.qcow2', fmt=qcow2 size=107374182400 encryption=off cluster_size=1048576 preallocation='metadata' lazy_refcounts=off qemu-img: block/qcow2-cluster.c:1196: qcow2_alloc_cluster_offset: Assertion `n_start * (1ULL 9) == offset_into_cluster(s, offset)' failed. This appears to be fixed in current git master. Kevin
[Qemu-devel] [PATCH v2] mac99: Add motherboard devices before PCI cards
Change the order of creating devices for New World Mac emulation so
that devices on the motherboard are added first and PCI cards (VGA and
NIC) come later. As a side effect, this also causes OpenBIOS to map
the motherboard devices into the MMIO space to the same addresses as
on real hardware and allow clients that hardcode these addresses (e.g.
MorphOS) to find and use them until OpenBIOS is tought to map devices
to specific addresses. (On real hardware the graphics and network
cards are really on separate buses but we don't model that yet.) This
brings the memory map closer to what is found on PowerMac3,1.
Signed-off-by: BALATON Zoltan bala...@eik.bme.hu
---
v2: style fixes suggested by checkpatch.pl
---
hw/ppc/mac_newworld.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
index e493dc1..89d3cad 100644
--- a/hw/ppc/mac_newworld.c
+++ b/hw/ppc/mac_newworld.c
@@ -373,18 +373,11 @@ static void ppc_core99_init(MachineState *machine)
machine_arch = ARCH_MAC99;
}
/* init basic PC hardware */
-pci_vga_init(pci_bus);
-
escc_mem = escc_init(0, pic[0x25], pic[0x24],
serial_hds[0], serial_hds[1], ESCC_CLOCK, 4);
memory_region_init_alias(escc_bar, NULL, escc-bar,
escc_mem, 0, memory_region_size(escc_mem));
-for(i = 0; i nb_nics; i++)
-pci_nic_init_nofail(nd_table[i], pci_bus, ne2k_pci, NULL);
-
-ide_drive_get(hd, MAX_IDE_BUS);
-
macio = pci_create(pci_bus, -1, TYPE_NEWWORLD_MACIO);
dev = DEVICE(macio);
qdev_connect_gpio_out(dev, 0, pic[0x19]); /* CUDA */
@@ -395,6 +388,8 @@ static void ppc_core99_init(MachineState *machine)
macio_init(macio, pic_mem, escc_bar);
/* We only emulate 2 out of 3 IDE controllers for now */
+ide_drive_get(hd, MAX_IDE_BUS);
+
macio_ide = MACIO_IDE(object_resolve_path_component(OBJECT(macio),
ide[0]));
macio_ide_init_drives(macio_ide, hd);
@@ -420,8 +415,15 @@ static void ppc_core99_init(MachineState *machine)
}
}
-if (graphic_depth != 15 graphic_depth != 32 graphic_depth != 8)
+pci_vga_init(pci_bus);
+
+if (graphic_depth != 15 graphic_depth != 32 graphic_depth != 8) {
graphic_depth = 15;
+}
+
+for (i = 0; i nb_nics; i++) {
+pci_nic_init_nofail(nd_table[i], pci_bus, ne2k_pci, NULL);
+}
/* The NewWorld NVRAM is not located in the MacIO device */
dev = qdev_create(NULL, TYPE_MACIO_NVRAM);
--
1.8.1.5
Re: [Qemu-devel] [Qemu-ppc] [PATCH] mac99: Add motherboard devices before PCI cards
On Mon, 23 Jun 2014, Mark Cave-Ayland wrote: On 23/06/14 23:03, BALATON Zoltan wrote: Change the order of creating devices for New World Mac emulation so that devices on the motherboard are added first and PCI cards (VGA and NIC) come later. As a side effect, this also causes OpenBIOS to map the motherboard devices into the MMIO space to the same addresses as on real hardware and allow clients that hardcode these addresses (e.g. MorphOS) to find and use them until OpenBIOS is tought to map devices to specific addresses. (On real hardware the graphics and network cards are really on separate buses but we don't model that yet.) This brings the memory map closer to what is found on PowerMac3,1. Signed-off-by: BALATON Zoltan bala...@eik.bme.hu --- hw/ppc/mac_newworld.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c index e493dc1..1a1e305 100644 --- a/hw/ppc/mac_newworld.c +++ b/hw/ppc/mac_newworld.c @@ -373,18 +373,11 @@ static void ppc_core99_init(MachineState *machine) machine_arch = ARCH_MAC99; } /* init basic PC hardware */ -pci_vga_init(pci_bus); - escc_mem = escc_init(0, pic[0x25], pic[0x24], serial_hds[0], serial_hds[1], ESCC_CLOCK, 4); memory_region_init_alias(escc_bar, NULL, escc-bar, escc_mem, 0, memory_region_size(escc_mem)); -for(i = 0; i nb_nics; i++) -pci_nic_init_nofail(nd_table[i], pci_bus, ne2k_pci, NULL); - -ide_drive_get(hd, MAX_IDE_BUS); - macio = pci_create(pci_bus, -1, TYPE_NEWWORLD_MACIO); dev = DEVICE(macio); qdev_connect_gpio_out(dev, 0, pic[0x19]); /* CUDA */ @@ -395,6 +388,8 @@ static void ppc_core99_init(MachineState *machine) macio_init(macio, pic_mem, escc_bar); /* We only emulate 2 out of 3 IDE controllers for now */ +ide_drive_get(hd, MAX_IDE_BUS); + macio_ide = MACIO_IDE(object_resolve_path_component(OBJECT(macio), ide[0])); macio_ide_init_drives(macio_ide, hd); @@ -420,9 +415,14 @@ static void ppc_core99_init(MachineState *machine) } } +pci_vga_init(pci_bus); + if (graphic_depth != 15 graphic_depth != 32 graphic_depth != 8) graphic_depth = 15; Missing braces here. +for(i = 0; i nb_nics; i++) +pci_nic_init_nofail(nd_table[i], pci_bus, ne2k_pci, NULL); + And here too. /* The NewWorld NVRAM is not located in the MacIO device */ dev = qdev_create(NULL, TYPE_MACIO_NVRAM); qdev_prop_set_uint32(dev, size, 0x2000); Generally the rule with QEMU is that as you change parts of the code that haven't been touched for a while, you should update them to meet the new style guidelines. Did you run the diffs through scripts/checkpatch.pl at all as that should catch styling points like this? Not this one as I haven't expected it to break anything and I did not expect it to be broken. Sent a v2. Regards, BALATON Zoltan
Re: [Qemu-devel] [PULL 075/118] macio: handle non-block ATAPI DMA transfers
Am 24.06.2014 um 00:41 hat Mark Cave-Ayland geschrieben: On 23/06/14 20:26, BALATON Zoltan wrote: (add Kevin to CC) I'm afraid as you're the only person that can boot MorphOS this far then we need you to diagnose and suggest a suitable alternative by comparing the before and after output. Since MacOS is already a supported client then if no solution can be found then it is likely that this patch will be reverted :( So should I revert the patch for now? We're already in soft freeze. Well let's see if Zoltan can make any headway with debugging over the next few days; if there's no progress by the weekend then sadly my recommendation would be to revert in time for -rc0 as this definitely causes intermittent boot failures in Darwin for me. It would be nicer if it could be fixed instead of reverting. You could help detangling the macio.c code for a start. Just to clarify here: the macio/DBDMA code is quite complicated, but this is because this device has to work around to the fact that currently the DMA I/O routines currently need sector alignment whereas macio requires byte-level alignment. There has been quite a lot of work at the lower levels to support byte-level alignment (see Kevin's series at http://lists.gnu.org/archive/html/qemu-devel/2014-01/msg02163.html) but until we can specify transfers to byte granularity in the dma_bdrv_*() APIs then there isn't much we can do to clean up the macio.c code. Kevin, are there any plans to bubble the byte-granularity block layer changes up to the dma_bdrv_*() APIs in the near future? Not to my knowledge. Block devices allowing byte-granularity accesses (or can you even call them block devices any more then?) seem to be something rather uncommon. So far this macio thing seems to be the only one that needs such functionality. Which probably means that if you guys don't do the conversion, nobody will. Please bear in mind that QEMU supports a large number of OSs, and there is already an enthusiastic group of people using Alex's OS X work (see emaculation for many examples) so introducing an intermittent fault on a supported OS is not an option here. I should also re-emphasise that Alex/Andreas work on many different parts of QEMU, and my work is currently unsponsored so while we are all keen to improve QEMU to the point where it can emulate new OSs such as MorphOS, it's not the case that we can simply drop what we are doing at the time to focus on an issue that affects a single OS which is new and currently unsupported. Now I think it's fair to say that I've spent quite a few hours helping you and coming up with the original version of this patch, and I'm glad that you are now seeing success with this. But what is important to us right now heading towards a release is that patches don't cause any regressions. Yes, I think you're making an important point here. Kevin
Re: [Qemu-devel] [PATCH trivial v2] block.c: Add return value for bdrv_append_temp_snapshot() to avoid incorrect failure processing issue
Am 23.06.2014 um 17:28 hat Chen Gang geschrieben: When failure occurs, 'ret' need be set, or may return 0 to indicate success. And error_propagate() also need be called only one time within a function. It is abnormal to prevent bdrv_append_temp_snapshot() return value but still set errp when error occurs -- although it contents return value internally. So let bdrv_append_temp_snapshot() internal return value outside, and let all things normal, then fix the issue too. Signed-off-by: Chen Gang gang.chen.5...@gmail.com What does this fix? Having both a return value and an Error* object is duplication and only a sign that a function hasn't been fully converted to the Error framework yet. We shouldn't introduce new instances of this without a very good reason. Kevin
Re: [Qemu-devel] [PATCH 0/2] target-ppc: fix unused-function warnings
On 24.06.14 01:05, Peter Maydell wrote: These patches for target-ppc fix clang 3.4 warnings about 'static inline' functions which are defined but never used. (Incidentally, d is a terrible name for a function, so we're well rid of that one :-)) Thanks, applied to ppc-next :). As for d - that's unfortunately how the spec calls the field ;). Alex
Re: [Qemu-devel] [PATCH] uninorth: Fix PCI hole size
On 23.06.14 21:10, BALATON Zoltan wrote: Fix PCI hole size to match that what is found on real hardware. (OpenBIOS already uses the correct length.) Signed-off-by: BALATON Zoltan bala...@eik.bme.hu Thanks, applied to ppc-next. Alex
Re: [Qemu-devel] [PATCH v2] mac99: Add motherboard devices before PCI cards
On 24.06.14 00:03, BALATON Zoltan wrote: Change the order of creating devices for New World Mac emulation so that devices on the motherboard are added first and PCI cards (VGA and NIC) come later. As a side effect, this also causes OpenBIOS to map the motherboard devices into the MMIO space to the same addresses as on real hardware and allow clients that hardcode these addresses (e.g. MorphOS) to find and use them until OpenBIOS is tought to map devices to specific addresses. (On real hardware the graphics and network cards are really on separate buses but we don't model that yet.) This brings the memory map closer to what is found on PowerMac3,1. Signed-off-by: BALATON Zoltan bala...@eik.bme.hu Thanks, applied to ppc-next. Alex
[Qemu-devel] Winter^W Hardfreeze is coming...
Reminder: hardfreeze for 2.1 is the 1st July, which is a week from now. After that we will be committing bugfixes only. If people maintaining submaintainer trees could make sure they get their last pullrequests for any remaining non-bugfix changes onto the list in good time I'd appreciate it. thanks -- PMM
Re: [Qemu-devel] [PULL 075/118] macio: handle non-block ATAPI DMA transfers
On Mon, 23 Jun 2014, Mark Cave-Ayland wrote: On 23/06/14 20:26, BALATON Zoltan wrote: (add Kevin to CC) I'm afraid as you're the only person that can boot MorphOS this far then we need you to diagnose and suggest a suitable alternative by comparing the before and after output. Since MacOS is already a supported client then if no solution can be found then it is likely that this patch will be reverted :( So should I revert the patch for now? We're already in soft freeze. Well let's see if Zoltan can make any headway with debugging over the next few days; if there's no progress by the weekend then sadly my recommendation would be to revert in time for -rc0 as this definitely causes intermittent boot failures in Darwin for me. It would be nicer if it could be fixed instead of reverting. You could help detangling the macio.c code for a start. Just to clarify here: the macio/DBDMA code is quite complicated, but this is because this device has to work around to the fact that currently the DMA I/O routines currently need sector alignment whereas macio requires byte-level alignment. There has been quite a lot of work at the lower levels to support byte-level alignment (see Kevin's series at http://lists.gnu.org/archive/html/qemu-devel/2014-01/msg02163.html) but until we can specify transfers to byte granularity in the dma_bdrv_*() APIs then there isn't much we can do to clean up the macio.c code. Kevin, are there any plans to bubble the byte-granularity block layer changes up to the dma_bdrv_*() APIs in the near future? Please bear in mind that QEMU supports a large number of OSs, and there is already an enthusiastic group of people using Alex's OS X work (see emaculation for many examples) so introducing an intermittent fault on a supported OS is not an option here. I should also re-emphasise that Alex/Andreas work on many different parts of QEMU, and my work is currently unsponsored so while we are all keen to improve QEMU to the point where it can emulate new OSs such as MorphOS, it's not the case that we can simply drop what we are doing at the time to focus on an issue that affects a single OS which is new and currently unsupported. I also work unsponsored on this and not sure how long can I still find time for it. I've already spent much more with this than I originally planned as I'm doing it since end of this February already. So I'd like my work so far to get upstream so that if I have to finish it's not lost and others could use and build on it. If there's no chance that this can be achieved by 2.1 then you could revert this patch and get back to it in 2.2 but that would delay things by months again. My patches are on the list for quite some time so it's not like I'm asking you to work on this in the last minute and this bug was reported on May 4th. I appreciate your help so far very much and don't exepct this to be highest priority but I'd like to make some progress too. Now I think it's fair to say that I've spent quite a few hours helping you and coming up with the original version of this patch, and I'm glad that you Now doubt about that, thank you very much again. are now seeing success with this. But what is important to us right now heading towards a release is that patches don't cause any regressions. All I can say is that debugging this stuff isn't easy, particularly with MorphOS which has some rather unusual behaviours. But what we really need from you now over the next few days is for you to compare the debug output between the working and non-working cases and figure out if we can fix this in time for the 2.1 release. You have everything you need (including my acceptance test of booting both MorphOS and Darwin ISOs), so time to take a deep breath and begin what should be a challenging yet ultimately rewarding debugging process :) I'm still working on finding a solution for the exception problems with OpenBIOS that prevent MorphOS from working and I failed to understand the whole working of macio, DBDMA and the whole block layer so far but I can try to debug it. Can you tell how to reproduce the problem with Darwin? The Darwin images don't seem to work with -M mac99 either before or after the patch so no regressions there. Regards, BALATON Zoltan
Re: [Qemu-devel] [PATCH trivial v2] block.c: Add return value for bdrv_append_temp_snapshot() to avoid incorrect failure processing issue
Kevin Wolf kw...@redhat.com writes:
Am 23.06.2014 um 17:28 hat Chen Gang geschrieben:
When failure occurs, 'ret' need be set, or may return 0 to indicate success.
And error_propagate() also need be called only one time within a function.
It is abnormal to prevent bdrv_append_temp_snapshot() return value but still
set errp when error occurs -- although it contents return value internally.
So let bdrv_append_temp_snapshot() internal return value outside, and let
all things normal, then fix the issue too.
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
What does this fix?
It fixes the return value of bdrv_open() when
bdrv_append_temp_snapshot() fails. Before this patch, it returns a
positive value, which is wrong. After the patch, it returns the
negative error code bdrv_append_temp_snapshot() now returns.
Having both a return value and an Error* object is duplication and
only a sign that a function hasn't been fully converted to the Error
framework yet. We shouldn't introduce new instances of this without a
very good reason.
Maybe. But I very much prefer
ret = foo(arg, errp);
if (ret 0) {
return ret;
}
over
Error *local_err = NULL;
foo(arg, local_err);
if (local_err) {
error_propagate(errp, local_err);
return;
}
Re: [Qemu-devel] [PULL 075/118] macio: handle non-block ATAPI DMA transfers
On 24.06.14 12:53, BALATON Zoltan wrote: On Mon, 23 Jun 2014, Mark Cave-Ayland wrote: On 23/06/14 20:26, BALATON Zoltan wrote: (add Kevin to CC) I'm afraid as you're the only person that can boot MorphOS this far then we need you to diagnose and suggest a suitable alternative by comparing the before and after output. Since MacOS is already a supported client then if no solution can be found then it is likely that this patch will be reverted :( So should I revert the patch for now? We're already in soft freeze. Well let's see if Zoltan can make any headway with debugging over the next few days; if there's no progress by the weekend then sadly my recommendation would be to revert in time for -rc0 as this definitely causes intermittent boot failures in Darwin for me. It would be nicer if it could be fixed instead of reverting. You could help detangling the macio.c code for a start. Just to clarify here: the macio/DBDMA code is quite complicated, but this is because this device has to work around to the fact that currently the DMA I/O routines currently need sector alignment whereas macio requires byte-level alignment. There has been quite a lot of work at the lower levels to support byte-level alignment (see Kevin's series at http://lists.gnu.org/archive/html/qemu-devel/2014-01/msg02163.html) but until we can specify transfers to byte granularity in the dma_bdrv_*() APIs then there isn't much we can do to clean up the macio.c code. Kevin, are there any plans to bubble the byte-granularity block layer changes up to the dma_bdrv_*() APIs in the near future? Please bear in mind that QEMU supports a large number of OSs, and there is already an enthusiastic group of people using Alex's OS X work (see emaculation for many examples) so introducing an intermittent fault on a supported OS is not an option here. I should also re-emphasise that Alex/Andreas work on many different parts of QEMU, and my work is currently unsponsored so while we are all keen to improve QEMU to the point where it can emulate new OSs such as MorphOS, it's not the case that we can simply drop what we are doing at the time to focus on an issue that affects a single OS which is new and currently unsupported. I also work unsponsored on this and not sure how long can I still find time for it. I've already spent much more with this than I originally planned as I'm doing it since end of this February already. So I'd like my work so far to get upstream so that if I have to finish it's not lost and others could use and build on it. If there's no chance that this can be achieved by 2.1 then you could revert this patch and get back to it in 2.2 but that would delay things by months again. My patches are on the list for quite some time so it's not like I'm asking you to work on this in the last minute and this bug was reported on May 4th. I appreciate your help so far very much and don't exepct this to be highest priority but I'd like to make some progress too. Now I think it's fair to say that I've spent quite a few hours helping you and coming up with the original version of this patch, and I'm glad that you Now doubt about that, thank you very much again. are now seeing success with this. But what is important to us right now heading towards a release is that patches don't cause any regressions. All I can say is that debugging this stuff isn't easy, particularly with MorphOS which has some rather unusual behaviours. But what we really need from you now over the next few days is for you to compare the debug output between the working and non-working cases and figure out if we can fix this in time for the 2.1 release. You have everything you need (including my acceptance test of booting both MorphOS and Darwin ISOs), so time to take a deep breath and begin what should be a challenging yet ultimately rewarding debugging process :) I'm still working on finding a solution for the exception problems with OpenBIOS that prevent MorphOS from working and I failed to understand the whole working of macio, DBDMA and the whole block layer so far That one's reasonably simple. On a real Mac, we have different chips implementing IDE and DMA. Traditionally in a non-DMA system, you would have an IDE controller that has a small buffer. When you issue a command, that buffer would get filled and you can poke the IDE controller byte-by-byte to retrieve that buffer. Then people realized that this doesn't perform too well, so they started implementing DMA controllers. The DBDMA controller does this task of poking the IDE controller for you. So instead of hogging the CPU with byte-by-byte transfers from the IDE controller, you now occupy the DMA controller with them, freeing the CPU to do other work. The way DBDMA works is that you put in something similar to a scatter-gather list: A list of chunks to read / write and where in memory those chunks live. DBDMA then goes over its
Re: [Qemu-devel] [PATCH v3 28/32] target-arm: make DFSR banked
On 17 Jun 2014, at 08:12, Edgar E. Iglesias edgar.igles...@gmail.com wrote:
On Fri, Jun 13, 2014 at 05:06:15PM -0500, Greg Bellows wrote:
I just wanted to point out that the change from array-notation to hard-code
numbers in the names undoes Edgar's EL2/EL3 changes. I prefer this way
over the array notation.
Hi,
This was discussed briefly here
http://lists.gnu.org/archive/html/qemu-devel/2014-05/msg03561.html
IMO, for some regs the array version doesn't make sense but for regs
that need to be indexed by EL it does. Just look at what this patch
results in for aarch64_cpu_do_interrupt(). AArch64 has a simpler/cleaner
architecture in this respect, IMO we should keep the
AArch64 simple and clean and take the banking pain in the AArch32 port.
You’re right. I didn’t like the outcome of this change either.
Since we can combine the advantages of both concepts in this compromise I
also vote for changing it to your proposed solution.
On 10 June 2014 18:55, Fabian Aggeler aggel...@ethz.ch wrote:
When EL3 is running in Aarch32 (or ARMv7 with Security Extensions)
DFSR has a secure and a non-secure instance.
Signed-off-by: Fabian Aggeler aggel...@ethz.ch
---
target-arm/cpu.h| 13 -
target-arm/helper-a64.c | 17 ++---
target-arm/helper.c | 15 ---
3 files changed, 34 insertions(+), 11 deletions(-)
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index 54c51a4..71782cf 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -266,7 +266,18 @@ typedef struct CPUARMState {
uint32_t ifsr32_el2;
};
};
-uint64_t esr_el[4];
+union {
+struct {
+uint64_t dfsr_ns;
+uint64_t hsr;
+uint64_t dfsr_s;
+};
+struct {
+uint64_t esr_el1;
+uint64_t esr_el2;
+uint64_t esr_el3;
+};
+};
I'd prefer:
-uint64_t esr_el[4];
+union {
+struct {
+uint64_t dummy
+uint64_t dfsr_ns;
+uint64_t hsr;
+uint64_t dfsr_s;
+};
+struct {
+uint64_t esr_el[4];
+};
+};
And avoid the whole target_esr pointer thing in aarch64_cpu_do_interrupt().
Cheers,
Edgar
uint32_t c6_region[8]; /* MPU base/size registers. */
uint64_t far_el[4]; /* Fault address registers. */
uint64_t par_el1; /* Translation result. */
diff --git a/target-arm/helper-a64.c b/target-arm/helper-a64.c
index d7522b6..dbbf012 100644
--- a/target-arm/helper-a64.c
+++ b/target-arm/helper-a64.c
@@ -447,6 +447,18 @@ void aarch64_cpu_do_interrupt(CPUState *cs)
target_ulong addr = env-cp15.vbar_el[new_el];
unsigned int new_mode = aarch64_pstate_mode(new_el, true);
int i;
+uint64_t *target_esr;
+switch (new_el) {
+case 3:
+target_esr = env-cp15.esr_el3;
+break;
+case 2:
+target_esr = env-cp15.esr_el2;
+break;
+case 1:
+target_esr = env-cp15.esr_el1;
+break;
+}
if (arm_current_pl(env) new_el) {
if (env-aarch64) {
@@ -477,8 +489,7 @@ void aarch64_cpu_do_interrupt(CPUState *cs)
case EXCP_SWI:
case EXCP_HVC:
case EXCP_SMC:
-env-cp15.esr_el[new_el] = env-exception.syndrome;
-break;
+*target_esr = env-exception.syndrome;
case EXCP_IRQ:
case EXCP_VIRQ:
addr += 0x80;
@@ -498,7 +509,7 @@ void aarch64_cpu_do_interrupt(CPUState *cs)
} else {
env-banked_spsr[0] = cpsr_read(env);
if (!env-thumb) {
-env-cp15.esr_el[new_el] |= 1 25;
+*target_esr |= 1 25;
}
env-elr_el[new_el] = env-regs[15];
diff --git a/target-arm/helper.c b/target-arm/helper.c
index f51498a..793985e 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -1492,7 +1492,8 @@ static void vmsa_ttbr_write(CPUARMState *env, const
ARMCPRegInfo *ri,
static const ARMCPRegInfo vmsa_cp_reginfo[] = {
{ .name = DFSR, .cp = 15, .crn = 5, .crm = 0, .opc1 = 0, .opc2 = 0,
.access = PL1_RW, .type = ARM_CP_NO_MIGRATE,
- .fieldoffset = offsetoflow32(CPUARMState, cp15.esr_el[1]),
+ .bank_fieldoffsets = { offsetoflow32(CPUARMState, cp15.dfsr_s),
+ offsetoflow32(CPUARMState, cp15.dfsr_ns) },
.resetfn = arm_cp_reset_ignore, },
{ .name = IFSR, .cp = 15, .crn = 5, .crm = 0, .opc1 = 0, .opc2 = 1,
.access = PL1_RW, .resetvalue = 0,
@@ -1501,7 +1502,7 @@ static const ARMCPRegInfo vmsa_cp_reginfo[] = {
{ .name = ESR_EL1, .state = ARM_CP_STATE_AA64,
.opc0 = 3, .crn = 5, .crm = 2, .opc1 = 0, .opc2 = 0,
.access = PL1_RW,
- .fieldoffset = offsetof(CPUARMState, cp15.esr_el[1]), .resetvalue =
0, },
+
Re: [Qemu-devel] [PATCH v3 32/32] target-arm: make c13 cp regs banked (FCSEIDR, ...)
On 23 Jun 2014, at 23:40, Greg Bellows
greg.bell...@linaro.orgmailto:greg.bell...@linaro.org wrote:
On 10 June 2014 18:55, Fabian Aggeler
aggel...@ethz.chmailto:aggel...@ethz.ch wrote:
When EL3 is running in Aarch32 (or ARMv7 with Security Extensions)
FCSEIDR, CONTEXTIDR, TPIDRURW, TPIDRURO and TPIDRPRW have a secure
and a non-secure instance.
Signed-off-by: Fabian Aggeler aggel...@ethz.chmailto:aggel...@ethz.ch
---
target-arm/cpu.h| 45 -
target-arm/helper.c | 27 +--
2 files changed, 57 insertions(+), 15 deletions(-)
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index c7d606e..13fa966 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -329,11 +329,46 @@ typedef struct CPUARMState {
};
uint64_t vbar_el2;
uint64_t mvbar; /* (monitor) vector base address register */
-uint32_t c13_fcse; /* FCSE PID. */
-uint64_t contextidr_el1; /* Context ID. */
-uint64_t tpidr_el0; /* User RW Thread register. */
-uint64_t tpidrro_el0; /* User RO Thread register. */
-uint64_t tpidr_el1; /* Privileged Thread register. */
+struct { /* FCSE PID. */
+uint32_t c13_fcseidr_ns;
+uint32_t c13_fcseidr_s;
+};
+union { /* Context ID. */
+struct {
+uint64_t contextidr_ns;
+uint64_t contextidr_s;
+};
+struct {
+uint64_t contextidr_el1;
+};
+};
+union { /* User RW Thread register. */
+struct {
+uint64_t tpidrurw_ns;
+uint64_t tpidrurw_s;
+};
+struct {
+uint64_t tpidr_el0;
+};
+};
+union { /* User RO Thread register. */
+struct {
+uint64_t tpidruro_ns;
+uint64_t tpidruro_s;
+};
+struct {
+uint64_t tpidrro_el0;
+};
+};
+union { /* Privileged Thread register. */
+struct {
+uint64_t tpidrprw_ns;
+uint64_t tpidrprw_s;
+};
+struct {
+uint64_t tpidr_el1;
+};
+};
uint64_t c14_cntfrq; /* Counter Frequency register */
uint64_t c14_cntkctl; /* Timer Control register */
ARMGenericTimer c14_timer[NUM_GTIMERS];
diff --git a/target-arm/helper.c b/target-arm/helper.c
index 2d085aa..aebcc62 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -396,12 +396,15 @@ static const ARMCPRegInfo cp_reginfo[] = {
{ .name = DBGDIDR, .cp = 14, .crn = 0, .crm = 0, .opc1 = 0, .opc2 = 0,
.access = PL0_R, .type = ARM_CP_CONST, .resetvalue = 0 },
{ .name = FCSEIDR, .cp = 15, .crn = 13, .crm = 0, .opc1 = 0, .opc2 = 0,
- .access = PL1_RW, .fieldoffset = offsetof(CPUARMState, cp15.c13_fcse),
+ .access = PL1_RW,
+ .bank_fieldoffsets = { offsetof(CPUARMState, cp15.c13_fcseidr_s),
+ offsetof(CPUARMState, cp15.c13_fcseidr_ns) },
.resetvalue = 0, .writefn = fcse_write, .raw_writefn = raw_write, },
{ .name = CONTEXTIDR, .state = ARM_CP_STATE_BOTH,
.opc0 = 3, .opc1 = 0, .crn = 13, .crm = 0, .opc2 = 1,
.access = PL1_RW,
- .fieldoffset = offsetof(CPUARMState, cp15.contextidr_el1),
+ .bank_fieldoffsets = { offsetof(CPUARMState, cp15.contextidr_s),
+ offsetof(CPUARMState, cp15.contextidr_ns) },
.resetvalue = 0, .writefn = contextidr_write, .raw_writefn = raw_write,
},
REGINFO_SENTINEL
};
@@ -889,21 +892,25 @@ static const ARMCPRegInfo v6k_cp_reginfo[] = {
.access = PL0_RW,
.fieldoffset = offsetof(CPUARMState, cp15.tpidr_el0), .resetvalue = 0 },
{ .name = TPIDRURW, .cp = 15, .crn = 13, .crm = 0, .opc1 = 0, .opc2 = 2,
- .access = PL0_RW,
- .fieldoffset = offsetoflow32(CPUARMState, cp15.tpidr_el0),
- .resetfn = arm_cp_reset_ignore },
+ .access = PL0_RW, .resetfn = arm_cp_reset_ignore,
+ .bank_fieldoffsets = { offsetoflow32(CPUARMState, cp15.tpidrurw_s),
+ offsetoflow32(CPUARMState, cp15.tpidrurw_ns) } },
{ .name = TPIDRRO_EL0, .state = ARM_CP_STATE_AA64,
.opc0 = 3, .opc1 = 3, .opc2 = 3, .crn = 13, .crm = 0,
.access = PL0_R|PL1_W,
.fieldoffset = offsetof(CPUARMState, cp15.tpidrro_el0), .resetvalue = 0
},
{ .name = TPIDRURO, .cp = 15, .crn = 13, .crm = 0, .opc1 = 0, .opc2 = 3,
- .access = PL0_R|PL1_W,
- .fieldoffset = offsetoflow32(CPUARMState, cp15.tpidrro_el0),
- .resetfn = arm_cp_reset_ignore },
-{ .name = TPIDR_EL1, .state = ARM_CP_STATE_BOTH,
+ .access = PL0_R|PL1_W, .resetfn = arm_cp_reset_ignore,
+ .bank_fieldoffsets = { offsetoflow32(CPUARMState, cp15.tpidruro_s),
+ offsetoflow32(CPUARMState, cp15.tpidruro_ns) } },
Re: [Qemu-devel] Xen 4.4 with qemu 1.6.2 VGA passthru NVIDIA
CC'ing xen-devel. Could you please post your QEMU logs? On Mon, 23 Jun 2014, Maxim Gordeev wrote: Hi! Please, give me an advice. I try use VGA passthough NVidia k40 on SuperMicro Server, but server is having error. My Xen is using qemu (a9e8aeb3755bccb7b51174adcf4a3fc427e0d147)2.0.0 My VirtualMachine is have config: device_model_version = qemu-xen device_model_override = /opt/sources/qemu-a9e8aeb/x86_64-softmmu/qemu-system-x86_64 When I start VM: dmesg [ 0.906181] pci :00:05.0: BAR 1: can't assign mem pref (size 0x1) [ 0.906187] pci :00:05.0: BAR 1: trying firmware assignment [mem 0x1-0x1 64bit pref] [ 0.906193] pci :00:05.0: BAR 1: assigned [mem 0x1-0x1 64bit pref] and lspci -s 00:05.0 -vvv Region 0: Memory at 8500 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at 1 (64-bit, prefetchable) [size=4G] Region 3: Memory at 8200 (64-bit, prefetchable) [size=32M] Why? This is message in DOM0: lspci -s 03:00.0 -vvv Region 0: Memory at de00 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at 58 (64-bit, prefetchable) [size=16G] Region 3: Memory at 5c (64-bit, prefetchable) [size=32M] Why Qemu don`t mapping BAR1? Thanks! Regards!
Re: [Qemu-devel] machines and versions - why so many?
Am 24.06.2014 07:21, schrieb Paolo Bonzini: Il 24/06/2014 00:33, Alexey Kardashevskiy ha scritto: I actually wonder if it is not going to be -machine pseries-2.0 then what will it look like? -machine pseries,qemucompat=2.0? I would keep using pseries-2.0. There might be some class hierarchy, like spapr-machine spapr-machine-2.2 spapr-machine-2.1 I don't know what Andreas had in mind though, but you can check out Eduardo's patches for QOMifying the PC machines and take inspiration from there. That's probably a safe bet. That's pretty much what I meant, yes. (Eduardo, not Marcel then. :)) Not sure about spapr-machine vs. spapr-machine-2.2, but pseries-2.1-machine inheriting from and overriding properties of pseries[-2.2]-machine definitely. Whatever works. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PULL 00/23] pc,pci,vhost,net fixes, enhancements
On 23 June 2014 16:53, Michael S. Tsirkin m...@redhat.com wrote: The following changes since commit d9c1647d896d3192cba9dbf98fb7efab876edde5: Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' into staging (2014-06-23 12:55:22 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_upstream for you to fetch changes up to c4f5cdc53f181f6fe84a0f1bf99914598934a8a6: xen-hvm: Handle machine opt max-ram-below-4g (2014-06-23 18:02:55 +0300) pc,pci,vhost,net fixes, enhancements Applied, thanks. -- PMM
Re: [Qemu-devel] machines and versions - why so many?
Am 24.06.2014 10:17, schrieb Markus Armbruster: Back then gerd created a way to do the compatibility stuff without getting into the other target's hair: compat_props. They've served us well enough, but now that more targets get interested in migration, their shortcomings start to hurt. Having to duplicate device compatibility gunk in multiple places, all far away from the device, is decidedly suboptimal. Better ideas welcome. Might it make sense to reconsider the proposed machine type hierarchy and have machine-2.2 - pc-i440fx-2.2, with global properties in machine-x.y types and pc_compat_x_y() taking care of PC inheritence? We can't inherit from both pc-x.y and machine-x.y though, so probably not, just throwing thoughts around. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PULL 075/118] macio: handle non-block ATAPI DMA transfers
Am 24.06.2014 um 13:02 hat Alexander Graf geschrieben: The way DBDMA works is that you put in something similar to a scatter-gather list: A list of chunks to read / write and where in memory those chunks live. DBDMA then goes over its list and does the pokes. So for example if the list is [ memaddr = 0x12000 | len = 500 ] [ memaddr = 0x13098 | len = 12 ] then it reads 500 bytes from IDE, writes them at memory offset 0x12000 and after that reads another 12 bytes from IDE and puts them at memory offset 0x13098. The reason we have such complicated code for real DMA is that we can't model this easily with our direct block-to-memory API. That one can only work on a 512 byte granularity. So when we see unaligned accesses like above, we have to split them out and handle them lazily. Wait... What kind of granularity are you talking about? We do need disk accesses with a 512 byte granularity, because the API takes a sector number. This is also what real IDE disks do, they don't provide byte access. However, for the memory, I can't see why you couldn't pass a s/g list like what you wrote above to the DMA functions. This is not unusual at all and is the same as ide/pci.c does. There is no 512-byte alignment needed for the individual s/g list entries, only the total size should obviously be a multiple of 512 in the general case (otherwise the list would be too short or too long for the request). If this is really what we're talking about, then I think your problem is just that you try to handle the 500 byte and the 12 byte as individual requests instead of building up the s/g list and then sending a single request. Kevin
Re: [Qemu-devel] [PULL 075/118] macio: handle non-block ATAPI DMA transfers
On 24.06.14 13:22, Kevin Wolf wrote: Am 24.06.2014 um 13:02 hat Alexander Graf geschrieben: The way DBDMA works is that you put in something similar to a scatter-gather list: A list of chunks to read / write and where in memory those chunks live. DBDMA then goes over its list and does the pokes. So for example if the list is [ memaddr = 0x12000 | len = 500 ] [ memaddr = 0x13098 | len = 12 ] then it reads 500 bytes from IDE, writes them at memory offset 0x12000 and after that reads another 12 bytes from IDE and puts them at memory offset 0x13098. The reason we have such complicated code for real DMA is that we can't model this easily with our direct block-to-memory API. That one can only work on a 512 byte granularity. So when we see unaligned accesses like above, we have to split them out and handle them lazily. Wait... What kind of granularity are you talking about? We do need disk accesses with a 512 byte granularity, because the API takes a sector number. This is also what real IDE disks do, they don't provide byte access. However, for the memory, I can't see why you couldn't pass a s/g list like what you wrote above to the DMA functions. This is not unusual at all and is the same as ide/pci.c does. There is no 512-byte alignment needed for the individual s/g list entries, only the total size should obviously be a multiple of 512 in the general case (otherwise the list would be too short or too long for the request). If this is really what we're talking about, then I think your problem is just that you try to handle the 500 byte and the 12 byte as individual requests instead of building up the s/g list and then sending a single request. The 500 and 12 byte requests can come in as separate requests that require previous requests to have finished. What Mac OS X does for example is [ memaddr = 0x2000 | len = 1024 ] [ memaddr = 0x1000 | len = 510 ] wait for ack [ memaddr = 0x10fe | len = 2 ] [ memaddr = 0x3000 | len = 2048 ] If it was as simple as creating a working sglist, I would've certainly done so long ago :). Alex
Re: [Qemu-devel] [PATCH 3/3 v2] ppc debug: Add debug stub support
On 18.06.14 06:39, bharat.bhus...@freescale.com wrote:
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Tuesday, June 17, 2014 4:14 PM
To: Bhushan Bharat-R65777; qemu-...@nongnu.org; qemu-devel@nongnu.org
Subject: Re: [PATCH 3/3 v2] ppc debug: Add debug stub support
On 17.06.14 12:40, bharat.bhus...@freescale.com wrote:
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Tuesday, June 17, 2014 3:20 PM
To: Bhushan Bharat-R65777; qemu-...@nongnu.org; qemu-devel@nongnu.org
Subject: Re: [PATCH 3/3 v2] ppc debug: Add debug stub support
On 17.06.14 11:14, bharat.bhus...@freescale.com wrote:
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Tuesday, June 17, 2014 1:46 PM
To: Bhushan Bharat-R65777; qemu-...@nongnu.org;
qemu-devel@nongnu.org
Subject: Re: [PATCH 3/3 v2] ppc debug: Add debug stub support
On 17.06.14 09:08, Bharat Bhushan wrote:
This patch adds software breakpoint, hardware breakpoint and
hardware watchpoint support for ppc. If the debug interrupt is not
handled then this is injected to guest.
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
v1-v2:
- factored out e500 specific code based on exception model
POWERPC_EXCP_BOOKE.
- Not supporting ppc440
hw/ppc/e500.c| 3 +
target-ppc/kvm.c | 355
++---
--
target-ppc/kvm_ppc.h | 1 +
3 files changed, 330 insertions(+), 29 deletions(-)
diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c index a973c18..47caa84
100644
--- a/hw/ppc/e500.c
+++ b/hw/ppc/e500.c
@@ -853,6 +853,9 @@ void ppce500_init(MachineState *machine,
PPCE500Params
*params)
if (kvm_enabled()) {
kvmppc_init();
}
+
+/* E500 supports 2 h/w breakpoints and 2 watchpoints */
+kvmppc_hw_breakpoint_init(2, 2);
This does not belong into the machine file.
What about calling this from init_proc_e500() in target-ppc/translate_init.c
?
I think it makes sense to leave it in KVM land. Why not do it lazily
on insert_hw_breakpoint?
You mean setting in kvm_arch_insert_hw_breakpoint() when called first time;
something like:
static bool init = 0;
if (!init) {
if (env-excp_model == POWERPC_EXCP_BOOKE) {
max_hw_breakpoint = 2;
max_hw_watchpoint = 2;
} else
// Add for book3s max_hw_watchpoint = 1;
}
init = 1;
}
I would probably reuse max_hw_breakpoint as a hint whether it's initialized and
put all of this into a small function, but yes :).
Ahh, we cannot do this in kvm_arch_insert_hw_breakpoint() as we can not get
env reference in this function. Prototype of this is:
int kvm_arch_insert_hw_breakpoint(target_ulong addr, target_ulong len, int
type);
Just use first_cpu? :)
I will suggest that we initialize this from kvm_arch_init_vcpu(). This way we
are still in KVM zone.
That works too, yes.
Alex
Re: [Qemu-devel] [PATCH v2 0/4] mirror: Fix behavior for zero byte image
Am 24.06.2014 um 06:25 hat Fam Zheng geschrieben:
On Mon, 06/09 10:56, Fam Zheng wrote:
The current behavior of mirroring zero byte image is slightly different from
non-zero image: the BLOCK_JOB_READY event is skipped and job is completed
immediately. This is not a big problem for human user but only makes
management
software harder to write. Since we are focusing on an good API instead of
UI,
let's make the behavior more consistent and predictable.
The first patch fixes the behavior. The following two patches add test case
for
the involved code path.
Thanks for Eric Blake to report this!
Ping. Shall we merge this before it rots?
I had it already applied, but now test case 041 fails for me, so I'm
going to remove it from my tree again:
041 7s ...[13:28:48] [13:29:27] [failed, exit status 1] - output
mismatch (see 041.out.bad)
--- 041.out 2014-06-24 13:23:13.597949977 +0200
+++ 041.out.bad 2014-06-24 13:29:27.024871226 +0200
@@ -1,5 +1,31 @@
-.
+qemu-img: /home/kwolf/source/qemu/tests/qemu-iotests/scratch/target.img:
Cluster size must be a power of two between 512 and 2048k
+qemu-img: /home/kwolf/source/qemu/tests/qemu-iotests/scratch/target.img:
Cluster size must be a power of two between 512 and 2048k
+..F...F..
+==
+FAIL: test_large_cluster (__main__.TestSingleDriveZeroLength)
+--
+Traceback (most recent call last):
+ File ./041, line 185, in test_large_cluster
+self.assert_qmp(result, 'return', {})
+ File /home/kwolf/source/qemu/tests/qemu-iotests/iotests.py, line 232, in
assert_qmp
+result = self.dictpath(d, path)
+ File /home/kwolf/source/qemu/tests/qemu-iotests/iotests.py, line 211, in
dictpath
+self.fail('failed path traversal for %s in %s' % (path, str(d)))
+AssertionError: failed path traversal for return in {u'error': {u'class':
u'GenericError', u'desc': uCould not open
'/home/kwolf/source/qemu/tests/qemu-iotests/scratch/target.img': No such file
or directory}}
+
+==
+FAIL: test_small_buffer2 (__main__.TestSingleDriveZeroLength)
+--
+Traceback (most recent call last):
+ File ./041, line 169, in test_small_buffer2
+self.assert_qmp(result, 'return', {})
+ File /home/kwolf/source/qemu/tests/qemu-iotests/iotests.py, line 232, in
assert_qmp
+result = self.dictpath(d, path)
+ File /home/kwolf/source/qemu/tests/qemu-iotests/iotests.py, line 211, in
dictpath
+self.fail('failed path traversal for %s in %s' % (path, str(d)))
+AssertionError: failed path traversal for return in {u'error': {u'class':
u'GenericError', u'desc': uCould not open
'/home/kwolf/source/qemu/tests/qemu-iotests/scratch/target.img': No such file
or directory}}
+
--
Ran 37 tests
-OK
+FAILED (failures=2)
Failures: 041
Re: [Qemu-devel] [PATCH 3/3 v2] ppc debug: Add debug stub support
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Tuesday, June 24, 2014 5:02 PM
To: Bhushan Bharat-R65777; qemu-...@nongnu.org; qemu-devel@nongnu.org
Subject: Re: [PATCH 3/3 v2] ppc debug: Add debug stub support
On 18.06.14 06:39, bharat.bhus...@freescale.com wrote:
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Tuesday, June 17, 2014 4:14 PM
To: Bhushan Bharat-R65777; qemu-...@nongnu.org; qemu-devel@nongnu.org
Subject: Re: [PATCH 3/3 v2] ppc debug: Add debug stub support
On 17.06.14 12:40, bharat.bhus...@freescale.com wrote:
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Tuesday, June 17, 2014 3:20 PM
To: Bhushan Bharat-R65777; qemu-...@nongnu.org;
qemu-devel@nongnu.org
Subject: Re: [PATCH 3/3 v2] ppc debug: Add debug stub support
On 17.06.14 11:14, bharat.bhus...@freescale.com wrote:
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Tuesday, June 17, 2014 1:46 PM
To: Bhushan Bharat-R65777; qemu-...@nongnu.org;
qemu-devel@nongnu.org
Subject: Re: [PATCH 3/3 v2] ppc debug: Add debug stub support
On 17.06.14 09:08, Bharat Bhushan wrote:
This patch adds software breakpoint, hardware breakpoint and
hardware watchpoint support for ppc. If the debug interrupt is
not handled then this is injected to guest.
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
v1-v2:
- factored out e500 specific code based on exception model
POWERPC_EXCP_BOOKE.
- Not supporting ppc440
hw/ppc/e500.c| 3 +
target-ppc/kvm.c | 355
++---
--
target-ppc/kvm_ppc.h | 1 +
3 files changed, 330 insertions(+), 29 deletions(-)
diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c index
a973c18..47caa84
100644
--- a/hw/ppc/e500.c
+++ b/hw/ppc/e500.c
@@ -853,6 +853,9 @@ void ppce500_init(MachineState *machine,
PPCE500Params
*params)
if (kvm_enabled()) {
kvmppc_init();
}
+
+/* E500 supports 2 h/w breakpoints and 2 watchpoints */
+kvmppc_hw_breakpoint_init(2, 2);
This does not belong into the machine file.
What about calling this from init_proc_e500() in
target-ppc/translate_init.c
?
I think it makes sense to leave it in KVM land. Why not do it
lazily on insert_hw_breakpoint?
You mean setting in kvm_arch_insert_hw_breakpoint() when called
first time;
something like:
static bool init = 0;
if (!init) {
if (env-excp_model == POWERPC_EXCP_BOOKE) {
max_hw_breakpoint = 2;
max_hw_watchpoint = 2;
} else
// Add for book3s max_hw_watchpoint = 1;
}
init = 1;
}
I would probably reuse max_hw_breakpoint as a hint whether it's
initialized and put all of this into a small function, but yes :).
Ahh, we cannot do this in kvm_arch_insert_hw_breakpoint() as we can not get
env reference in this function. Prototype of this is:
int kvm_arch_insert_hw_breakpoint(target_ulong addr, target_ulong len,
int type);
Just use first_cpu? :)
I will suggest that we initialize this from kvm_arch_init_vcpu(). This way
we
are still in KVM zone.
That works too, yes.
V3 version of path is based on this :)
Thanks
-Bharat
Alex
Re: [Qemu-devel] [PATCH 3/3 v2] ppc debug: Add debug stub support
On 24.06.14 13:32, bharat.bhus...@freescale.com wrote:
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Tuesday, June 24, 2014 5:02 PM
To: Bhushan Bharat-R65777; qemu-...@nongnu.org; qemu-devel@nongnu.org
Subject: Re: [PATCH 3/3 v2] ppc debug: Add debug stub support
On 18.06.14 06:39, bharat.bhus...@freescale.com wrote:
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Tuesday, June 17, 2014 4:14 PM
To: Bhushan Bharat-R65777; qemu-...@nongnu.org; qemu-devel@nongnu.org
Subject: Re: [PATCH 3/3 v2] ppc debug: Add debug stub support
On 17.06.14 12:40, bharat.bhus...@freescale.com wrote:
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Tuesday, June 17, 2014 3:20 PM
To: Bhushan Bharat-R65777; qemu-...@nongnu.org;
qemu-devel@nongnu.org
Subject: Re: [PATCH 3/3 v2] ppc debug: Add debug stub support
On 17.06.14 11:14, bharat.bhus...@freescale.com wrote:
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Tuesday, June 17, 2014 1:46 PM
To: Bhushan Bharat-R65777; qemu-...@nongnu.org;
qemu-devel@nongnu.org
Subject: Re: [PATCH 3/3 v2] ppc debug: Add debug stub support
On 17.06.14 09:08, Bharat Bhushan wrote:
This patch adds software breakpoint, hardware breakpoint and
hardware watchpoint support for ppc. If the debug interrupt is
not handled then this is injected to guest.
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
v1-v2:
- factored out e500 specific code based on exception model
POWERPC_EXCP_BOOKE.
- Not supporting ppc440
hw/ppc/e500.c| 3 +
target-ppc/kvm.c | 355
++---
--
target-ppc/kvm_ppc.h | 1 +
3 files changed, 330 insertions(+), 29 deletions(-)
diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c index
a973c18..47caa84
100644
--- a/hw/ppc/e500.c
+++ b/hw/ppc/e500.c
@@ -853,6 +853,9 @@ void ppce500_init(MachineState *machine,
PPCE500Params
*params)
if (kvm_enabled()) {
kvmppc_init();
}
+
+/* E500 supports 2 h/w breakpoints and 2 watchpoints */
+kvmppc_hw_breakpoint_init(2, 2);
This does not belong into the machine file.
What about calling this from init_proc_e500() in
target-ppc/translate_init.c
?
I think it makes sense to leave it in KVM land. Why not do it
lazily on insert_hw_breakpoint?
You mean setting in kvm_arch_insert_hw_breakpoint() when called
first time;
something like:
static bool init = 0;
if (!init) {
if (env-excp_model == POWERPC_EXCP_BOOKE) {
max_hw_breakpoint = 2;
max_hw_watchpoint = 2;
} else
// Add for book3s max_hw_watchpoint = 1;
}
init = 1;
}
I would probably reuse max_hw_breakpoint as a hint whether it's
initialized and put all of this into a small function, but yes :).
Ahh, we cannot do this in kvm_arch_insert_hw_breakpoint() as we can not get
env reference in this function. Prototype of this is:
int kvm_arch_insert_hw_breakpoint(target_ulong addr, target_ulong len,
int type);
Just use first_cpu? :)
I will suggest that we initialize this from kvm_arch_init_vcpu(). This way we
are still in KVM zone.
That works too, yes.
V3 version of path is based on this :)
Uh, I don't see a v3 yet? :)
Alex
Re: [Qemu-devel] [Qemu-ppc] [PATCH 1/4] spapr: Add rtas_st_buffer utility function
On 24.06.14 02:22, Sam Bobroff wrote:
Add a function to write lengh + data into a buffer as required for the
emulation of the RTAS ibm,get-system-parameter call.
If the destination is smaller than the source, the write is truncated
and success is returned. This matches the behaviour of pHyp.
This will be used in following patches.
Signed-off-by: Sam Bobroff sam.bobr...@au1.ibm.com
---
include/hw/ppc/spapr.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
index 08c301f..39a7764 100644
--- a/include/hw/ppc/spapr.h
+++ b/include/hw/ppc/spapr.h
@@ -373,6 +373,23 @@ static inline void rtas_st(target_ulong phys, int n,
uint32_t val)
stl_be_phys(address_space_memory, ppc64_phys_to_real(phys + 4*n), val);
}
+
+static inline void rtas_st_buffer(target_ulong phys, target_ulong phys_len,
+ uint8_t *buffer, uint16_t buffer_len)
+{
+uint16_t i;
+
+if (phys_len 2) {
+return;
+}
+stw_be_phys(address_space_memory,
+ppc64_phys_to_real(phys), buffer_len);
+for (i = 0; i MIN(buffer_len, phys_len - 2); i++) {
+stb_phys(address_space_memory,
+ ppc64_phys_to_real(phys + 2 + i), buffer[i]);
+}
cpu_physical_memory_write()?
Alex
Re: [Qemu-devel] [PATCH v2 22/22] target-mips: define a new generic CPU supporting MIPS64R6
On 19/06/2014 23:16, Aurelien Jarno wrote:
On Wed, Jun 11, 2014 at 04:19:52PM +0100, Leon Alrae wrote:
Signed-off-by: Leon Alrae leon.al...@imgtec.com
---
target-mips/translate_init.c | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/target-mips/translate_init.c b/target-mips/translate_init.c
index 29dc2ef..0adbb19 100644
--- a/target-mips/translate_init.c
+++ b/target-mips/translate_init.c
@@ -516,6 +516,35 @@ static const mips_def_t mips_defs[] =
.mmu_type = MMU_TYPE_R4000,
},
{
+/* A generic CPU providing MIPS64 Release 6 features.
+ FIXME: Eventually this should be replaced by a real CPU model. */
+.name = MIPS64R6-generic,
+.CP0_PRid = 0x0001,
+.CP0_Config0 = MIPS_CONFIG0 | (0x2 CP0C0_AR) | (0x2 CP0C0_AT)
|
+ (MMU_TYPE_R4000 CP0C0_MT),
+.CP0_Config1 = MIPS_CONFIG1 | (1 CP0C1_FP) | (63 CP0C1_MMU) |
+ (2 CP0C1_IS) | (4 CP0C1_IL) | (3 CP0C1_IA) |
+ (2 CP0C1_DS) | (4 CP0C1_DL) | (3 CP0C1_DA) |
+ (0 CP0C1_PC) | (1 CP0C1_WR) | (1 CP0C1_EP),
+.CP0_Config2 = MIPS_CONFIG2,
+.CP0_Config3 = MIPS_CONFIG3,
+.CP0_LLAddr_rw_bitmask = 0,
+.CP0_LLAddr_shift = 0,
+.SYNCI_Step = 32,
+.CCRes = 2,
+.CP0_Status_rw_bitmask = 0x30D8,
+.CP1_fcr0 = (1 FCR0_F64) | (1 FCR0_L) | (1 FCR0_W) |
+(1 FCR0_D) | (1 FCR0_S) | (0x00 FCR0_PRID) |
+(0x0 FCR0_REV),
+.SEGBITS = 42,
+/* The architectural limit is 59, but we have hardcoded 36 bit
+ in some places...
+.PABITS = 59, */ /* the architectural limit */
+.PABITS = 36,
+.insn_flags = CPU_MIPS64R6,
+.mmu_type = MMU_TYPE_R4000,
+},
+{
.name = Loongson-2E,
.CP0_PRid = 0x6302,
/*64KB I-cache and d-cache. 4 way with 32 bit cache line size*/
Sorry to say that again, but I think it should be deferred to the point
where the MIPS R6 CPU is fully functional, so probably after the
implement features required in MIPS64 Release 6, and probably even
more, as I haven't seen any patch concerning the unaligned access
support yet.
It will take some time before MIPS R6 CPU becomes fully functional. With
the current patchset QEMU should be able to run R6 binaries in userland
emulation mode where we don't care about KScratch, TLBINV etc. Thus I
think having available MIPS R6 CPU might be handy at this point (even
though there are limitations regarding unaligned access or forbidden
slot support).
Regards,
Leon
Re: [Qemu-devel] [Qemu-ppc] [PATCH 3/4] spapr: Fix RTAS sysparm DIAGNOSTICS_RUN_MODE
On 24.06.14 02:22, Sam Bobroff wrote:
This allows the ibm,get-system-parameter RTAS call to succeed for the
DIAGNOSTICS_RUN_MODE system parameter.
The problem can be seen with ppc64_cpu --run-mode from the
powerpc-utils package which fails before this patch with Machine does
not support diagnostic run mode.
This is corrected by using the rtas_st_buffer() function to write to
the buffer.
The function return value code is also slightly simplified.
Signed-off-by: Sam Bobroff sam.bobr...@au1.ibm.com
---
hw/ppc/spapr_rtas.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/hw/ppc/spapr_rtas.c b/hw/ppc/spapr_rtas.c
index 4f87673..8d94845 100644
--- a/hw/ppc/spapr_rtas.c
+++ b/hw/ppc/spapr_rtas.c
@@ -236,19 +236,18 @@ static void rtas_ibm_get_system_parameter(PowerPCCPU *cpu,
target_ulong parameter = rtas_ld(args, 0);
target_ulong buffer = rtas_ld(args, 1);
target_ulong length = rtas_ld(args, 2);
-target_ulong ret = RTAS_OUT_NOT_SUPPORTED;
+target_ulong ret = RTAS_OUT_SUCCESS;
+uint8_t zero = 0;
switch (parameter) {
case DIAGNOSTICS_RUN_MODE:
-if (length == 1) {
-rtas_st(buffer, 0, 0);
-ret = RTAS_OUT_SUCCESS;
-}
+rtas_st_buffer(buffer, length, zero, sizeof zero);
Please use sizeof(zero) here :).
Alex
Re: [Qemu-devel] [Qemu-ppc] [PATCH 3/4] spapr: Fix RTAS sysparm DIAGNOSTICS_RUN_MODE
On 24.06.14 13:58, Alexander Graf wrote:
On 24.06.14 02:22, Sam Bobroff wrote:
This allows the ibm,get-system-parameter RTAS call to succeed for the
DIAGNOSTICS_RUN_MODE system parameter.
The problem can be seen with ppc64_cpu --run-mode from the
powerpc-utils package which fails before this patch with Machine does
not support diagnostic run mode.
This is corrected by using the rtas_st_buffer() function to write to
the buffer.
The function return value code is also slightly simplified.
Signed-off-by: Sam Bobroff sam.bobr...@au1.ibm.com
---
hw/ppc/spapr_rtas.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/hw/ppc/spapr_rtas.c b/hw/ppc/spapr_rtas.c
index 4f87673..8d94845 100644
--- a/hw/ppc/spapr_rtas.c
+++ b/hw/ppc/spapr_rtas.c
@@ -236,19 +236,18 @@ static void
rtas_ibm_get_system_parameter(PowerPCCPU *cpu,
target_ulong parameter = rtas_ld(args, 0);
target_ulong buffer = rtas_ld(args, 1);
target_ulong length = rtas_ld(args, 2);
-target_ulong ret = RTAS_OUT_NOT_SUPPORTED;
+target_ulong ret = RTAS_OUT_SUCCESS;
+uint8_t zero = 0;
switch (parameter) {
case DIAGNOSTICS_RUN_MODE:
-if (length == 1) {
-rtas_st(buffer, 0, 0);
-ret = RTAS_OUT_SUCCESS;
-}
+rtas_st_buffer(buffer, length, zero, sizeof zero);
Please use sizeof(zero) here :).
Also while at it, please make the code slightly more readable. We don't
pass in zero, we pass in DIAGNOSTICS_RUN_MODE_DISABLED, no? Please
define the possible values in a header file and set it accordingly here.
Since it's limited to DIAGNOSTICS_RUN_MODE, please also make the
variable limited to that scope then.
Alex
Re: [Qemu-devel] [Qemu-ppc] [PATCH 4/4] spapr: Add RTAS sysparm SPLPAR Characteristics
On 24.06.14 02:22, Sam Bobroff wrote:
Add support for the SPLPAR Characteristics parameter to the emulated
RTAS call ibm,get-system-parameter.
The support provides just enough information to allow cat
/proc/powerpc/lparcfg to succeed without generating a kernel error
message.
Without this patch the above command will produce the following kernel
message: arch/powerpc/platforms/pseries/lparcfg.c \
parse_system_parameter_string Error calling get-system-parameter \
(0xfffd)
Signed-off-by: Sam Bobroff sam.bobr...@au1.ibm.com
---
hw/ppc/spapr_rtas.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/hw/ppc/spapr_rtas.c b/hw/ppc/spapr_rtas.c
index 8d94845..4270e7a 100644
--- a/hw/ppc/spapr_rtas.c
+++ b/hw/ppc/spapr_rtas.c
@@ -224,6 +224,7 @@ static void rtas_stop_self(PowerPCCPU *cpu,
sPAPREnvironment *spapr,
env-msr = 0;
}
+#define SPLPAR_CHARACTERISTICS 20
#define DIAGNOSTICS_RUN_MODE42
#define UUID48
@@ -238,8 +239,20 @@ static void rtas_ibm_get_system_parameter(PowerPCCPU *cpu,
target_ulong length = rtas_ld(args, 2);
target_ulong ret = RTAS_OUT_SUCCESS;
uint8_t zero = 0;
+uint8_t param_buf[64];
+int param_len;
switch (parameter) {
+case SPLPAR_CHARACTERISTICS:
+param_len = snprintf((char *)param_buf, sizeof param_buf,
+ MaxEntCap=%d,MaxPlatProcs=%d,
+ max_cpus, smp_cpus);
We have a nice g_strdup_printf() helper function that allocates memory
for us automatically based on the printf size. Just use that one here ;).
Alex
Re: [Qemu-devel] [Qemu-ppc] [PATCH 0/4] spapr: improve RTAS get_system_parameter
On 24.06.14 02:22, Sam Bobroff wrote: This series of patches improves QEMU's emulation of the RTAS call ibm,get-system-parameter by adding support for the UUID and SPLPAR Characteristics parameters as well as fixing a problem in the the implementation of the Platform Processor Diagnostics Run Mode parameter. It also improves the surrounding code a little to support the addition of additional system parameters. Very nice patch set. Please address the few minor nits I had on it, send a v2 and it's ready to go in I think ;) Alex
Re: [Qemu-devel] [PULL 075/118] macio: handle non-block ATAPI DMA transfers
Am 24.06.2014 um 13:27 hat Alexander Graf geschrieben: On 24.06.14 13:22, Kevin Wolf wrote: Am 24.06.2014 um 13:02 hat Alexander Graf geschrieben: The way DBDMA works is that you put in something similar to a scatter-gather list: A list of chunks to read / write and where in memory those chunks live. DBDMA then goes over its list and does the pokes. So for example if the list is [ memaddr = 0x12000 | len = 500 ] [ memaddr = 0x13098 | len = 12 ] then it reads 500 bytes from IDE, writes them at memory offset 0x12000 and after that reads another 12 bytes from IDE and puts them at memory offset 0x13098. The reason we have such complicated code for real DMA is that we can't model this easily with our direct block-to-memory API. That one can only work on a 512 byte granularity. So when we see unaligned accesses like above, we have to split them out and handle them lazily. Wait... What kind of granularity are you talking about? We do need disk accesses with a 512 byte granularity, because the API takes a sector number. This is also what real IDE disks do, they don't provide byte access. However, for the memory, I can't see why you couldn't pass a s/g list like what you wrote above to the DMA functions. This is not unusual at all and is the same as ide/pci.c does. There is no 512-byte alignment needed for the individual s/g list entries, only the total size should obviously be a multiple of 512 in the general case (otherwise the list would be too short or too long for the request). If this is really what we're talking about, then I think your problem is just that you try to handle the 500 byte and the 12 byte as individual requests instead of building up the s/g list and then sending a single request. The 500 and 12 byte requests can come in as separate requests that require previous requests to have finished. What Mac OS X does for example is [ memaddr = 0x2000 | len = 1024 ] [ memaddr = 0x1000 | len = 510 ] wait for ack [ memaddr = 0x10fe | len = 2 ] [ memaddr = 0x3000 | len = 2048 ] If it was as simple as creating a working sglist, I would've certainly done so long ago :). Thanks, that's the explanation that was missing for me (I'm sure you explained it more than once to me in the past few years, but I keep forgetting). This means, however, that exposing the byte access in the block layer is probably not what you want. Otherwise you would read the same sector twice from the image (assuming cache=none, so the backend must have 512-byte alignment). If you do the handling in the device emulation you can read the full request once and then only do the DMA part with a byte granularity. I suppose this is the complicated code that you have today? Kevin
Re: [Qemu-devel] [PATCH v2 16/22] target-mips: add new Floating Point instructions
On 20/06/2014 22:14, Aurelien Jarno wrote: In R6 all Floating Point instructions are supposed to be IEEE-2008 compliant i.e. FIR.HAS2008 always 1. However, QEMU softfloat for MIPS has not been updated yet. I don't think we can update softfloat. The existing version has to stay to correctly emulate the existing CPU, and unfortunately things like the sNaN bit is not even configurable at runtime, but fixed at compile time (in softfloat-specialize.h). How do you plan to handle that? I'm aware of this. By update softfloat I meant making it configurable at runtime for MIPS depending on FIR.HAS2008, FCSR.NAN2008 and FCSR.ABS2008 flags, so legacy MIPS FPU will be still available for existing CPUs. +DEF_HELPER_1(float_class_s, i32, i32) +DEF_HELPER_1(float_class_d, i64, i64) + +DEF_HELPER_2(float_rint_s, i32, env, i32) +DEF_HELPER_2(float_rint_d, i64, env, i64) + +DEF_HELPER_4(float_maddf_s, i32, env, i32, i32, i32) +DEF_HELPER_4(float_maddf_d, i64, env, i64, i64, i64) + +DEF_HELPER_4(float_msubf_s, i32, env, i32, i32, i32) +DEF_HELPER_4(float_msubf_d, i64, env, i64, i64, i64) + Why not using FOP_PROTO here? I'll correct it. Thanks, Leon
[Qemu-devel] [PATCH 0/5 v3][RESEND] ppc: Add debug stub support
This patchset add support for - software breakpoint - h/w breakpoint - h/w watchpoint Please find description in individual patch. 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 (5): ppc: debug stub: Get trap instruction opcode from KVM ppc: Add interface to inject interrupt to guest ppc: Add debug interrupt injection handler ppc: Add software breakpoint support ppc: Add hw breakpoint watchpoint support target-ppc/kvm.c | 392 +++ 1 file changed, 364 insertions(+), 28 deletions(-) -- 1.9.0
[Qemu-devel] [PATCH 1/5 v3][RESEND] 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 --- target-ppc/kvm.c | 4 1 file changed, 4 insertions(+) diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c index dfa5a26..1f78cd1 100644 --- a/target-ppc/kvm.c +++ b/target-ppc/kvm.c @@ -71,6 +71,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 @@ -434,6 +436,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.0
Re: [Qemu-devel] [PULL 075/118] macio: handle non-block ATAPI DMA transfers
On 24.06.14 14:07, Kevin Wolf wrote: Am 24.06.2014 um 13:27 hat Alexander Graf geschrieben: On 24.06.14 13:22, Kevin Wolf wrote: Am 24.06.2014 um 13:02 hat Alexander Graf geschrieben: The way DBDMA works is that you put in something similar to a scatter-gather list: A list of chunks to read / write and where in memory those chunks live. DBDMA then goes over its list and does the pokes. So for example if the list is [ memaddr = 0x12000 | len = 500 ] [ memaddr = 0x13098 | len = 12 ] then it reads 500 bytes from IDE, writes them at memory offset 0x12000 and after that reads another 12 bytes from IDE and puts them at memory offset 0x13098. The reason we have such complicated code for real DMA is that we can't model this easily with our direct block-to-memory API. That one can only work on a 512 byte granularity. So when we see unaligned accesses like above, we have to split them out and handle them lazily. Wait... What kind of granularity are you talking about? We do need disk accesses with a 512 byte granularity, because the API takes a sector number. This is also what real IDE disks do, they don't provide byte access. However, for the memory, I can't see why you couldn't pass a s/g list like what you wrote above to the DMA functions. This is not unusual at all and is the same as ide/pci.c does. There is no 512-byte alignment needed for the individual s/g list entries, only the total size should obviously be a multiple of 512 in the general case (otherwise the list would be too short or too long for the request). If this is really what we're talking about, then I think your problem is just that you try to handle the 500 byte and the 12 byte as individual requests instead of building up the s/g list and then sending a single request. The 500 and 12 byte requests can come in as separate requests that require previous requests to have finished. What Mac OS X does for example is [ memaddr = 0x2000 | len = 1024 ] [ memaddr = 0x1000 | len = 510 ] wait for ack [ memaddr = 0x10fe | len = 2 ] [ memaddr = 0x3000 | len = 2048 ] If it was as simple as creating a working sglist, I would've certainly done so long ago :). Thanks, that's the explanation that was missing for me (I'm sure you explained it more than once to me in the past few years, but I keep forgetting). This means, however, that exposing the byte access in the block layer is probably not what you want. Otherwise you would read the same sector twice from the image (assuming cache=none, so the backend must have 512-byte alignment). If you do the handling in the device emulation you can read the full request once and then only do the DMA part with a byte granularity. I suppose this is the complicated code that you have today? Yes and no. We are trying to be slightly smarter than that. For all the aligned pieces in between the just have a fast path doing straight DMA to/from memory. For the tiny unaligned chunks, we read into a temporary buffer and do DMA byte-wise from that one manually. For writes it's the reverse - we only issue the full sector IDE transfer after our temporary buffer is fully filled. I think it's perfectly reasonable to read the sector twice from the image though if that makes the DBDMA emulation code easier to maintain ;). Right now there are just way too many tiny corner cases lingering. Alex
[Qemu-devel] [PATCH 3/5 v3][RESEND] ppc: Add debug interrupt injection handler
With this patch a debug interrupt can be injected to guest.
Follow up patch will use this interface to inject debug
interrupt to guest if qemu will not be able to handle.
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
target-ppc/kvm.c | 53 +++--
1 file changed, 51 insertions(+), 2 deletions(-)
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 70f77d1..5238de7 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -759,11 +759,59 @@ static int kvm_put_vpa(CPUState *cs)
}
#endif /* TARGET_PPC64 */
-static int kvmppc_inject_debug_exception(CPUState *cs)
+static int kvmppc_e500_inject_debug_exception(CPUState *cs)
{
+PowerPCCPU *cpu = POWERPC_CPU(cs);
+CPUPPCState *env = cpu-env;
+struct kvm_sregs sregs;
+int ret;
+
+if (!cap_booke_sregs) {
+return -1;
+}
+
+ret = kvm_vcpu_ioctl(cs, KVM_GET_SREGS, sregs);
+if (ret 0) {
+return -1;
+}
+
+if (sregs.u.e.features KVM_SREGS_E_ED) {
+sregs.u.e.dsrr0 = env-nip;
+sregs.u.e.dsrr1 = env-msr;
+} else {
+sregs.u.e.csrr0 = env-nip;
+sregs.u.e.csrr1 = env-msr;
+}
+
+sregs.u.e.update_special = KVM_SREGS_E_UPDATE_DBSR;
+sregs.u.e.dbsr = env-spr[SPR_BOOKE_DBSR];
+
+ret = kvm_vcpu_ioctl(cs, KVM_SET_SREGS, sregs);
+if (ret 0) {
+return -1;
+}
+
return 0;
}
+static int kvmppc_inject_debug_exception(CPUState *cs)
+{
+PowerPCCPU *cpu = POWERPC_CPU(cs);
+CPUPPCState *env = cpu-env;
+int ret = -1;
+
+switch (env-excp_model) {
+case POWERPC_EXCP_BOOKE:
+ret = kvmppc_e500_inject_debug_exception(cs);
+break;
+default:
+fprintf(stderr, %s: Invalid exception model %d\n,
+__func__, env-excp_model);
+break;
+}
+return ret;
+}
+
static void kvmppc_inject_exception(CPUState *cs)
{
PowerPCCPU *cpu = POWERPC_CPU(cs);
@@ -772,8 +820,9 @@ static void kvmppc_inject_exception(CPUState *cs)
if (env-pending_interrupts (1 PPC_INTERRUPT_DEBUG)) {
if (kvmppc_inject_debug_exception(cs)) {
fprintf(stderr, %s: Debug exception injection failed\n,
__func__);
+return;
}
-return;
+env-pending_interrupts = ~(1 PPC_INTERRUPT_DEBUG);
}
}
--
1.9.0
[Qemu-devel] [PATCH 5/5 v3][RESEND] ppc: Add hw breakpoint watchpoint support
This patch adds hardware breakpoint and hardware watchpoint support
for ppc. If the debug interrupt is not handled then this is injected
to guest.
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
v2-v3
- Shared as much code as much possible for futuristic book3s support
- Initializing number of hw breakpoint/watchpoints from KVM world
- Other minor cleanup/fixes
target-ppc/kvm.c | 248 +++
1 file changed, 233 insertions(+), 15 deletions(-)
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 8e2dbb3..4fb0efd 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
@@ -410,6 +411,44 @@ 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)
+{
+static bool initialize = true;
+
+if (initialize) {
+if (cenv-excp_model == POWERPC_EXCP_BOOKE) {
+max_hw_breakpoint = 2;
+max_hw_watchpoint = 2;
+}
+
+initialize = false;
+}
+
+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);
@@ -437,6 +476,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;
}
@@ -1343,24 +1383,216 @@ 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)
+{
+assert((nb_hw_breakpoint + nb_hw_watchpoint)
+ = ARRAY_SIZE(hw_debug_points));
+
+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 GDB_WATCHPOINT_READ:
+case GDB_WATCHPOINT_ACCESS:
+if (nb_hw_watchpoint = max_hw_watchpoint) {
+return -ENOBUFS;
+}
+
+if (find_hw_breakpoint(addr, type) = 0) {
+return -EEXIST;
+}
+
+nb_hw_watchpoint++;
+break;
+
+default:
+return -ENOSYS;
+}
+
+return 0;
+}
+
+int kvm_arch_remove_hw_breakpoint(target_ulong addr,
+ target_ulong len, int type)
+{
+int n;
+
+n = find_hw_breakpoint(addr, type);
+if (n 0) {
+return -ENOENT;
+}
+
+switch (type) {
+case GDB_BREAKPOINT_HW:
+nb_hw_breakpoint--;
+break;
+
+case GDB_WATCHPOINT_WRITE:
+case GDB_WATCHPOINT_READ:
+case GDB_WATCHPOINT_ACCESS:
+nb_hw_watchpoint--;
+break;
+
+default:
+return -ENOSYS;
+}
+hw_debug_points[n] = hw_debug_points[nb_hw_breakpoint + nb_hw_watchpoint];
+
+return 0;
+}
+
+void kvm_arch_remove_all_hw_breakpoints(void)
+{
+nb_hw_breakpoint = nb_hw_watchpoint = 0;
+}
+
void kvm_arch_update_guest_debug(CPUState *cs, struct kvm_guest_debug *dbg)
{
+int
[Qemu-devel] [PATCH 4/5 v3][RESEND] ppc: Add software breakpoint support
This patch allow insert/remove software breakpoint
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
target-ppc/kvm.c | 71 +---
1 file changed, 57 insertions(+), 14 deletions(-)
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 5238de7..8e2dbb3 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -1317,6 +1317,53 @@ 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, 4, 0) ||
+cpu_memory_rw_debug(cs, bp-pc, (uint8_t *)sc, 4, 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, 4, 0) ||
+sc != debug_inst_opcode ||
+cpu_memory_rw_debug(cs, bp-pc, (uint8_t *)bp-saved_insn, 4, 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);
@@ -1357,6 +1404,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;
@@ -2044,16 +2101,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;
@@ -2068,10 +2115,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.0
Re: [Qemu-devel] AArch64 linux-user: SA_ONSTACK usage in get_sigframe
On Mon, Jun 23, 2014 at 06:15:03PM +0200, Laurent Desnogues wrote:
Hello,
in linux-user/signal.c the code for AArch64 get_sigframe reads like this:
if ((ka-sa_flags SA_ONSTACK) !sas_ss_flags(sp)) {
Shouldn't that be TARGET_SA_ONSTACK?
The same question applies to Microblaze and OpenRISC.
Correct. Most people wont just notice since SA_ONSTACK appears to be
0x0800 for everything but alpha and parisc where it is 1.
Riku
Re: [Qemu-devel] [PATCH v3 05/32] target-arm: reject switching to monitor mode
Hm…yes, this case is missing, but it is only missing for ARMv7 as this bit is RES0 in ARMv8. Even in ARMv7 it is IMPDEF whether this bit is supported. And since ARMv7 mentions, that this bit is deprecated from the introduction of Virtualization Extensions I did not care to add this special case. On 12 Jun 2014, at 23:55, Greg Bellows greg.bell...@linaro.orgmailto:greg.bell...@linaro.org wrote: Missing case where it is UNPREDICTABLE to enter FIQ mode from non-secure state if NSACR.RFR is 1. On 10 June 2014 18:54, Fabian Aggeler aggel...@ethz.chmailto:aggel...@ethz.ch wrote: From: Sergey Fedorov s.fedo...@samsung.commailto:s.fedo...@samsung.com ...from non-secure state. Signed-off-by: Sergey Fedorov s.fedo...@samsung.commailto:s.fedo...@samsung.com Signed-off-by: Fabian Aggeler aggel...@ethz.chmailto:aggel...@ethz.ch --- target-arm/helper.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/target-arm/helper.c b/target-arm/helper.c index d8d6637..ace8d8b 100644 --- a/target-arm/helper.c +++ b/target-arm/helper.c @@ -3049,6 +3049,8 @@ static int bad_mode_switch(CPUARMState *env, int mode) case ARM_CPU_MODE_IRQ: case ARM_CPU_MODE_FIQ: return 0; +case ARM_CPU_MODE_MON: +return !arm_is_secure(env); default: return 1; } -- 1.8.3.2
Re: [Qemu-devel] [PATCH v4 0/9] virtio-blk: use alias properties in transport devices
Il 18/06/2014 11:58, Stefan Hajnoczi ha scritto:
v4:
* Coding style: typedef struct { on a single line [Andreas]
* Add dataplane: bail out on unsupported transport for s390-virtio [Cornelia]
v3:
* Split qdev_alias_all_properties() into its own patch [Peter Crosthwaite]
* Do not dereference DEVICE_CLASS(class) inline [Peter Crosthwaite]
v2:
* Add qdev_alias_all_properties() instead of virtio-blk-specific function
[Paolo]
* Explain refcount handling in doc comment [Paolo]
* Fix property duplicate typo [Peter Crosthwaite]
* Add the same object or to clarify commit description [Igor]
Thanks for the feedback on the RFC. This time around the alias property is
implemented at the QOM property level instead of at the qdev property level.
Note that this series only addresses virtio-blk. In later series we can
convert virtio net, scsi, rng, and serial.
The virtio transport/device split is broken as follows:
1. The virtio-blk device is never finalized because the transport devices
(virtio-blk-pci and friends) leak the refcount.
2. If we fix the refcount leak then we double-free the 'serial' string property
upon hot unplug since its char* is copied into the virtio-blk device which
has an identical 'serial' qdev property.
This series solves both of these problems as follows:
1. Introduce a QOM alias property that lets the transport device forward
property accesses into the virtio device (the child).
2. Use alias properties in transport devices, instead of keeping a duplicate
copy of the VirtIOBlkConf struct.
3. Fix the virtio-blk device refcount leak. It's now safe to do this since the
double-free has been resolved.
Tested that hotplug/hotunplug of virtio-blk-pci still works.
Cornelia Huck (1):
dataplane: bail out on unsupported transport
Stefan Hajnoczi (8):
qom: add object_property_add_alias()
virtio-blk: avoid qdev property definition duplication
virtio-blk: move x-data-plane qdev property to virtio-blk.h
qdev: add qdev_alias_all_properties()
virtio-blk: use aliases instead of duplicate qdev properties
virtio-blk: drop virtio_blk_set_conf()
virtio: fix virtio-blk child refcount in transports
virtio-blk: move qdev properties into virtio-blk.c
hw/block/dataplane/virtio-blk.c | 10
hw/block/virtio-blk.c | 18 +--
hw/core/qdev.c | 21 +
hw/s390x/s390-virtio-bus.c | 10 ++--
hw/s390x/s390-virtio-bus.h | 1 -
hw/s390x/virtio-ccw.c | 7 ++
hw/s390x/virtio-ccw.h | 1 -
hw/virtio/virtio-pci.c | 7 ++
hw/virtio/virtio-pci.h | 1 -
include/hw/qdev-properties.h| 2 ++
include/hw/virtio/virtio-blk.h | 19 ---
include/qom/object.h| 20
qom/object.c| 51 +
13 files changed, 121 insertions(+), 47 deletions(-)
Andreas, can you review this series?
Paolo
[Qemu-devel] [PATCH v3 2/4] mirror: Go through ready - complete process for 0 len image
When mirroring or active committing a zero length image, BLOCK_JOB_READY
is not reported now, instead the job completes because we short circuit
the mirror job loop.
This is inconsistent with non-zero length images, and only confuses
management software.
Let's do the same thing when seeing a 0-length image: report ready
immediately; wait for block-job-cancel or block-job-complete; clear the
cancel flag as existing non-zero image synced case (cancelled after
ready); then jump to the exit.
Reported-by: Eric Blake ebl...@redhat.com
Signed-off-by: Fam Zheng f...@redhat.com
Reviewed-by: Eric Blake ebl...@redhat.com
---
block/mirror.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/block/mirror.c b/block/mirror.c
index 94c8661..705260a 100644
--- a/block/mirror.c
+++ b/block/mirror.c
@@ -324,9 +324,18 @@ static void coroutine_fn mirror_run(void *opaque)
}
s-common.len = bdrv_getlength(bs);
-if (s-common.len = 0) {
+if (s-common.len 0) {
ret = s-common.len;
goto immediate_exit;
+} else if (s-common.len == 0) {
+/* Report BLOCK_JOB_READY and wait for complete. */
+block_job_ready(s-common);
+s-synced = true;
+while (!block_job_is_cancelled(s-common) !s-should_complete) {
+block_job_yield(s-common);
+}
+s-common.cancelled = false;
+goto immediate_exit;
}
length = DIV_ROUND_UP(s-common.len, s-granularity);
--
2.0.0
[Qemu-devel] [PATCH v3 0/4] mirror: Fix behavior for zero byte image
The current behavior of mirroring zero byte image is slightly different from non-zero image: the BLOCK_JOB_READY event is skipped and job is completed immediately. This is not a big problem for human user but only makes management software harder to write. Since we are focusing on an good API instead of UI, let's make the behavior more consistent and predictable. The first patch fixes the behavior. The following two patches add test case for the involved code path. Thanks for Eric Blake to report this! v3: Fix test case failure in 4/4. (Kevin) Add Eric's review-by's in 1~3. v2: Address Stefan's comments. - Added patch 01: block_job_yield. - Use block_job_yield in 02. - Fix test case updates. Thanks to Stefan, Paolo and Eric for reviewing! Fam Fam Zheng (4): blockjob: Add block_job_yield() mirror: Go through ready - complete process for 0 len image qemu-iotests: Test BLOCK_JOB_READY event for 0Kb image active commit qemu-iotests: Test 0-length image for mirror block/mirror.c | 11 ++- blockjob.c | 14 ++ include/block/blockjob.h | 8 tests/qemu-iotests/040 | 12 +--- tests/qemu-iotests/040.out | 4 ++-- tests/qemu-iotests/041 | 11 --- tests/qemu-iotests/041.out | 4 ++-- 7 files changed, 53 insertions(+), 11 deletions(-) -- 2.0.0
[Qemu-devel] [PATCH v3 1/4] blockjob: Add block_job_yield()
This will unset busy flag and put coroutine to sleep, can be used to
wait for QMP complete/cancel.
Signed-off-by: Fam Zheng f...@redhat.com
Reviewed-by: Eric Blake ebl...@redhat.com
---
blockjob.c | 14 ++
include/block/blockjob.h | 8
2 files changed, 22 insertions(+)
diff --git a/blockjob.c b/blockjob.c
index 7d84ca1..a85146a 100644
--- a/blockjob.c
+++ b/blockjob.c
@@ -210,6 +210,20 @@ void block_job_sleep_ns(BlockJob *job, QEMUClockType type,
int64_t ns)
job-busy = true;
}
+void block_job_yield(BlockJob *job)
+{
+assert(job-busy);
+
+/* Check cancellation *before* setting busy = false, too! */
+if (block_job_is_cancelled(job)) {
+return;
+}
+
+job-busy = false;
+qemu_coroutine_yield();
+job-busy = true;
+}
+
BlockJobInfo *block_job_query(BlockJob *job)
{
BlockJobInfo *info = g_new0(BlockJobInfo, 1);
diff --git a/include/block/blockjob.h b/include/block/blockjob.h
index c0a7875..ac313ea 100644
--- a/include/block/blockjob.h
+++ b/include/block/blockjob.h
@@ -147,6 +147,14 @@ void *block_job_create(const BlockJobDriver *driver,
BlockDriverState *bs,
void block_job_sleep_ns(BlockJob *job, QEMUClockType type, int64_t ns);
/**
+ * block_job_yield:
+ * @job: The job that calls the function.
+ *
+ * Yield the block job coroutine.
+ */
+void block_job_yield(BlockJob *job);
+
+/**
* block_job_completed:
* @job: The job being completed.
* @ret: The status code.
--
2.0.0
[Qemu-devel] [PATCH v3 3/4] qemu-iotests: Test BLOCK_JOB_READY event for 0Kb image active commit
There should be a BLOCK_JOB_READY event with active commit, regardless
of image length. Let's test the 0 length image case, and make sure it
goes through the ready-complete process.
Signed-off-by: Fam Zheng f...@redhat.com
Reviewed-by: Eric Blake ebl...@redhat.com
---
tests/qemu-iotests/040 | 12 +---
tests/qemu-iotests/040.out | 4 ++--
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/tests/qemu-iotests/040 b/tests/qemu-iotests/040
index 734b6a6..d166810 100755
--- a/tests/qemu-iotests/040
+++ b/tests/qemu-iotests/040
@@ -35,12 +35,13 @@ test_img = os.path.join(iotests.test_dir, 'test.img')
class ImageCommitTestCase(iotests.QMPTestCase):
'''Abstract base class for image commit test cases'''
-def run_commit_test(self, top, base):
+def run_commit_test(self, top, base, need_ready=False):
self.assert_no_active_block_jobs()
result = self.vm.qmp('block-commit', device='drive0', top=top,
base=base)
self.assert_qmp(result, 'return', {})
completed = False
+ready = False
while not completed:
for event in self.vm.get_qmp_events(wait=True):
if event['event'] == 'BLOCK_JOB_COMPLETED':
@@ -48,8 +49,11 @@ class ImageCommitTestCase(iotests.QMPTestCase):
self.assert_qmp(event, 'data/device', 'drive0')
self.assert_qmp(event, 'data/offset', self.image_len)
self.assert_qmp(event, 'data/len', self.image_len)
+if need_ready:
+self.assertTrue(ready, Expecting BLOCK_JOB_COMPLETED
event)
completed = True
elif event['event'] == 'BLOCK_JOB_READY':
+ready = True
self.assert_qmp(event, 'data/type', 'commit')
self.assert_qmp(event, 'data/device', 'drive0')
self.assert_qmp(event, 'data/len', self.image_len)
@@ -63,7 +67,7 @@ class TestSingleDrive(ImageCommitTestCase):
test_len = 1 * 1024 * 256
def setUp(self):
-iotests.create_image(backing_img, TestSingleDrive.image_len)
+iotests.create_image(backing_img, self.image_len)
qemu_img('create', '-f', iotests.imgfmt, '-o', 'backing_file=%s' %
backing_img, mid_img)
qemu_img('create', '-f', iotests.imgfmt, '-o', 'backing_file=%s' %
mid_img, test_img)
qemu_io('-c', 'write -P 0xab 0 524288', backing_img)
@@ -105,7 +109,7 @@ class TestSingleDrive(ImageCommitTestCase):
self.assert_qmp(result, 'error/desc', 'Base \'badfile\' not found')
def test_top_is_active(self):
-self.run_commit_test(test_img, backing_img)
+self.run_commit_test(test_img, backing_img, need_ready=True)
self.assertEqual(-1, qemu_io('-c', 'read -P 0xab 0 524288',
backing_img).find(verification failed))
self.assertEqual(-1, qemu_io('-c', 'read -P 0xef 524288 524288',
backing_img).find(verification failed))
@@ -238,6 +242,8 @@ class TestSetSpeed(ImageCommitTestCase):
self.cancel_and_wait(resume=True)
+class TestActiveZeroLengthImage(TestSingleDrive):
+image_len = 0
if __name__ == '__main__':
iotests.main(supported_fmts=['qcow2', 'qed'])
diff --git a/tests/qemu-iotests/040.out b/tests/qemu-iotests/040.out
index b6f2576..42314e9 100644
--- a/tests/qemu-iotests/040.out
+++ b/tests/qemu-iotests/040.out
@@ -1,5 +1,5 @@
-
+
--
-Ran 16 tests
+Ran 24 tests
OK
--
2.0.0
[Qemu-devel] [PATCH v3 4/4] qemu-iotests: Test 0-length image for mirror
All behavior and invariant should hold for images with 0 length, so
add a class to repeat all the tests in TestSingleDrive.
Hide two unapplicable test methods that would fail with 0 image length
because it's also used as cluster size.
Signed-off-by: Fam Zheng f...@redhat.com
---
tests/qemu-iotests/041 | 11 ---
tests/qemu-iotests/041.out | 4 ++--
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/tests/qemu-iotests/041 b/tests/qemu-iotests/041
index ec470b2..ef4f465 100755
--- a/tests/qemu-iotests/041
+++ b/tests/qemu-iotests/041
@@ -64,7 +64,7 @@ class TestSingleDrive(ImageMirroringTestCase):
image_len = 1 * 1024 * 1024 # MB
def setUp(self):
-iotests.create_image(backing_img, TestSingleDrive.image_len)
+iotests.create_image(backing_img, self.image_len)
qemu_img('create', '-f', iotests.imgfmt, '-o', 'backing_file=%s' %
backing_img, test_img)
self.vm = iotests.VM().add_drive(test_img)
self.vm.launch()
@@ -163,7 +163,7 @@ class TestSingleDrive(ImageMirroringTestCase):
self.assert_no_active_block_jobs()
qemu_img('create', '-f', iotests.imgfmt, '-o',
'cluster_size=%d,size=%d'
-% (TestSingleDrive.image_len,
TestSingleDrive.image_len), target_img)
+% (self.image_len, self.image_len), target_img)
result = self.vm.qmp('drive-mirror', device='drive0', sync='full',
buf_size=65536, mode='existing',
target=target_img)
self.assert_qmp(result, 'return', {})
@@ -179,7 +179,7 @@ class TestSingleDrive(ImageMirroringTestCase):
self.assert_no_active_block_jobs()
qemu_img('create', '-f', iotests.imgfmt, '-o',
'cluster_size=%d,backing_file=%s'
-% (TestSingleDrive.image_len, backing_img), target_img)
+% (self.image_len, backing_img), target_img)
result = self.vm.qmp('drive-mirror', device='drive0', sync='full',
mode='existing', target=target_img)
self.assert_qmp(result, 'return', {})
@@ -206,6 +206,11 @@ class TestSingleDrive(ImageMirroringTestCase):
target=target_img)
self.assert_qmp(result, 'error/class', 'DeviceNotFound')
+class TestSingleDriveZeroLength(TestSingleDrive):
+image_len = 0
+test_small_buffer2 = None
+test_large_cluster = None
+
class TestMirrorNoBacking(ImageMirroringTestCase):
image_len = 2 * 1024 * 1024 # MB
diff --git a/tests/qemu-iotests/041.out b/tests/qemu-iotests/041.out
index 6d9bee1..cfa5c0d 100644
--- a/tests/qemu-iotests/041.out
+++ b/tests/qemu-iotests/041.out
@@ -1,5 +1,5 @@
-...
+...
--
-Ran 27 tests
+Ran 35 tests
OK
--
2.0.0
Re: [Qemu-devel] machines and versions - why so many?
On Mon, 2014-06-23 at 23:41 +0200, Andreas Färber wrote: Am 23.06.2014 23:35, schrieb Alexey Kardashevskiy: Looks like I must copy PC_COMPAT_X_X as PSERIES_COMPAT_X_X starting 1.6 (or 1.7 - whichever starts supporting migration well enough on pseries) because pretty much of what they do is tweaking PCI devices and we can have all of these devices on pseries. And then keep an eye on what is happening in PC world to copy same tweaks to pseries as they come. Is that correct? Please don't. There's a series by Marcel on the list converting those PC macros to QOM. Actually, I think you are referring to is Eduardo's series :) http://lists.gnu.org/archive/html/qemu-devel/2014-06/msg03155.html Thanks, Marcel You already have a QOM sPAPR machine, so you should just derive new legacy types as needed and override things there. Also, -machine *is* the global mechanism we have to tell QEMU which version you want, it's a shorthand for setting a list of global properties. Don't forget that QEMU can be used without libvirt, so the knowledge of which properties to set for which version is kept in QEMU. Cheers, Andreas
Re: [Qemu-devel] [PATCH v2 0/4] mirror: Fix behavior for zero byte image
Am 24.06.2014 um 06:25 hat Fam Zheng geschrieben:
On Mon, 06/09 10:56, Fam Zheng wrote:
The current behavior of mirroring zero byte image is slightly different
from
non-zero image: the BLOCK_JOB_READY event is skipped and job is completed
immediately. This is not a big problem for human user but only makes
management
software harder to write. Since we are focusing on an good API instead of
UI,
let's make the behavior more consistent and predictable.
The first patch fixes the behavior. The following two patches add test
case for
the involved code path.
Thanks for Eric Blake to report this!
Ping. Shall we merge this before it rots?
I had it already applied, but now test case 041 fails for me, so I'm
going to remove it from my tree again:
I'm pretty sure it passed when I sent it, so it's probably due do some recent
code changes. Rebased and sent v3. Please try again!
Thanks for the effort!
Fam
041 7s ...[13:28:48] [13:29:27] [failed, exit status 1] - output
mismatch (see 041.out.bad)
--- 041.out 2014-06-24 13:23:13.597949977 +0200
+++ 041.out.bad 2014-06-24 13:29:27.024871226 +0200
@@ -1,5 +1,31 @@
-.
+qemu-img: /home/kwolf/source/qemu/tests/qemu-iotests/scratch/target.img:
Cluster size must be a power of two between 512 and 2048k
+qemu-img: /home/kwolf/source/qemu/tests/qemu-iotests/scratch/target.img:
Cluster size must be a power of two between 512 and 2048k
+..F...F..
+==
+FAIL: test_large_cluster (__main__.TestSingleDriveZeroLength)
+--
+Traceback (most recent call last):
+ File ./041, line 185, in test_large_cluster
+self.assert_qmp(result, 'return', {})
+ File /home/kwolf/source/qemu/tests/qemu-iotests/iotests.py, line 232, in
assert_qmp
+result = self.dictpath(d, path)
+ File /home/kwolf/source/qemu/tests/qemu-iotests/iotests.py, line 211, in
dictpath
+self.fail('failed path traversal for %s in %s' % (path, str(d)))
+AssertionError: failed path traversal for return in {u'error': {u'class':
u'GenericError', u'desc': uCould not open
'/home/kwolf/source/qemu/tests/qemu-iotests/scratch/target.img': No such
file or directory}}
+
+==
+FAIL: test_small_buffer2 (__main__.TestSingleDriveZeroLength)
+--
+Traceback (most recent call last):
+ File ./041, line 169, in test_small_buffer2
+self.assert_qmp(result, 'return', {})
+ File /home/kwolf/source/qemu/tests/qemu-iotests/iotests.py, line 232, in
assert_qmp
+result = self.dictpath(d, path)
+ File /home/kwolf/source/qemu/tests/qemu-iotests/iotests.py, line 211, in
dictpath
+self.fail('failed path traversal for %s in %s' % (path, str(d)))
+AssertionError: failed path traversal for return in {u'error': {u'class':
u'GenericError', u'desc': uCould not open
'/home/kwolf/source/qemu/tests/qemu-iotests/scratch/target.img': No such
file or directory}}
+
--
Ran 37 tests
-OK
+FAILED (failures=2)
Failures: 041
[Qemu-devel] [PATCH 2/5 v3][RESEND] ppc: Add interface to inject interrupt to guest
This patch adds interface to inject interrupt to guest.
Currently a void debug exception function added.
Follow up patch will use this interface to inject debug
interrupt to guest
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
target-ppc/kvm.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 1f78cd1..70f77d1 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -759,6 +759,24 @@ static int kvm_put_vpa(CPUState *cs)
}
#endif /* TARGET_PPC64 */
+static int kvmppc_inject_debug_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_DEBUG)) {
+if (kvmppc_inject_debug_exception(cs)) {
+fprintf(stderr, %s: Debug exception injection failed\n,
__func__);
+}
+return;
+}
+}
+
int kvm_arch_put_registers(CPUState *cs, int level)
{
PowerPCCPU *cpu = POWERPC_CPU(cs);
@@ -772,6 +790,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.0
[Qemu-devel] Regarding guest-file-write
Hi,
From host, I wrote 26 alphabets in guest file (/tmp/testqga) using
guest-file-write guest agent command (logs pasted below). I faced 2 issues
when doing that.
1a. It could wrote only 18bytes! Why could it not write all 26 characters?
Are we supposed to track how much data is written and need to resend the
remaining one?
1b. What is the limit of data, I can send in one guest-file-write command?
2. In the guest, file data seems to be different. Am I doing something
wrong here?
Host (file write)
[root@sdsr720-14 ~]# virsh qemu-agent-command vm_04 '{
execute:guest-file-open, arguments:{path:/tmp/testqga,mode:w
+}}'
{return:1000}
[root@sdsr720-14 ~]# virsh qemu-agent-command vm_04 '{
execute:guest-file-write,
arguments:{handle:1000,buf-b64:abcdefghijklmnopqrstuvwxyz}}'
{return:{count:18,eof:false}}
[root@sdsr720-14 ~]# virsh qemu-agent-command vm_04 '{
execute:guest-file-close, arguments:{handle:1000}}'
{return:{}}
Host (file read)
[root@sdsr720-14 ~]# virsh qemu-agent-command vm_04 '{
execute:guest-file-open, arguments:{path:/tmp/testqga,mode:r}}'
{return:1001}
[root@sdsr720-14 ~]# virsh qemu-agent-command vm_04 '{
execute:guest-file-read, arguments:{handle:1001,count:18}}'
{return:{count:18,buf-b64:abcdefghijklmnopqrstuvwx,eof:false}}
[root@sdsr720-14 ~]# virsh qemu-agent-command vm_04 '{
execute:guest-file-close, arguments:{handle:1001}}'
{return:{}}
Guest
[root@vm04 qga]# ll /tmp/testqga
-rw-rw-rw-. 1 root root 18 Jun 24 15:06 /tmp/testqga
[root@vm04 qga]# cat /tmp/testqga
i�^]y�!�9%�z)��-��1[root@vm04 qga]#
[root@vm04 qga]# od -x /tmp/testqga
000 b769 791d 21f8 398a 9a25 297a bbaa ba2d
020 31fc
022
[root@vm04 qga]# strings /tmp/testqga
[root@vm04 qga]# hexdump /tmp/testqga
000 b769 791d 21f8 398a 9a25 297a bbaa ba2d
010 31fc
012
[root@vm04 qga]# hexdump -c /tmp/testqga
000 i 267 035 y 370 ! 212 9 % 232 z ) 252 273 - 272
010 374 1
012
[root@vm04 qga]#
Regards,
~Puneet
Re: [Qemu-devel] [PATCH v6 for 2.1 00/10] Modify block jobs to use node-names
Am 19.06.2014 um 18:49 hat Eric Blake geschrieben: On 06/19/2014 10:26 AM, Jeff Cody wrote: b. Is it a good idea to perform op blocker checks on the root node? It's inconsistent with resize, snapshot-sync, etc. Permissions in BDS graphs with multiple root nodes (e.g. guest device and NBD run-time server) will be different depending on which root you specify. I don't think (b) is the ultimate solution. It is used as a stop-gap because op blockers in the current implementation is essentially analogous to the in-use flag. But is it good enough for 2.1? If *everything* checks the topmost node in 2.1, then I think we are OK in all cases except where images files share a common BDS. What's the problem again with just propagating all blockers down the chain using bs-backing_hd and then checking just the affected nodes rather than trying to figure out a root? It would probably be more restrictive than necessary, but it looked like a safe first step. The ability for internal BDSs to share a common base BDS makes some block jobs unsafe currently, I believe. A crude and ugly fix is to only allow a single block-job to occur at any given time, but that doesn't seem feasible, so let's ignore that. Can we even create a common base BDS in qemu 2.1? I know that the blockdev-add command was designed with this possibility in mind, but to my knowledge, we have not actually wired it up yet. You can create such chains, I just tried it: x86_64-softmmu/qemu-system-x86_64 \ -drive if=none,id=backing,file=/tmp/backing.qcow2 \ -drive file=/tmp/empty.qcow2,backing.file=backing \ -drive file=/tmp/empty2.qcow2,backing.file=backing Gives me the same disk twice, and I can independently change them as you would expect. The answer seems to be that op blockers should be propagated to all child nodes and commands should test the node, not the drive/root node. That gives us the flexibility for per-node op blockers in the future and maintains compatibility with existing node-name users. Long term thoughts: So if I think of operations that are done on block devices from a block job, and chuck them into categories, I think we have: 1) Read of guest-visible data 2) Write of guest-visible data 3) Read of host-visible data (e.g. image file metadata) 4) Write of host-visible data (e.g. image file metadata, such as the backing-file) 5) Block chain manipulations (e.g. movement of a BDS, change to r/w instead of r/o, etc..) 6) I/O attribute changes (e.g. throttling, etc..) Does this make sense, and did I miss any (likely so)? It seems like we should issue blockers not based on specific commands (e.g. BLOCK_OP_TYPE_COMMIT), but rather based on what specific category of interaction on a BDS we want to prohibit / allow. Yes, I like that train of thought - it's not the operation that we are blocking, but the access category(ies) required by that operation. Yes, I argued something similar in our block meeting in Stuttgart, and I still think it's a good idea in principle. The problem with it is that the right categories aren't quite obvious. For example, I think guest/host writes really means writes that change the visible contents of this image. A shared backing file would require that its contents never changes, but that's not really related to the guest. A commit operation does a guest write on the base node because its contents changes when you look only at the specific node. Kevin pgp3v3dyMypib.pgp Description: PGP signature
Re: [Qemu-devel] machines and versions - why so many?
On 06/24/2014 09:22 PM, Andreas Färber wrote: Am 24.06.2014 10:17, schrieb Markus Armbruster: Back then gerd created a way to do the compatibility stuff without getting into the other target's hair: compat_props. They've served us well enough, but now that more targets get interested in migration, their shortcomings start to hurt. Having to duplicate device compatibility gunk in multiple places, all far away from the device, is decidedly suboptimal. Better ideas welcome. Might it make sense to reconsider the proposed machine type hierarchy and have machine-2.2 - pc-i440fx-2.2, with global properties in machine-x.y types and pc_compat_x_y() taking care of PC inheritence? We can't inherit from both pc-x.y and machine-x.y though, so probably not, just throwing thoughts around. I wanted to suggest this but I do not want even think about multiple inheritance in QOM :) And in fact all I would possibly want for pseries from those versioned PCs is those PC_COMPAT_X_Y things with enforced device properties. -- Alexey
Re: [Qemu-devel] [libvirt] Regarding guest-file-write
On Tue, Jun 24, 2014 at 06:20:16PM +0530, Puneet Bakshi wrote:
Hi,
From host, I wrote 26 alphabets in guest file (/tmp/testqga) using
guest-file-write guest agent command (logs pasted below). I faced 2 issues
when doing that.
1a. It could wrote only 18bytes! Why could it not write all 26 characters?
Are we supposed to track how much data is written and need to resend the
remaining one?
1b. What is the limit of data, I can send in one guest-file-write command?
2. In the guest, file data seems to be different. Am I doing something
wrong here?
Yes, the command does not take raw data, it takes base-64 encoded data.
So those 26 characters you specified were base64 decoded which gives
you 18 bytes of raw data.
The clue is in the variable name 'buf-b64' - a shorthand for base64:
[root@sdsr720-14 ~]# virsh qemu-agent-command vm_04 '{
execute:guest-file-write,
arguments:{handle:1000,buf-b64:abcdefghijklmnopqrstuvwxyz}}'
{return:{count:18,eof:false}}
Regards,
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Re: [Qemu-devel] [PATCH 4/5 v3][RESEND] ppc: Add software breakpoint support
On 24.06.14 14:10, Bharat Bhushan wrote:
This patch allow insert/remove software breakpoint
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
target-ppc/kvm.c | 71 +---
1 file changed, 57 insertions(+), 14 deletions(-)
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 5238de7..8e2dbb3 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -1317,6 +1317,53 @@ 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;
What if debug_inst_opcode has never been set (thus is 0)? In that case
we should fail the insert, no?
Alex
Re: [Qemu-devel] machines and versions - why so many?
On 06/24/2014 09:15 PM, Andreas Färber wrote: Am 24.06.2014 07:21, schrieb Paolo Bonzini: Il 24/06/2014 00:33, Alexey Kardashevskiy ha scritto: I actually wonder if it is not going to be -machine pseries-2.0 then what will it look like? -machine pseries,qemucompat=2.0? I would keep using pseries-2.0. There might be some class hierarchy, like spapr-machine spapr-machine-2.2 spapr-machine-2.1 I don't know what Andreas had in mind though, but you can check out Eduardo's patches for QOMifying the PC machines and take inspiration from there. That's probably a safe bet. That's pretty much what I meant, yes. (Eduardo, not Marcel then. :)) Aha. Eduardo, oky :) I looked there, I fail to see why I should not cut-n-paste PC_COMPAT_XXX stuff to pseries and how that patchset helps me at all so any clues are very appreciated :) Not sure about spapr-machine vs. spapr-machine-2.2, but pseries-2.1-machine inheriting from and overriding properties of pseries[-2.2]-machine definitely. Whatever works. -- Alexey
Re: [Qemu-devel] [PULL for-2.1 00/40] QMP queue
于 2014/6/21 4:02, Eric Blake 写道: On 06/20/2014 01:49 PM, Paolo Bonzini wrote: As I explained on IRC, many patches when rebased would have conflicts with Igor's new event. I think this is much more complex than having an extraordinary merge commit. I include the conflict resolution: - hw/acpi/memory-hotplug.c is only present in mst's branch, so I'm including the diff from there (changing to the QAPI event style) - qapi-event.json is only present in luiz's branch, so I'm including the diff from there (adding the ACPI_DEVICE_OST event) One other alternative would have been to pull out the new ACPI_DEVICE_OST patches out of mst's branch, and upgrade them to Igor's v3 which applies on top of Wenchao's work: https://lists.gnu.org/archive/html/qemu-devel/2014-06/msg04927.html So which way to go now? - Paolo a76d72f692ed5f4f30f116cc9c3ac5fefe221cb7 Merge: 0a99aae b98ff90 Author: Paolo Bonzini pbonz...@redhat.com Date: Fri Jun 20 21:18:08 2014 +0200 Merge commit b98ff90e9459e0113da8502c03670a9539f90aa1 of git://repo.or.cz/qemu/qmp-unstable into HEAD Conflicts: docs/qmp/qmp-events.txt [removed with QAPI event conversion] hw/core/qdev.c [trivial header file conflict] include/monitor/monitor.h [QMP event enum removed by QAPI conversion] monitor.c [QMP event enum removed by QAPI conversion] qapi-schema.json [trivial, code added by both sides in the same place] qemu-char.c [trivial, code added by both sides in the same place] vl.c [trivial header file conflict] Other files changed: qapi-event.json [include ACPI_DEVICE_OST event] hw/acpi/memory-hotplug.c [use QAPI event] Signed-off-by: Paolo Bonzini pbonz...@redhat.com If you are okay taking this complex merge patch, you can add: Reviewed-by: Eric Blake ebl...@redhat.com
[Qemu-devel] [PULL 00/22] Migration queue
Hi Peter, please pull: - RDMA bugfixes (Michael) - Static checker from Amit (v5) - acked patches from vmstate (thanks Dave) Later, Juan. The following changes since commit d9c1647d896d3192cba9dbf98fb7efab876edde5: Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' into staging (2014-06-23 12:55:22 +0100) are available in the git repository at: git://github.com/juanquintela/qemu.git tags/migration/20140623 for you to fetch changes up to 4ea7df4e5c6b9d8b8a474680d6b1687fc8eacbac: vmstate: Refactor increase tests for primitive types (2014-06-23 19:14:52 +0200) migration/next for 20140623 Amit Shah (18): migration: dump vmstate info as a json file for static analysis vmstate-static-checker: script to validate vmstate changes tests: vmstate static checker: add dump1 and dump2 files tests: vmstate static checker: incompat machine types tests: vmstate static checker: add version error in main section tests: vmstate static checker: version mismatch inside a Description tests: vmstate static checker: minimum_version_id check tests: vmstate static checker: remove a section tests: vmstate static checker: remove a field tests: vmstate static checker: remove last field in a struct tests: vmstate static checker: change description name tests: vmstate static checker: remove Fields tests: vmstate static checker: remove Description tests: vmstate static checker: remove Description inside Fields tests: vmstate static checker: remove a subsection tests: vmstate static checker: remove Subsections tests: vmstate static checker: add substructure for usb-kbd for hid section tests: vmstate static checker: add size mismatch inside substructure Juan Quintela (3): migration: Remove unneeded minimum_version_id_old vmstate: Return error in case of error vmstate: Refactor increase tests for primitive types Michael R. Hines (1): rdma: bug fixes hw/usb/hcd-ohci.c|7 +- include/migration/vmstate.h |2 + migration-rdma.c | 20 +- qemu-options.hx | 14 + savevm.c | 139 +++ scripts/vmstate-static-checker.py| 345 tests/test-vmstate.c | 273 -- tests/vmstate-static-checker-data/dump1.json | 1163 ++ tests/vmstate-static-checker-data/dump2.json | 968 + vl.c | 13 + vmstate.c|4 + 11 files changed, 2872 insertions(+), 76 deletions(-) create mode 100755 scripts/vmstate-static-checker.py create mode 100644 tests/vmstate-static-checker-data/dump1.json create mode 100644 tests/vmstate-static-checker-data/dump2.json
[Qemu-devel] [PULL 01/22] rdma: bug fixes
From: Michael R. Hines mrhi...@us.ibm.com
1. Fix small memory leak in parsing inet address from command line in
data_init()
2. Fix ibv_post_send() return value check and pass error code back up correctly.
3. Fix rdma_destroy_qp() segfault after failure to connect to destination.
Reported-by: frank.yang...@gmail.com
Reported-by: dgilb...@redhat.com
Signed-off-by: Michael R. Hines mrhi...@us.ibm.com
Signed-off-by: Juan Quintela quint...@redhat.com
---
migration-rdma.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/migration-rdma.c b/migration-rdma.c
index f60749b..d99812c 100644
--- a/migration-rdma.c
+++ b/migration-rdma.c
@@ -1590,13 +1590,11 @@ static int qemu_rdma_post_send_control(RDMAContext
*rdma, uint8_t *buf,
}
-if (ibv_post_send(rdma-qp, send_wr, bad_wr)) {
-return -1;
-}
+ret = ibv_post_send(rdma-qp, send_wr, bad_wr);
-if (ret 0) {
+if (ret 0) {
fprintf(stderr, Failed to use post IB SEND for control!\n);
-return ret;
+return -ret;
}
ret = qemu_rdma_block_for_wrid(rdma, RDMA_WRID_SEND_CONTROL, NULL);
@@ -2238,10 +2236,6 @@ static void qemu_rdma_cleanup(RDMAContext *rdma)
}
}
-if (rdma-qp) {
-rdma_destroy_qp(rdma-cm_id);
-rdma-qp = NULL;
-}
if (rdma-cq) {
ibv_destroy_cq(rdma-cq);
rdma-cq = NULL;
@@ -2259,6 +2253,10 @@ static void qemu_rdma_cleanup(RDMAContext *rdma)
rdma-listen_id = NULL;
}
if (rdma-cm_id) {
+if (rdma-qp) {
+rdma_destroy_qp(rdma-cm_id);
+rdma-qp = NULL;
+}
rdma_destroy_id(rdma-cm_id);
rdma-cm_id = NULL;
}
@@ -2513,8 +2511,10 @@ static void *qemu_rdma_data_init(const char *host_port,
Error **errp)
} else {
ERROR(errp, bad RDMA migration address '%s', host_port);
g_free(rdma);
-return NULL;
+rdma = NULL;
}
+
+qapi_free_InetSocketAddress(addr);
}
return rdma;
--
1.9.3
[Qemu-devel] [PULL 09/22] tests: vmstate static checker: remove a section
From: Amit Shah amit.s...@redhat.com
Signed-off-by: Amit Shah amit.s...@redhat.com
Reviewed-by: Juan Quintela quint...@redhat.com
Signed-off-by: Juan Quintela quint...@redhat.com
---
tests/vmstate-static-checker-data/dump2.json | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/vmstate-static-checker-data/dump2.json
b/tests/vmstate-static-checker-data/dump2.json
index 36a9b4b..4ccfd67 100644
--- a/tests/vmstate-static-checker-data/dump2.json
+++ b/tests/vmstate-static-checker-data/dump2.json
@@ -2,7 +2,7 @@
vmschkmachine: {
Name: pc-i440fx-2.2
},
- fw_cfg: {
+ fw_cfg2: {
Name: fw_cfg,
version_id: 2,
minimum_version_id: 1,
--
1.9.3
Re: [Qemu-devel] [PATCH 4/5 v3][RESEND] ppc: Add software breakpoint support
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Tuesday, June 24, 2014 6:35 PM
To: Bhushan Bharat-R65777
Cc: qemu-...@nongnu.org; qemu-devel@nongnu.org; ma...@linux.vnet.ibm.com
Subject: Re: [PATCH 4/5 v3][RESEND] ppc: Add software breakpoint support
On 24.06.14 14:10, Bharat Bhushan wrote:
This patch allow insert/remove software breakpoint
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
target-ppc/kvm.c | 71
+-
--
1 file changed, 57 insertions(+), 14 deletions(-)
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c index
5238de7..8e2dbb3 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -1317,6 +1317,53 @@ 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;
What if debug_inst_opcode has never been set (thus is 0)?
Can 0 be a debug_inst_code ?
In that case we should fail the insert, no?
Yes, will checking for 0 is sufficient or we need a cap_ also ?
Thanks
-Bharat
Alex
[Qemu-devel] [PULL 15/22] tests: vmstate static checker: remove Description inside Fields
From: Amit Shah amit.s...@redhat.com
Signed-off-by: Amit Shah amit.s...@redhat.com
Reviewed-by: Juan Quintela quint...@redhat.com
Signed-off-by: Juan Quintela quint...@redhat.com
---
tests/vmstate-static-checker-data/dump2.json | 27 +--
1 file changed, 1 insertion(+), 26 deletions(-)
diff --git a/tests/vmstate-static-checker-data/dump2.json
b/tests/vmstate-static-checker-data/dump2.json
index 66ac3bd..05b8fce 100644
--- a/tests/vmstate-static-checker-data/dump2.json
+++ b/tests/vmstate-static-checker-data/dump2.json
@@ -212,32 +212,7 @@
field: pci,
version_id: 0,
field_exists: false,
- size: 1944,
- Description: {
-name: PCIDevice,
-version_id: 2,
-minimum_version_id: 1,
-Fields: [
- {
-field: version_id,
-version_id: 0,
-field_exists: false,
-size: 4
- },
- {
-field: config,
-version_id: 0,
-field_exists: false,
-size: 256
- },
- {
-field: irq_state,
-version_id: 2,
-field_exists: false,
-size: 16
- }
-]
- }
+ size: 1944
},
{
field: g_ctl,
--
1.9.3
[Qemu-devel] [PULL 10/22] tests: vmstate static checker: remove a field
From: Amit Shah amit.s...@redhat.com
Signed-off-by: Amit Shah amit.s...@redhat.com
Reviewed-by: Juan Quintela quint...@redhat.com
Signed-off-by: Juan Quintela quint...@redhat.com
---
tests/vmstate-static-checker-data/dump2.json | 6 --
1 file changed, 6 deletions(-)
diff --git a/tests/vmstate-static-checker-data/dump2.json
b/tests/vmstate-static-checker-data/dump2.json
index 4ccfd67..f6b52d0 100644
--- a/tests/vmstate-static-checker-data/dump2.json
+++ b/tests/vmstate-static-checker-data/dump2.json
@@ -58,12 +58,6 @@
size: 4
},
{
-field: usbsts,
-version_id: 0,
-field_exists: false,
-size: 4
- },
- {
field: usbsts_pending,
version_id: 2,
field_exists: false,
--
1.9.3
[Qemu-devel] [PULL 14/22] tests: vmstate static checker: remove Description
From: Amit Shah amit.s...@redhat.com
Signed-off-by: Amit Shah amit.s...@redhat.com
Reviewed-by: Juan Quintela quint...@redhat.com
Signed-off-by: Juan Quintela quint...@redhat.com
---
tests/vmstate-static-checker-data/dump2.json | 33 +---
1 file changed, 1 insertion(+), 32 deletions(-)
diff --git a/tests/vmstate-static-checker-data/dump2.json
b/tests/vmstate-static-checker-data/dump2.json
index cc0aae3..66ac3bd 100644
--- a/tests/vmstate-static-checker-data/dump2.json
+++ b/tests/vmstate-static-checker-data/dump2.json
@@ -462,38 +462,7 @@
cfi.pflash01: {
Name: cfi.pflash01,
version_id: 1,
-minimum_version_id: 1,
-Description: {
- name: pflash_cfi01,
- version_id: 1,
- minimum_version_id: 1,
- Fields: [
-{
- field: wcycle,
- version_id: 0,
- field_exists: false,
- size: 1
-},
-{
- field: cmd,
- version_id: 0,
- field_exists: false,
- size: 1
-},
-{
- field: status,
- version_id: 0,
- field_exists: false,
- size: 1
-},
-{
- field: counter,
- version_id: 0,
- field_exists: false,
- size: 8
-}
- ]
-}
+minimum_version_id: 1
},
megasas: {
Name: megasas,
--
1.9.3
[Qemu-devel] [PULL 19/22] tests: vmstate static checker: add size mismatch inside substructure
From: Amit Shah amit.s...@redhat.com
Signed-off-by: Amit Shah amit.s...@redhat.com
Reviewed-by: Juan Quintela quint...@redhat.com
Signed-off-by: Juan Quintela quint...@redhat.com
---
tests/vmstate-static-checker-data/dump2.json | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/vmstate-static-checker-data/dump2.json
b/tests/vmstate-static-checker-data/dump2.json
index 45cccaf..75719f5 100644
--- a/tests/vmstate-static-checker-data/dump2.json
+++ b/tests/vmstate-static-checker-data/dump2.json
@@ -909,7 +909,7 @@
field: kbd.keycodes,
version_id: 0,
field_exists: false,
-size: 4
+size: 2
},
{
field: head,
--
1.9.3
Re: [Qemu-devel] [PATCH v5 00/18] migration: add static analysis tool to check vmstate compat
Amit Shah amit.s...@redhat.com wrote: Hello, v5: - Add section / description name checking for matching names for changed fields. This has the benefit of also getting rid of the for loop in the lookup. However, for each section, like piix4_pm, all the changes have to be in one group, as against them being in different ones. That's still better than earlier where sections were not checked. If my Python gets better, I might come up with a way to improve on this as well. (Juan Quintela) - Add more comments to the Python script - Update help text to be more verbose - for qemu and for the script. - Simplify the check_fields() function - lesser indentations Applied. Later, Juan.
[Qemu-devel] [PULL 16/22] tests: vmstate static checker: remove a subsection
From: Amit Shah amit.s...@redhat.com
Signed-off-by: Amit Shah amit.s...@redhat.com
Reviewed-by: Juan Quintela quint...@redhat.com
Signed-off-by: Juan Quintela quint...@redhat.com
---
tests/vmstate-static-checker-data/dump2.json | 13 -
1 file changed, 13 deletions(-)
diff --git a/tests/vmstate-static-checker-data/dump2.json
b/tests/vmstate-static-checker-data/dump2.json
index 05b8fce..6f8a617 100644
--- a/tests/vmstate-static-checker-data/dump2.json
+++ b/tests/vmstate-static-checker-data/dump2.json
@@ -836,19 +836,6 @@
size: 1
}
]
-},
-{
- name: fdrive/media_rate,
- version_id: 1,
- minimum_version_id: 1,
- Fields: [
-{
- field: media_rate,
- version_id: 0,
- field_exists: false,
- size: 1
-}
- ]
}
]
}
--
1.9.3
[Qemu-devel] [PULL 11/22] tests: vmstate static checker: remove last field in a struct
From: Amit Shah amit.s...@redhat.com
Signed-off-by: Amit Shah amit.s...@redhat.com
Reviewed-by: Juan Quintela quint...@redhat.com
Signed-off-by: Juan Quintela quint...@redhat.com
---
tests/vmstate-static-checker-data/dump2.json | 6 --
1 file changed, 6 deletions(-)
diff --git a/tests/vmstate-static-checker-data/dump2.json
b/tests/vmstate-static-checker-data/dump2.json
index f6b52d0..34bfbf6 100644
--- a/tests/vmstate-static-checker-data/dump2.json
+++ b/tests/vmstate-static-checker-data/dump2.json
@@ -637,12 +637,6 @@
version_id: 0,
field_exists: false,
size: 256
- },
- {
-field: irq_state,
-version_id: 2,
-field_exists: false,
-size: 16
}
]
}
--
1.9.3
