[Qemu-devel] [PATCH 12/15] cpu_ldst_template.h: Use ld*_p directly rather than via ld*_raw macros
The ld*_raw and st*_raw macros are now only used within the code
produced by cpu_ldst_template.h, and only in three places.
Expand these out to just call the ld_p and st_p functions directly.
Note that in all the callsites the address argument is a uintptr_t,
so we can drop that part of the double-cast used in the saddr() and
laddr() macros.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
include/exec/cpu_ldst_template.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/exec/cpu_ldst_template.h b/include/exec/cpu_ldst_template.h
index 006093a..3b53605 100644
--- a/include/exec/cpu_ldst_template.h
+++ b/include/exec/cpu_ldst_template.h
@@ -79,7 +79,7 @@ glue(glue(cpu_ld, USUFFIX), MEMSUFFIX)(CPUArchState *env,
target_ulong ptr)
res = glue(glue(helper_ld, SUFFIX), MMUSUFFIX)(env, addr, mmu_idx);
} else {
uintptr_t hostaddr = addr + env-tlb_table[mmu_idx][page_index].addend;
-res = glue(glue(ld, USUFFIX), _raw)(hostaddr);
+res = glue(glue(ld, USUFFIX), _p)((uint8_t *)hostaddr);
}
return res;
}
@@ -101,7 +101,7 @@ glue(glue(cpu_lds, SUFFIX), MEMSUFFIX)(CPUArchState *env,
target_ulong ptr)
MMUSUFFIX)(env, addr, mmu_idx);
} else {
uintptr_t hostaddr = addr + env-tlb_table[mmu_idx][page_index].addend;
-res = glue(glue(lds, SUFFIX), _raw)(hostaddr);
+res = glue(glue(lds, SUFFIX), _p)((uint8_t *)hostaddr);
}
return res;
}
@@ -127,7 +127,7 @@ glue(glue(cpu_st, SUFFIX), MEMSUFFIX)(CPUArchState *env,
target_ulong ptr,
glue(glue(helper_st, SUFFIX), MMUSUFFIX)(env, addr, v, mmu_idx);
} else {
uintptr_t hostaddr = addr + env-tlb_table[mmu_idx][page_index].addend;
-glue(glue(st, SUFFIX), _raw)(hostaddr, v);
+glue(glue(st, SUFFIX), _p)((uint8_t *)hostaddr, v);
}
}
--
1.9.1
Re: [Qemu-devel] [PATCH 03/15] target-sparc: Don't use {ld, st}*_raw functions
Peter Maydell peter.mayd...@linaro.org writes:
Instead of using the _raw family of ld/st accessor functions, use
cpu_*_data. All this code is CONFIG_USER_ONLY, so the two are the
same semantically, but the _raw functions are really a detail of
the implementation which has leaked into a few callsites like this one.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
Reviewed-by: Alex Bennée alex.ben...@linaro.org
---
target-sparc/ldst_helper.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/target-sparc/ldst_helper.c b/target-sparc/ldst_helper.c
index 1a62e19..e62228c 100644
--- a/target-sparc/ldst_helper.c
+++ b/target-sparc/ldst_helper.c
@@ -1122,17 +1122,17 @@ uint64_t helper_ld_asi(CPUSPARCState *env,
target_ulong addr, int asi, int size,
{
switch (size) {
case 1:
-ret = ldub_raw(addr);
+ret = cpu_ldub_data(env, addr);
break;
case 2:
-ret = lduw_raw(addr);
+ret = cpu_lduw_data(env, addr);
break;
case 4:
-ret = ldl_raw(addr);
+ret = cpu_ldl_data(env, addr);
break;
default:
case 8:
-ret = ldq_raw(addr);
+ret = cpu_ldq_data(env, addr);
break;
}
}
@@ -1239,17 +1239,17 @@ void helper_st_asi(CPUSPARCState *env, target_ulong
addr, target_ulong val,
{
switch (size) {
case 1:
-stb_raw(addr, val);
+cpu_stb_data(env, addr, val);
break;
case 2:
-stw_raw(addr, val);
+cpu_stw_data(env, addr, val);
break;
case 4:
-stl_raw(addr, val);
+cpu_stl_data(env, addr, val);
break;
case 8:
default:
-stq_raw(addr, val);
+cpu_stq_data(env, addr, val);
break;
}
}
@@ -2289,8 +2289,8 @@ void helper_ldqf(CPUSPARCState *env, target_ulong addr,
int mem_idx)
break;
}
#else
-u.ll.upper = ldq_raw(address_mask(env, addr));
-u.ll.lower = ldq_raw(address_mask(env, addr + 8));
+u.ll.upper = cpu_ldq_data(env, address_mask(env, addr));
+u.ll.lower = cpu_ldq_data(env, address_mask(env, addr + 8));
QT0 = u.q;
#endif
}
@@ -2326,8 +2326,8 @@ void helper_stqf(CPUSPARCState *env, target_ulong addr,
int mem_idx)
}
#else
u.q = QT0;
-stq_raw(address_mask(env, addr), u.ll.upper);
-stq_raw(address_mask(env, addr + 8), u.ll.lower);
+cpu_stq_data(env, address_mask(env, addr), u.ll.upper);
+cpu_stq_data(env, address_mask(env, addr + 8), u.ll.lower);
#endif
}
--
Alex Bennée
Re: [Qemu-devel] [RFC PATCH 4/4] hw/arm/sysbus-fdt: arm, pl330 vfio device property
Hi Baptiste,
On 01/12/2015 02:21 PM, Baptiste Reynal wrote:
Adapt arm,pl330 function to use the vfio device property API.
Clock apb-pclk is the default if a clock is needed by the device.
Three optional parameters are taken into account :
- #dma-cells
- #dma-channels
- #dma-requests
Signed-off-by: Baptiste Reynal b.rey...@virtualopensystems.com
---
hw/arm/sysbus-fdt.c | 120
1 file changed, 103 insertions(+), 17 deletions(-)
diff --git a/hw/arm/sysbus-fdt.c b/hw/arm/sysbus-fdt.c
index 087e788..a0adc50 100644
--- a/hw/arm/sysbus-fdt.c
+++ b/hw/arm/sysbus-fdt.c
@@ -96,13 +96,13 @@ static int set_interrupts_fdt_node(char *nodename,
SysBusDevice *sbdev,
irq_attr[3*i+2] = cpu_to_be32(((__u32 *) irq_prop-data)[3*i+2]);
}
-ret = qemu_fdt_setprop(fdt, nodename, interrupts,
-irq_attr, vbasedev-num_irqs*3*sizeof(uint32_t));
+ ret = qemu_fdt_setprop(fdt, nodename, interrupts,
+ irq_attr, vbasedev-num_irqs*3*sizeof(uint32_t));
delta may be removed
g_free(irq_attr);
g_free(irq_prop);
-return ret;
+ return ret;
delta may be removed
}
/**
@@ -140,6 +140,54 @@ static int set_regions_fdt_node(char *nodename,
SysBusDevice *sbdev,
return ret;
}
may deserve a comment and/or pointer to
Documentation/devicetree/bindings/arm/primecell.txt; don't know whether
this is the reference doc, sorry.
+static int set_arm_primecell_node(char *nodename, SysBusDevice *sbdev, void
+*opaque)
+{
+PlatformBusFdtData *data = opaque;
+void *fdt = data-fdt;
+int ret;
+VFIOPlatformDevice *vdev = VFIO_PLATFORM_DEVICE(sbdev);
+VFIODevice *vbasedev = vdev-vbasedev;
+struct vfio_dev_property *property;
+
Wouldn't it make sense to handle the required compatible prop here?
+/* Optional properties */
+property = vfio_get_dev_property(vbasedev-fd, interrupts,
+VFIO_DEV_PROPERTY_TYPE_U32);
+if (property != NULL) {
+ret = set_interrupts_fdt_node(nodename, sbdev, opaque);
+if (ret 0) {
+error_report(could not set interrupts property of node %s,
+nodename);
+goto fail;
in case of fail the property is not released.
+}
+g_free(property);
+}
+
+property = vfio_get_dev_property(vbasedev-fd, clock-names,
+VFIO_DEV_PROPERTY_TYPE_STRINGS);
+if (property != NULL) {
+/* If a clock is attached, we rely on apb-pclk */
+/* Check clock existence */
+ret = fdt_path_offset(fdt, /apb-pclk);
+
+if (ret 0) {
+error_report(could not set clocks property of node %s,
nodename);
+goto fail;
release property
+} else {
+qemu_fdt_setprop_cells(fdt, nodename, clocks,
+qemu_fdt_getprop_cell(fdt, /apb-pclk, phandle));
+char clock_names[] = apb_pclk;
+qemu_fdt_setprop(fdt, nodename, clock-names, clock_names,
+sizeof(clock_names));
+}
+g_free(property);
do you intend to support other optional properties?
+}
+
+return 0;
+
+fail:
+return -1;
+}
/**
* add_calxeda_midway_xgmac_fdt_node
*
@@ -213,6 +261,8 @@ static int add_arm_pl330_fdt_node(SysBusDevice *sbdev,
void *opaque)
VFIOPlatformDevice *vdev = VFIO_PLATFORM_DEVICE(sbdev);
VFIODevice *vbasedev = vdev-vbasedev;
Object *obj = OBJECT(sbdev);
+struct vfio_dev_property *property;
+int propint;
mmio_base = object_property_get_int(obj, mmio[0], NULL);
@@ -222,6 +272,13 @@ static int add_arm_pl330_fdt_node(SysBusDevice *sbdev,
void *opaque)
qemu_fdt_add_subnode(fdt, nodename);
+ret = set_arm_primecell_node(nodename, sbdev, opaque);
+if (ret 0) {
+error_report(could not set arm,primecell properties of node %s,
+nodename);
+goto fail;
+}
+
/*
* Process compatible string to deal with multiple strings
* (; is replaced by \0)
@@ -237,20 +294,6 @@ static int add_arm_pl330_fdt_node(SysBusDevice *sbdev,
void *opaque)
qemu_fdt_setprop(fdt, nodename, compatible,
compat, compat_str_len);
-/* Setup clocks for AMBA device */
-/* Check clock existence */
-ret = fdt_path_offset(fdt, /apb-pclk);
-
-if (ret 0) {
-error_report(could not set clocks property of node %s, nodename);
-} else {
-qemu_fdt_setprop_cells(fdt, nodename, clocks,
-qemu_fdt_getprop_cell(fdt, /apb-pclk, phandle));
-char clock_names[] = apb_pclk;
-qemu_fdt_setprop(fdt, nodename, clock-names, clock_names,
-sizeof(clock_names));
-}
-
ret = set_regions_fdt_node(nodename, sbdev, opaque);
if (ret 0) {
@@ -266,6 +309,49 @@ static int
Re: [Qemu-devel] [RfC PATCH 2/3] sdl2: add support for display rendering using opengl.
On 2015-01-12 at 07:46, Gerd Hoffmann wrote: Hi, +glBegin(GL_QUADS); +glTexCoord2f(0, 1); glVertex3f(-1, -1, 0); +glTexCoord2f(0, 0); glVertex3f(-1, 1, 0); +glTexCoord2f(1, 0); glVertex3f(1, 1, 0); +glTexCoord2f(1, 1); glVertex3f(1, -1, 0); +glEnd(); I've been trained to hate direct mode, but it should be fine for just this quad. --verbose please. Guess for longer sequences it would be much more efficient to compile this into a shader program? Well, again, I'm used to OpenGL 3/4 Core now which doesn't have the immediate mode any more. [ ... ] [ ... ] and maybe for some reason there are people which want to use qemu with OpenGL acceleration on a pre OpenGL 2 machine. For virtio-gpu we'll need OPENGL 3 anyway, so I don't feel like caring too much about old opengl versions. How would the opengl 3/4 version of the above would look like? Regarding OpenGL 3/4 Core, you'd need some shaders and a buffer for the vertex data. So, regarding the vertex buffers, you'd have to create a buffer with glGenBuffers(), bind it to GL_ARRAY_BUFFER with glBindBuffer() and fill it with glBufferData(). Then, for every (vertex) attribute your vertex shader has, you call glVertexAttribPointer() (after glEnableVertexArray()) to specify the part of the buffer to be used for that attribute. You can receive the ID required for glVertexAttribPointer() by using glGetAttribLocation() on the linked shader program. It's probably best to just go for the OpenGL 1 (or 3/4 Compatibility) version for now and I'll see to a patch to make it 3/4 Core later on. Then we can decide what to do and don't have to decide now. Max Using glTexSubImage2D() would give us the advantage of being able to perform partial updates on the texture; but it seems to fit pretty bad into the existing code. To make it fit, I'd call glTexSubImage2D() directly in sdl2_gl_update() and just draw the quad here. Yes, that should work. Done, also factoring this into helper functions so gtk can use this too some day, new series sent out, please have a look. thanks, Gerd
Re: [Qemu-devel] [PATCH 2/3] multiboot: Fix offset of bootloader name
On 2015-01-15 at 06:26, Kevin Wolf wrote:
This fixes a bug introduced in commit 5eba5a66 ('Add bootloader name to
multiboot implementation').
The calculation of the bootloader name offset didn't consider space
occupied by module command lines, so some unlucky module got its command
line partially overwritten with a qemu string.
Signed-off-by: Kevin Wolf kw...@redhat.com
---
hw/i386/multiboot.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/hw/i386/multiboot.c b/hw/i386/multiboot.c
index f86d351..1adbe9e 100644
--- a/hw/i386/multiboot.c
+++ b/hw/i386/multiboot.c
@@ -156,6 +156,7 @@ int load_multiboot(FWCfgState *fw_cfg,
MultibootState mbs;
uint8_t bootinfo[MBI_SIZE];
uint8_t *mb_bootinfo_data;
+uint32_t cmdline_len;
/* Ok, let's see if it is a multiboot image.
The header is 12x32bit long, so the latest entry may be 8192 - 48. */
@@ -258,27 +259,28 @@ int load_multiboot(FWCfgState *fw_cfg,
mbs.offset_mbinfo = mbs.mb_buf_size;
/* Calculate space for cmdlines, bootloader name, and mb_mods */
-mbs.mb_buf_size += strlen(kernel_filename) + 1;
-mbs.mb_buf_size += strlen(kernel_cmdline) + 1;
-mbs.mb_buf_size += strlen(bootloader_name) + 1;
+cmdline_len = strlen(kernel_filename) + 1;
+cmdline_len += strlen(kernel_cmdline) + 1;
if (initrd_filename) {
const char *r = initrd_filename;
-mbs.mb_buf_size += strlen(r) + 1;
+cmdline_len += strlen(r) + 1;
mbs.mb_mods_avail = 1;
while (*(r = get_opt_value(NULL, 0, r))) {
mbs.mb_mods_avail++;
r++;
}
-mbs.mb_buf_size += MB_MOD_SIZE * mbs.mb_mods_avail;
}
+mbs.mb_buf_size += cmdline_len;
+mbs.mb_buf_size += MB_MOD_SIZE * mbs.mb_mods_avail;
+mbs.mb_buf_size += strlen(bootloader_name) + 1;
I would have swapped these two lines to reflect their order in mb_buf,
but it's fine either way.
+
mbs.mb_buf_size = TARGET_PAGE_ALIGN(mbs.mb_buf_size);
/* enlarge mb_buf to hold cmdlines, bootloader, mb-info structs */
mbs.mb_buf= g_realloc(mbs.mb_buf, mbs.mb_buf_size);
mbs.offset_cmdlines = mbs.offset_mbinfo + mbs.mb_mods_avail *
MB_MOD_SIZE;
-mbs.offset_bootloader = mbs.offset_cmdlines + strlen(kernel_filename) + 1
-+ strlen(kernel_cmdline) + 1;
+mbs.offset_bootloader = mbs.offset_cmdlines + cmdline_len;
if (initrd_filename) {
char *next_initrd, not_last;
Reviewed-by: Max Reitz mre...@redhat.com
Re: [Qemu-devel] [PATCH] arm: define version-based machine type for ARM
On 15 January 2015 at 17:50, Wei Huang w...@redhat.com wrote: ARM virt machine type (machvirt) had been stable for a while. But recently new devices have been added to support extra features. Considerring the support of long-term compatibility, it is time to create a version-based machine types. This patch defines a qemu 2.2 specific machine type (machvirt-2.2) and points the default machvirt to it. In the future new machine types can follow a similar naming scheme (e.g. machvirt-3.0, ...). Note that this patch doesn't change the semantic of existing QEMU command line. I don't think we're anywhere ready yet to support between version migration compatibility. We will want this *eventually* but we are a long long way away from needing it...(maybe a year?) thanks -- PMM
Re: [Qemu-devel] [PATCH 3/3] tests/multiboot: Add test for modules
On 2015-01-15 at 06:26, Kevin Wolf wrote:
This test case is meant to detect corruptions of the Multiboot modules
as well as the multiboot modules list and the module command lines.
Signed-off-by: Kevin Wolf kw...@redhat.com
---
tests/multiboot/Makefile| 5 -
tests/multiboot/libc.c | 12 ++
tests/multiboot/libc.h | 1 +
tests/multiboot/module.txt | 1 +
tests/multiboot/modules.c | 55 +
tests/multiboot/modules.out | 38 +++
tests/multiboot/run_test.sh | 9 +++-
7 files changed, 119 insertions(+), 2 deletions(-)
create mode 100644 tests/multiboot/module.txt
create mode 100644 tests/multiboot/modules.c
create mode 100644 tests/multiboot/modules.out
diff --git a/tests/multiboot/Makefile b/tests/multiboot/Makefile
index 34cdd81..36f01dc 100644
--- a/tests/multiboot/Makefile
+++ b/tests/multiboot/Makefile
@@ -6,11 +6,14 @@ LD=ld
LDFLAGS=-melf_i386 -T link.ld
LIBS=$(shell $(CC) $(CCFLAGS) -print-libgcc-file-name)
-all: mmap.elf
+all: mmap.elf modules.elf
mmap.elf: start.o mmap.o libc.o
$(LD) $(LDFLAGS) -o $@ $^ $(LIBS)
+modules.elf: start.o modules.o libc.o
+ $(LD) $(LDFLAGS) -o $@ $^ $(LIBS)
+
%.o: %.c
$(CC) $(CCFLAGS) -c -o $@ $^
diff --git a/tests/multiboot/libc.c b/tests/multiboot/libc.c
index 05abbd9..6df9bda 100644
--- a/tests/multiboot/libc.c
+++ b/tests/multiboot/libc.c
@@ -22,6 +22,18 @@
#include libc.h
+void* memcpy(void *dest, const void *src, int n)
This should be void *memcpy. There are three more occurences of this
in this patch (see checkpatch output).
+{
+char *d = dest;
+const char *s = src;
+
+while (n--) {
+*d++ = *s++;
+}
+
+return dest;
+}
+
static void print_char(char c)
{
outb(0xe9, c);
diff --git a/tests/multiboot/libc.h b/tests/multiboot/libc.h
index 80eec5b..04c9922 100644
--- a/tests/multiboot/libc.h
+++ b/tests/multiboot/libc.h
@@ -57,5 +57,6 @@ static inline void outb(uint16_t port, uint8_t data)
/* Misc functions */
void printf(const char *fmt, ...);
+void* memcpy(void *dest, const void *src, int n);
#endif
diff --git a/tests/multiboot/module.txt b/tests/multiboot/module.txt
new file mode 100644
index 000..54c1d27
--- /dev/null
+++ b/tests/multiboot/module.txt
@@ -0,0 +1 @@
+This is a test file that is used as a multiboot module.
diff --git a/tests/multiboot/modules.c b/tests/multiboot/modules.c
new file mode 100644
index 000..531601f
--- /dev/null
+++ b/tests/multiboot/modules.c
@@ -0,0 +1,55 @@
+/*
+ * Copyright (c) 2015 Kevin Wolf kw...@redhat.com
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include libc.h
+#include multiboot.h
+
+int test_main(uint32_t magic, struct mb_info *mbi)
+{
+struct mb_module *mod;
+unsigned int i;
+
+(void) magic;
+
+printf(Module list with %d entries at %x\n,
+ mbi-mods_count, mbi-mods_addr);
+
+for (i = 0, mod = (struct mb_module*) mbi-mods_addr;
+ i mbi-mods_count;
+ i++, mod++)
+{
+char buf[1024];
+unsigned int size = mod-mod_end - mod-mod_start;
+
+printf([%p] Module: %x - %x (%d bytes) '%s'\n,
+ mod, mod-mod_start, mod-mod_end, size, mod-string);
+
+/* Print test file, but remove the newline at the end */
+if (size sizeof(buf)) {
+memcpy(buf, (void*) mod-mod_start, size);
+buf[size - 1] = '\0';
+printf( Content: '%s'\n, buf);
+}
+}
+
+return 0;
+}
diff --git a/tests/multiboot/modules.out b/tests/multiboot/modules.out
new file mode 100644
index 000..1636708
--- /dev/null
+++ b/tests/multiboot/modules.out
@@ -0,0 +1,38 @@
+
+
+
+=== Running test case: modules.elf ===
+
+Module list with 0 entries at 102000
+
+
+=== Running test case: modules.elf -initrd module.txt ===
+
+Module list with 1 entries at
Re: [Qemu-devel] [PATCH v5 1/3] qcow2: Add qcow2_shrink_l1_and_l2_table for qcow2 shrinking
On 2015-01-03 at 07:23, Jun Li wrote: On Fri, 11/21 11:56, Max Reitz wrote: So, as for what I think we do need to do when shrinking (and keep in mind: The offset given to qcow2_truncate() is the guest size! NOT the host image size!): (1) Determine the first L2 table and the first entry in the table which will lie beyond the new guest disk size. Here is not correct always. Due to the COW, using offset to calculate the first entry of the first L2 table will be incorrect. Again: This is *not* about the host disk size or the host offset of some cluster, but about the *guest* disk size. Let's make up an example. You have a 2 GB disk but you want to resize it to 1.25 GB. The cluster size is 64 kB, therefore we have 2 GB / 64 kB = 32,768 data clusters (as long as there aren't any internal snapshots, which is a prerequisite for resizing qcow2 images). Every L2 table contains 65,536 / 8 = 8,192 entries; there are thus 32,768 / 8,192 = 4 L2 tables. As you can see, one can directly derive the number of data clusters and L2 tables from the guest disk size (as long as there aren't any internal snapshots). So of course we can do the same for the target disk size: 1.25 GB / 64 kB = 20,480 data clusters; 20,480 / 8,192 = 2.5 L2 tables, therefore we need three L2 tables but only half of the last one (4,096 entries). We know that every cluster references somewhere after that limit (that is, every entry in the fourth L2 table and every entry starting with index 4,096 in the third L2 table) is a data cluster with a guest offset somewhere beyond 1.25 GB, so we don't need it anymore. Thus, we simply discard all those data clusters and after that we can discard the fourth L2 table. That's it. If we really want to we can calculate the highest cluster host offset in use and truncate the image accordingly. But that's optional, see the last point in my problems with this approach list (having discarded the clusters should save us all the space already). Furthermore, as I'm saying in that list, to really solve this issue, we'd need qcow2 defragmentation. What I have done for this scenario: (1) if the first entry is the first entry of the L2 table, so will scan the previous L2 table(the previous L2 table location is in front of L2 table in L1 table). If the entry of previous L2 table is larger than offset, will discard this entry, too. (2) If the first entry is not the first entry of the L2 table, still to scan the whole L2 table to make sure no entry is beyond offset. (2) Discard all clusters beginning from there. (3) Discard all L2 tables which are then completely empty. (4) Update the header size. For this patch current's realizion, have include above 4 steps I think. Current patch, also have another step 5. (5) truncate the file. As I wrote above, you can do that but it shouldn't matter much because the discarded clusters should not use any disk space. Here I think we also should add discard refcount table and refcount block table when they are completely empty. And that's it. We can either speed up step (2) by implementing it manually, or we just use bdrv_discard() on the qcow2 BDS (in the simplest case: bdrv_discard(bs, DIV_ROUND_UP(offset, BDRV_SECTOR_SIZE), bs-total_sectors - DIV_ROUND_UP(offset, BDRV_SECTOR_SIZE));. We can incorporate step (3) by extending qcow2_discard_clusters() to free L2 tables when they are empty after discard_single_l2(). But we don't even have to that now. It's an optimization we can go about later. So, we can do (1), (2) and (3) in a single step: Just one bdrv_discard() call. But it's probably better to use qcow2_discard_clusters() instead and set the full_discard parameter to true. So: qcow2_discard_clusters(bs, offset, bs-total_sectors - offset / BDRV_SECTOR_SIZE, true);. Then update the guest disk size field in the header. And we're done. There are four problems with this approach: - qcow2_discard_clusters() might be slower than optimal. I personally don't care at all. - If bs-total_sectors * BDRV_SECTOR_SIZE - offset is greater than INT_MAX, this won't work. Trivially solvable by encapsulating the qcow2_discard_clusters() call in a loop which limits nb_clusters to INT_MAX / BDRV_SECTOR_SIZE. - The L1 table is not resized. Should not matter in practice at all. Yes, agree with you. - The file is not truncated. Does not matter either (because holes in the file are good enough), and we can't actually solve this problem without defragmentation anyway. There is one advantage: - It's extremely simple. It's literally below ten lines of code. I think the advantage far outweighs the disadvantage. But I may be wrong. What do you think? Hi max, Sorry for so late to reply as I am so busy recently. I think let's have an agreement on how to realize qcow2 shrinking first, then type code is better. Yes, this will probably be for the best. :-) Another issue, as gmail can not be used in current China, I have to use this email to reply. :) No
[Qemu-devel] [PATCH] arm: define version-based machine type for ARM
ARM virt machine type (machvirt) had been stable for a while. But recently
new devices have been added to support extra features. Considerring the
support of long-term compatibility, it is time to create a version-based
machine types.
This patch defines a qemu 2.2 specific machine type (machvirt-2.2) and
points the default machvirt to it. In the future new machine types can
follow a similar naming scheme (e.g. machvirt-3.0, ...). Note that this
patch doesn't change the semantic of existing QEMU command line.
With this patch, machine type querry (-M ?) will print the following:
virt ARM Virtual Machine v2.2 (alias of machvirt-2.2)
machvirt-2.2 ARM Virtual Machine v2.2 (default)
Signed-off-by: Wei Huang w...@redhat.com
---
hw/arm/virt.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 2353440..6174abd 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -701,15 +701,37 @@ static void virt_class_init(ObjectClass *oc, void *data)
static const TypeInfo machvirt_info = {
.name = TYPE_VIRT_MACHINE,
.parent = TYPE_MACHINE,
+.abstract = true,
.instance_size = sizeof(VirtMachineState),
.instance_init = virt_instance_init,
.class_size = sizeof(VirtMachineClass),
.class_init = virt_class_init,
};
+static void machvirt_2_2_class_init(ObjectClass *oc, void *data)
+{
+MachineClass *mc = MACHINE_CLASS(oc);
+static GlobalProperty compat_props[] = {
+{ /* end of list */ }
+};
+
+mc-name = machvirt-2.2;
+mc-desc = ARM Virtual Machine v2.2;
+mc-alias = virt;
+mc-is_default = 1;
+mc-compat_props = compat_props;
+}
+
+static const TypeInfo machvirt_2_2_info = {
+.name = TYPE_VIRT_MACHINE -2.2,
+.parent = TYPE_VIRT_MACHINE,
+.class_init = machvirt_2_2_class_init,
+};
+
static void machvirt_machine_init(void)
{
type_register_static(machvirt_info);
+type_register_static(machvirt_2_2_info);
}
machine_init(machvirt_machine_init);
--
1.8.3.1
Re: [Qemu-devel] [PATCH 00/15] Clean up cpu-ldst ld/st memory accessors
On 15 January 2015 at 15:32, Lluís Vilanova vilan...@ac.upc.edu wrote:
I haven't reviewed the patches, but that's a much appreciated cleanup! I was
also trying to make sense of all the variants while implementing guest memory
access tracing
I drew the following terrible ASCII art diagram of the remaining
memory access functions...
(pastebin link for those without fixed-width mail clients:
http://pastebin.ubuntu.com/9757219/ )
If anybody feels they can rearrange it into something less
confusing do feel free :-)
+--+
|
|
|
+-+
|
| |
| |
| |
| |
| |
+--+
| |
| ||
| | |
| ||
v v |
| || MemoryRegion callbacks
ld/st_*_p, memcpy, etc ! --+
| || ^
on host memory
| || |
^ ^^
| || |
| ||
| || |
| ||
| || |
| ||
| || |
+ ||
| || +
+ld/st_*_phys ! ||
| ||+- io_mem_read,
---+ ||
| ||+ io_mem_write !
||
| || io_read*, io_write* ---+
||
| ||^|
||
| ||||
+|
| |||+
address_space_{rw,read,write} ! |
| ||+ ^
^ |
| |+helper_ld_* --+ |
| |
| |^ | |
| |
| || | |
| +
| || | cpu_physical_memory_rw c+---+
| cpu_physical_memory_write_rom !
| || | ^ !
| ^
| || | |
+ |
| |+ | |
dma_memory_rw c !|
| ++ cpu_ld/st_* ! | |
|
| | |
|
| + |
|
+-+ generated TCG code|
+
+-+
cpu_physical_memory_rw_debug !
! marks APIs intended for use by other parts of QEMU
-- PMM
Re: [Qemu-devel] [PATCH 0/3] multiboot: Fix offset of bootloader name
On 01/15/2015 04:26 AM, Kevin Wolf wrote: This fixes a recent Multiboot load regression (see patch 2) that we noticed while hacking on the advent calendar image for December 24. These changes all look fine to me.
Re: [Qemu-devel] [PATCH v4 39/47] postcopy_ram.c: place_page and helpers
* David Gibson (da...@gibson.dropbear.id.au) wrote:
On Fri, Oct 03, 2014 at 06:47:45PM +0100, Dr. David Alan Gilbert (git) wrote:
From: Dr. David Alan Gilbert dgilb...@redhat.com
postcopy_place_page (etc) provide a way for postcopy to place a page
into guests memory atomically (using the new remap_anon_pages syscall).
Signed-off-by: Dr. David Alan Gilbert dgilb...@redhat.com
---
include/migration/migration.h| 2 +
include/migration/postcopy-ram.h | 23 +++
postcopy-ram.c | 145
++-
3 files changed, 168 insertions(+), 2 deletions(-)
diff --git a/include/migration/migration.h b/include/migration/migration.h
index 5bc01d5..58ac7bf 100644
--- a/include/migration/migration.h
+++ b/include/migration/migration.h
@@ -96,6 +96,8 @@ struct MigrationIncomingState {
QEMUFile *return_path;
QemuMutex rp_mutex;/* We send replies from multiple threads */
PostcopyPMIpostcopy_pmi;
+void *postcopy_tmp_page;
+long postcopy_place_skipped; /* Check for incorrect place
ops */
};
MigrationIncomingState *migration_incoming_get_current(void);
diff --git a/include/migration/postcopy-ram.h
b/include/migration/postcopy-ram.h
index 413b670..0210491 100644
--- a/include/migration/postcopy-ram.h
+++ b/include/migration/postcopy-ram.h
@@ -80,4 +80,27 @@ void postcopy_discard_send_chunk(MigrationState *ms,
PostcopyDiscardState *pds,
void postcopy_discard_send_finish(MigrationState *ms,
PostcopyDiscardState *pds);
+/*
+ * Place a zero'd page of memory at *host
+ * returns 0 on success
+ */
+int postcopy_place_zero_page(MigrationIncomingState *mis, void *host,
+ long bitmap_offset);
+
+/*
+ * Place a page (from) at (host) efficiently
+ *There are restrictions on how 'from' must be mapped, in general best
+ *to use other postcopy_ routines to allocate.
+ * returns 0 on success
+ */
+int postcopy_place_page(MigrationIncomingState *mis, void *host, void
*from,
+long bitmap_offset);
+
+/*
+ * Allocate a page of memory that can be mapped at a later point in time
+ * using postcopy_place_page
+ * Returns: Pointer to allocated page
+ */
+void *postcopy_get_tmp_page(MigrationIncomingState *mis, long
bitmap_offset);
+
#endif
diff --git a/postcopy-ram.c b/postcopy-ram.c
index 8b2a035..19d4b20 100644
--- a/postcopy-ram.c
+++ b/postcopy-ram.c
@@ -229,7 +229,6 @@ static PostcopyPMIState postcopy_pmi_get_state_nolock(
}
/* Retrieve the state of the given page */
-__attribute__ (( unused )) /* Until later in patch series */
static PostcopyPMIState postcopy_pmi_get_state(MigrationIncomingState *mis,
size_t bitmap_index)
{
@@ -245,7 +244,6 @@ static PostcopyPMIState
postcopy_pmi_get_state(MigrationIncomingState *mis,
* Set the page state to the given state if the previous state was as
expected
* Return the actual previous state.
*/
-__attribute__ (( unused )) /* Until later in patch series */
static PostcopyPMIState postcopy_pmi_change_state(MigrationIncomingState
*mis,
size_t bitmap_index,
PostcopyPMIState expected_state,
@@ -464,6 +462,7 @@ static int cleanup_area(const char *block_name, void
*host_addr,
int postcopy_ram_incoming_init(MigrationIncomingState *mis, size_t
ram_pages)
{
postcopy_pmi_init(mis, ram_pages);
+mis-postcopy_place_skipped = -1;
if (qemu_ram_foreach_block(init_area, mis)) {
return -1;
@@ -482,6 +481,10 @@ int
postcopy_ram_incoming_cleanup(MigrationIncomingState *mis)
return -1;
}
+if (mis-postcopy_tmp_page) {
+munmap(mis-postcopy_tmp_page, getpagesize());
+mis-postcopy_tmp_page = NULL;
+}
return 0;
}
@@ -551,6 +554,126 @@ int postcopy_ram_enable_notify(MigrationIncomingState
*mis)
return 0;
}
+/*
+ * Place a zero'd page of memory at *host
+ * returns 0 on success
+ * bitmap_offset: Index into the migration bitmaps
+ */
+int postcopy_place_zero_page(MigrationIncomingState *mis, void *host,
+ long bitmap_offset)
+{
+void *tmp = postcopy_get_tmp_page(mis, bitmap_offset);
+if (!tmp) {
+return -ENOMEM;
+}
+*(char *)tmp = 0;
+return postcopy_place_page(mis, host, tmp, bitmap_offset);
+}
+
+/*
+ * Place a target page (from) at (host) efficiently
+ *There are restrictions on how 'from' must be mapped, in general best
+ *to use other postcopy_ routines to allocate.
+ * returns 0 on success
+ * bitmap_offset: Index into the migration bitmaps
+ *
+
Re: [Qemu-devel] kvmclock, Migration, and NTP clock jitter
On 15/01/2015 17:39, Mohammed Gamal wrote: The increase in the jitter and offset values is well within the 500 ppm frequency tolerance limit, and therefore are easily corrected by subsequent NTP clock sync events, but some live migrations do cause much higher jitter and offset jumps, which can not be corrected by NTP and cause the time to go way off. Any idea why this is the case? It might be fixed in QEMU 2.2. See https://lists.gnu.org/archive/html/qemu-devel/2014-09/msg01239.html Paolo
Re: [Qemu-devel] [PATCH] arm: define version-based machine type for ARM
On 01/15/2015 12:10 PM, Peter Maydell wrote: On 15 January 2015 at 17:50, Wei Huang w...@redhat.com wrote: ARM virt machine type (machvirt) had been stable for a while. But recently new devices have been added to support extra features. Considerring the support of long-term compatibility, it is time to create a version-based machine types. This patch defines a qemu 2.2 specific machine type (machvirt-2.2) and points the default machvirt to it. In the future new machine types can follow a similar naming scheme (e.g. machvirt-3.0, ...). Note that this patch doesn't change the semantic of existing QEMU command line. I don't think we're anywhere ready yet to support between version migration compatibility. We will want this *eventually* but we are a long long way away from needing it...(maybe a year?) Thanks, Peter. I think migration support is getting closer than one year. It might not create problems at the beginning. So I understand your point. -Wei thanks -- PMM
Re: [Qemu-devel] [PATCH] WIP: add GCoroutine support
On Fri, Jan 09, 2015 at 06:19:50PM +0100, Marc-André Lureau wrote: Learn to use the GCoroutine library instead of qemu own coroutine implementation. GCoroutine is hosted on github: https://github.com/elmarco/gcoroutine This allows to share the same coroutine implementation between various projects (gtk-vnc and spice-gtk). It is related to the effort to push coroutine support in GLib. See also: https://bugzilla.gnome.org/show_bug.cgi?id=719362 Notes: - there are no GCoroutine releases, the API isn't frozen - this patch hasn't been thoroughly tested - GCoroutine doesn't implement pools yet - GCoroutine is missing sigaltstack based coroutines - spice-gtk and gtk-vnc patches are being worked on The GCoroutine API has a very direct mapping to QEMU's coroutine interface: https://github.com/elmarco/gcoroutine/blob/master/src/gcoroutine.h I like that you added gpointer arguments and return values to enter/yield. When writing the QEMU coroutine interface I dropped them because I felt we wouldn't need them, but they are appropriate in a general-purpose coroutine library. Kevin Lieven and Peter Lieven are currently measuring and improving coroutine performance in the QEMU block layer. I guess this will result in code changes to QEMU's coroutines implementation over the next weeks. Stefan pgpCJh0eijngA.pgp Description: PGP signature
Re: [Qemu-devel] [RFC PATCH v2 2/3] hw/vfio: amba device support
Baptiste,
On 12/22/2014 05:23 PM, Baptiste Reynal wrote:
Add VFIO_DEVICE_TYPE_AMBA.
Differentiate amba and platform devices according to compatible string.
Signed-off-by: Baptiste Reynal b.rey...@virtualopensystems.com
---
hw/vfio/platform.c| 15 ---
include/hw/vfio/vfio-common.h | 1 +
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/hw/vfio/platform.c b/hw/vfio/platform.c
index 39eef08..0a96178 100644
--- a/hw/vfio/platform.c
+++ b/hw/vfio/platform.c
@@ -563,8 +563,13 @@ static int vfio_base_device_init(VFIODevice *vbasedev)
}
/* Check that the host device exists */
-snprintf(path, sizeof(path), /sys/bus/platform/devices/%s/,
- vbasedev-name);
+if (vbasedev-type == VFIO_DEVICE_TYPE_AMBA) {
+snprintf(path, sizeof(path), /sys/bus/amba/devices/%s/,
+vbasedev-name);
+} else {
+snprintf(path, sizeof(path), /sys/bus/platform/devices/%s/,
+vbasedev-name);
+}
if (stat(path, st) 0) {
error_report(vfio: error: no such host device: %s, path);
@@ -661,7 +666,11 @@ static void vfio_platform_realize(DeviceState *dev,
Error **errp)
VFIODevice *vbasedev = vdev-vbasedev;
int i, ret;
-vbasedev-type = VFIO_DEVICE_TYPE_PLATFORM;
+if (strstr(vdev-compat, arm,primecell)) {
+vbasedev-type = VFIO_DEVICE_TYPE_AMBA;
+} else {
+vbasedev-type = VFIO_DEVICE_TYPE_PLATFORM;
+}
vbasedev-ops = vfio_platform_ops;
#ifdef CONFIG_KVM
diff --git a/include/hw/vfio/vfio-common.h b/include/hw/vfio/vfio-common.h
index 58fd786..2f1b09c 100644
--- a/include/hw/vfio/vfio-common.h
+++ b/include/hw/vfio/vfio-common.h
@@ -49,6 +49,7 @@ extern int vfio_kvm_device_fd;
enum {
VFIO_DEVICE_TYPE_PCI = 0,
VFIO_DEVICE_TYPE_PLATFORM = 1,
+VFIO_DEVICE_TYPE_AMBA = 2,
};
typedef struct VFIORegion {
With last version I added a check of the flags in vfio_populate_device
following Alex advice. You will need to check AMBA too.
Best Regards
Eric
[Qemu-devel] [PATCH 05/15] bsd-user/elfload.c: Don't use ldl() or ldq_raw()
Use get_user_u64() and get_user_ual() instead of the ldl() and
ldq_raw() functions.
[Note that this change is not compile tested as it is actually
in dead code -- none of the bsd-user configurations are PPC.]
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
bsd-user/elfload.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/bsd-user/elfload.c b/bsd-user/elfload.c
index 93fd9e4..2bf57eb 100644
--- a/bsd-user/elfload.c
+++ b/bsd-user/elfload.c
@@ -351,8 +351,10 @@ static inline void init_thread(struct target_pt_regs
*_regs, struct image_info *
_regs-gpr[1] = infop-start_stack;
#if defined(TARGET_PPC64) !defined(TARGET_ABI32)
-entry = ldq_raw(infop-entry) + infop-load_addr;
-toc = ldq_raw(infop-entry + 8) + infop-load_addr;
+get_user_u64(entry, infop-entry);
+entry += infop-load_addr;
+get_user_u64(toc, infop-entry + 8);
+toc += infop-load_addr;
_regs-gpr[2] = toc;
infop-entry = entry;
#endif
@@ -365,8 +367,9 @@ static inline void init_thread(struct target_pt_regs
*_regs, struct image_info *
get_user_ual(_regs-gpr[3], pos);
pos += sizeof(abi_ulong);
_regs-gpr[4] = pos;
-for (tmp = 1; tmp != 0; pos += sizeof(abi_ulong))
-tmp = ldl(pos);
+for (tmp = 1; tmp != 0; pos += sizeof(abi_ulong)) {
+get_user_ual(tmp, pos);
+}
_regs-gpr[5] = pos;
}
--
1.9.1
[Qemu-devel] [PATCH 15/15] cpu_ldst.h, cpu-all.h, bswap.h: Update documentation on ld/st accessors
Add documentation of what the cpu_*_* accessors look like.
Correct some minor errors in the existing documentation of the
direct _p accessor family. Remove the near-duplicate comment
on the _p accessors from cpu-all.h and replace it with a reference
to the comment in bswap.h.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
include/exec/cpu-all.h | 38 ++
include/exec/cpu_ldst.h | 21 -
include/qemu/bswap.h| 11 ++-
3 files changed, 32 insertions(+), 38 deletions(-)
diff --git a/include/exec/cpu-all.h b/include/exec/cpu-all.h
index 5fdd2fe..2c48286 100644
--- a/include/exec/cpu-all.h
+++ b/include/exec/cpu-all.h
@@ -115,43 +115,9 @@ static inline void tswap64s(uint64_t *s)
#define bswaptls(s) bswap64s(s)
#endif
-/* CPU memory access without any memory or io remapping */
-
-/*
- * the generic syntax for the memory accesses is:
- *
- * load: ld{type}{sign}{size}{endian}_{access_type}(ptr)
- *
- * store: st{type}{size}{endian}_{access_type}(ptr, val)
- *
- * type is:
- * (empty): integer access
- * f: float access
- *
- * sign is:
- * (empty): for floats or 32 bit size
- * u: unsigned
- * s: signed
- *
- * size is:
- * b: 8 bits
- * w: 16 bits
- * l: 32 bits
- * q: 64 bits
- *
- * endian is:
- * (empty): target cpu endianness or 8 bit access
- * r: reversed target cpu endianness (not implemented yet)
- * be : big endian (not implemented yet)
- * le : little endian (not implemented yet)
- *
- * access_type is:
- * raw: host memory access
- * user : user mode access using soft MMU
- * kernel : kernel mode access using soft MMU
+/* Target-endianness CPU memory access functions. These fit into the
+ * {ld,st}{type}{sign}{size}{endian}_p naming scheme described in bswap.h.
*/
-
-/* target-endianness CPU memory access functions */
#if defined(TARGET_WORDS_BIGENDIAN)
#define lduw_p(p) lduw_be_p(p)
#define ldsw_p(p) ldsw_be_p(p)
diff --git a/include/exec/cpu_ldst.h b/include/exec/cpu_ldst.h
index 16f4e30..d98ff17 100644
--- a/include/exec/cpu_ldst.h
+++ b/include/exec/cpu_ldst.h
@@ -23,7 +23,26 @@
*
* Used by target op helpers.
*
- * MMU mode suffixes are defined in target cpu.h.
+ * The syntax for the accessors is:
+ *
+ * load: cpu_ld{sign}{size}_{mmusuffix}(env, ptr)
+ *
+ * store: cpu_st{sign}{size}_{mmusuffix}(env, ptr, val)
+ *
+ * sign is:
+ * (empty): for 32 and 64 bit sizes
+ * u: unsigned
+ * s: signed
+ *
+ * size is:
+ * b: 8 bits
+ * w: 16 bits
+ * l: 32 bits
+ * q: 64 bits
+ *
+ * mmusuffix is one of the generic suffixes data or code, or
+ * (for softmmu configs) a target-specific MMU mode suffix as defined
+ * in target cpu.h.
*/
#ifndef CPU_LDST_H
#define CPU_LDST_H
diff --git a/include/qemu/bswap.h b/include/qemu/bswap.h
index 78c1ced..07d88de 100644
--- a/include/qemu/bswap.h
+++ b/include/qemu/bswap.h
@@ -204,7 +204,7 @@ typedef union {
* f: float access
*
* sign is:
- * (empty): for floats or 32 bit size
+ * (empty): for 32 or 64 bit sizes (including floats and doubles)
* u: unsigned
* s: signed
*
@@ -218,7 +218,16 @@ typedef union {
* he : host endian
* be : big endian
* le : little endian
+ * te : target endian
* (except for byte accesses, which have no endian infix).
+ *
+ * The target endian accessors are obviously only available to source
+ * files which are built per-target; they are defined in cpu-all.h.
+ *
+ * In all cases these functions take a host pointer.
+ * For accessors that take a guest address rather than a
+ * host address, see the cpu_{ld,st}_* accessors defined in
+ * cpu_ldst.h.
*/
static inline int ldub_p(const void *ptr)
--
1.9.1
[Qemu-devel] [PATCH 10/15] cpu_ldst.h: Remove unused very short ld*/st* defines
The very short ld*/st* defines are now not used anywhere; delete them. Signed-off-by: Peter Maydell peter.mayd...@linaro.org --- include/exec/cpu_ldst.h | 26 -- 1 file changed, 26 deletions(-) diff --git a/include/exec/cpu_ldst.h b/include/exec/cpu_ldst.h index 64d9087..2dc4775 100644 --- a/include/exec/cpu_ldst.h +++ b/include/exec/cpu_ldst.h @@ -82,20 +82,6 @@ #if defined(CONFIG_USER_ONLY) /* if user mode, no other memory access functions */ -#define ldub(p) ldub_raw(p) -#define ldsb(p) ldsb_raw(p) -#define lduw(p) lduw_raw(p) -#define ldsw(p) ldsw_raw(p) -#define ldl(p) ldl_raw(p) -#define ldq(p) ldq_raw(p) -#define ldfl(p) ldfl_raw(p) -#define ldfq(p) ldfq_raw(p) -#define stb(p, v) stb_raw(p, v) -#define stw(p, v) stw_raw(p, v) -#define stl(p, v) stl_raw(p, v) -#define stq(p, v) stq_raw(p, v) -#define stfl(p, v) stfl_raw(p, v) -#define stfq(p, v) stfq_raw(p, v) #define cpu_ldub_code(env1, p) ldub_raw(p) #define cpu_ldsb_code(env1, p) ldsb_raw(p) @@ -287,18 +273,6 @@ uint64_t helper_ldq_cmmu(CPUArchState *env, target_ulong addr, int mmu_idx); #undef CPU_MMU_INDEX #undef MEMSUFFIX -#define ldub(p) ldub_data(p) -#define ldsb(p) ldsb_data(p) -#define lduw(p) lduw_data(p) -#define ldsw(p) ldsw_data(p) -#define ldl(p) ldl_data(p) -#define ldq(p) ldq_data(p) - -#define stb(p, v) stb_data(p, v) -#define stw(p, v) stw_data(p, v) -#define stl(p, v) stl_data(p, v) -#define stq(p, v) stq_data(p, v) - #define CPU_MMU_INDEX (cpu_mmu_index(env)) #define MEMSUFFIX _code #define SOFTMMU_CODE_ACCESS -- 1.9.1
Re: [Qemu-devel] [PATCH 04/15] linux-user/elfload.c: Don't use _raw accessor functions
Peter Maydell peter.mayd...@linaro.org writes:
The _raw accessor functions are an implementation detail that has
leaked out to some callsites. Use get_user_u64() instead of ldq_raw().
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
Reviewed-by: Alex Bennée alex.ben...@linaro.org
---
linux-user/elfload.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index e2596a4..399c021 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -829,8 +829,11 @@ static inline void init_thread(struct target_pt_regs
*_regs, struct image_info *
_regs-gpr[1] = infop-start_stack;
#if defined(TARGET_PPC64) !defined(TARGET_ABI32)
if (get_ppc64_abi(infop) 2) {
-_regs-gpr[2] = ldq_raw(infop-entry + 8) + infop-load_bias;
-infop-entry = ldq_raw(infop-entry) + infop-load_bias;
+uint64_t val;
+get_user_u64(val, infop-entry + 8);
+_regs-gpr[2] = val + infop-load_bias;
+get_user_u64(val, infop-entry);
+infop-entry = val + infop-load_bias;
} else {
_regs-gpr[12] = infop-entry; /* r12 set to global entry address */
}
--
Alex Bennée
[Qemu-devel] kvmclock, Migration, and NTP clock jitter
Hi, I've seen some strange time behavior in some of our VMs usually triggered by live migration. In some VMs we have seen some significant time drift which NTP was not able to correct after doing a live migration. I've not been able so far to reproduce the same case, however, I did notice that live migration does introduce some increase in clock jitter values, and I am not sure if that might have anything to do with any significant time drift. Here is an example of a CentOS 6 guest running under qemu 1.2 before doing a live migration: [root@centos ~]# ntpq -pcrv remote refid st t when poll reach delay offset jitter == +helium.constant 18.26.4.105 2 u 65 64 377 60.539 -0.011 0.554 -209.118.204.201 128.9.176.30 2 u 47 64 377 15.750 -1.835 0.388 *time3.chpc.utah 198.60.22.2402 u 46 64 377 30.5853.934 0.253 +dns2.untangle.c 216.218.254.202 2 u 21 64 377 22.1962.345 0.740 associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync, version=ntpd 4.2.6p5@1.2349-o Sat Dec 20 02:53:39 UTC 2014 (1), processor=x86_64, system=Linux/2.6.32-504.3.3.el6.x86_64, leap=00, stratum=3, precision=-21, rootdelay=32.355, rootdisp=53.173, refid=155.101.3.115, reftime=d86264f3.444c75e7 Thu, Jan 15 2015 16:10:27.266, clock=d86265ed.10a34c1c Thu, Jan 15 2015 16:14:37.064, peer=3418, tc=6, mintc=3, offset=0.000, frequency=2.863, sys_jitter=2.024, clk_jitter=2.283, clk_wander=0.000 [root@centos ~]# ntpdc -c kerninfo pll offset: 0 s pll frequency:2.863 ppm maximum error:0.19838 s estimated error: 0.002282 s status: 2001 pll nano pll time constant:6 precision:1e-09 s frequency tolerance: 500 ppm Immediately after live migration, you can see that there is an increase in jitter values: [root@centos ~]# ntpq -pcrv remote refid st t when poll reach delay offset jitter == -helium.constant 18.26.4.105 2 u 59 64 377 60.556 -0.916 31.921 +209.118.204.201 128.9.176.30 2 u 38 64 377 15.717 28.879 12.220 +time3.chpc.utah 132.163.4.1032 u 45 64 353 30.6393.240 26.975 *dns2.untangle.c 216.218.254.202 2 u 17 64 377 22.248 33.039 11.791 associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync, version=ntpd 4.2.6p5@1.2349-o Sat Dec 20 02:53:39 UTC 2014 (1), processor=x86_64, system=Linux/2.6.32-504.3.3.el6.x86_64, leap=00, stratum=3, precision=-21, rootdelay=25.086, rootdisp=83.736, refid=74.123.29.4, reftime=d8626838.47529689 Thu, Jan 15 2015 16:24:24.278, clock=d8626849.4920018a Thu, Jan 15 2015 16:24:41.285, peer=3419, tc=6, mintc=3, offset=24.118, frequency=11.560, sys_jitter=15.145, clk_jitter=8.056, clk_wander=2.757 [root@centos ~]# ntpdc -c kerninfo pll offset: 0.0211957 s pll frequency:11.560 ppm maximum error:0.112523 s estimated error: 0.008055 s status: 2001 pll nano pll time constant:6 precision:1e-09 s frequency tolerance: 500 ppm The increase in the jitter and offset values is well within the 500 ppm frequency tolerance limit, and therefore are easily corrected by subsequent NTP clock sync events, but some live migrations do cause much higher jitter and offset jumps, which can not be corrected by NTP and cause the time to go way off. Any idea why this is the case? Regards, Mohammed
Re: [Qemu-devel] [PATCH] WIP: add GCoroutine support
On Fri, Jan 09, 2015 at 05:32:14PM +, Peter Maydell wrote: On 9 January 2015 at 17:19, Marc-André Lureau marcandre.lur...@gmail.com wrote: Learn to use the GCoroutine library instead of qemu own coroutine implementation. GCoroutine is hosted on github: https://github.com/elmarco/gcoroutine This allows to share the same coroutine implementation between various projects (gtk-vnc and spice-gtk). It is related to the effort to push coroutine support in GLib. See also: https://bugzilla.gnome.org/show_bug.cgi?id=719362 Notes: - there are no GCoroutine releases, the API isn't frozen - this patch hasn't been thoroughly tested - GCoroutine doesn't implement pools yet - GCoroutine is missing sigaltstack based coroutines - spice-gtk and gtk-vnc patches are being worked on It's bad enough having four coroutine backends without adding yet another one :-( I'm not sure we should take this patch unless/until GCoroutine is fully implemented and supported in a common enough version of glib that we could delete at least one of our other backends in favour of this... It's an RFC. I see this more of a way to collaborate on GCoroutine than something that needs to be merged into qemu.git today. Stefan pgpUuOHxvbZTO.pgp Description: PGP signature
Re: [Qemu-devel] [RFC PATCH v2 1/3] hw/vfio/sysbus-fdt: refactoring
Hi Baptiste,
On 12/22/2014 05:23 PM, Baptiste Reynal wrote:
Creates set_interrupts_fdt_node and set_regions_fdt_node
for code reusability.
Signed-off-by: Baptiste Reynal b.rey...@virtualopensystems.com
---
hw/arm/sysbus-fdt.c | 102
+---
1 file changed, 73 insertions(+), 29 deletions(-)
diff --git a/hw/arm/sysbus-fdt.c b/hw/arm/sysbus-fdt.c
index 15bb50c..f6ff8a7 100644
--- a/hw/arm/sysbus-fdt.c
+++ b/hw/arm/sysbus-fdt.c
@@ -58,6 +58,76 @@ typedef struct NodeCreationPair {
/* Device Specific Code */
/**
+ * set_interrupts_fdt_node
+ *
+ * Helper function, generate interrupts property for a given node
+ */
+static int set_interrupts_fdt_node(char *nodename, SysBusDevice *sbdev,
+void *opaque, int type, int flags)
+{
+PlatformBusFdtData *data = opaque;
+PlatformBusDevice *pbus = data-pbus;
+void *fdt = data-fdt;
+uint32_t *irq_attr;
+uint64_t irq_number;
+int i, ret;
+VFIOPlatformDevice *vdev = VFIO_PLATFORM_DEVICE(sbdev);
+VFIODevice *vbasedev = vdev-vbasedev;
+
+irq_attr = g_new(uint32_t, vbasedev-num_irqs*3);
+
+for (i = 0; i vbasedev-num_irqs; i++) {
+irq_number = platform_bus_get_irqn(pbus, sbdev , i)
+ + data-irq_start;
+irq_attr[3*i] = cpu_to_be32(type);
+irq_attr[3*i+1] = cpu_to_be32(irq_number);
+irq_attr[3*i+2] = cpu_to_be32(flags);
+}
+
+ ret = qemu_fdt_setprop(fdt, nodename, interrupts,
+ irq_attr, vbasedev-num_irqs*3*sizeof(uint32_t));
+
+g_free(irq_attr);
+
+ return ret;
+}
+
+/**
+ * set_regions_fdt_node
+ *
+ * Helper function, generate reg property for a given node
+ */
+static int set_regions_fdt_node(char *nodename, SysBusDevice *sbdev,
+void *opaque)
+{
+PlatformBusFdtData *data = opaque;
+PlatformBusDevice *pbus = data-pbus;
+void *fdt = data-fdt;
+uint64_t *reg_attr;
+uint64_t mmio_base;
+int i, ret;
+VFIOPlatformDevice *vdev = VFIO_PLATFORM_DEVICE(sbdev);
+VFIODevice *vbasedev = vdev-vbasedev;
+
+reg_attr = g_new(uint64_t, vbasedev-num_regions*4);
+
+for (i = 0; i vbasedev-num_regions; i++) {
+mmio_base = platform_bus_get_mmio_addr(pbus, sbdev, i);
+reg_attr[4*i] = 1;
+reg_attr[4*i+1] = mmio_base;
+reg_attr[4*i+2] = 1;
+reg_attr[4*i+3] = memory_region_size(vdev-regions[i]-mem);
+}
+
+ret = qemu_fdt_setprop_sized_cells_from_array(fdt, nodename, reg,
+ vbasedev-num_regions*2, reg_attr);
+
+g_free(reg_attr);
+
+return ret;
+}
+
+/**
* add_calxeda_midway_xgmac_fdt_node
*
* Generates a very simple node with following properties:
@@ -66,16 +136,12 @@ typedef struct NodeCreationPair {
static int add_calxeda_midway_xgmac_fdt_node(SysBusDevice *sbdev, void
*opaque)
{
PlatformBusFdtData *data = opaque;
-PlatformBusDevice *pbus = data-pbus;
void *fdt = data-fdt;
const char *parent_node = data-pbus_node_name;
int compat_str_len;
char *nodename;
-int i, ret;
-uint32_t *irq_attr;
-uint64_t *reg_attr;
+int ret;
uint64_t mmio_base;
-uint64_t irq_number;
VFIOPlatformDevice *vdev = VFIO_PLATFORM_DEVICE(sbdev);
VFIODevice *vbasedev = vdev-vbasedev;
Object *obj = OBJECT(sbdev);
@@ -92,35 +158,15 @@ static int
add_calxeda_midway_xgmac_fdt_node(SysBusDevice *sbdev, void *opaque)
qemu_fdt_setprop(fdt, nodename, compatible,
vdev-compat, compat_str_len);
-reg_attr = g_new(uint64_t, vbasedev-num_regions*4);
-
-for (i = 0; i vbasedev-num_regions; i++) {
-mmio_base = platform_bus_get_mmio_addr(pbus, sbdev, i);
-reg_attr[4*i] = 1;
-reg_attr[4*i+1] = mmio_base;
-reg_attr[4*i+2] = 1;
-reg_attr[4*i+3] = memory_region_size(vdev-regions[i]-mem);
-}
+ret = set_regions_fdt_node(nodename, sbdev, opaque);
-ret = qemu_fdt_setprop_sized_cells_from_array(fdt, nodename, reg,
- vbasedev-num_regions*2, reg_attr);
if (ret 0) {
error_report(could not set reg property of node %s, nodename);
goto fail;
}
-irq_attr = g_new(uint32_t, vbasedev-num_irqs*3);
+ret = set_interrupts_fdt_node(nodename, sbdev, opaque, 0, 0x4);
-for (i = 0; i vbasedev-num_irqs; i++) {
-irq_number = platform_bus_get_irqn(pbus, sbdev , i)
- + data-irq_start;
-irq_attr[3*i] = cpu_to_be32(0);
-irq_attr[3*i+1] = cpu_to_be32(irq_number);
-irq_attr[3*i+2] = cpu_to_be32(0x4);
-}
-
- ret = qemu_fdt_setprop(fdt, nodename, interrupts,
- irq_attr, vbasedev-num_irqs*3*sizeof(uint32_t));
if (ret 0) {
error_report(could not set interrupts property of node %s,
[Qemu-devel] [PATCH 06/15] linux-user/vm86.c: Use cpu_ldl_data c rather than plain ldl c
Use the cpu_ld*_data and cpu_st*_data family of functions to access
guest memory in vm86.c rather than the very short-named ldl/stl functions.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
linux-user/vm86.c | 57 ++-
1 file changed, 31 insertions(+), 26 deletions(-)
diff --git a/linux-user/vm86.c b/linux-user/vm86.c
index 45ef559..22a4eb9 100644
--- a/linux-user/vm86.c
+++ b/linux-user/vm86.c
@@ -45,29 +45,34 @@ static inline int is_revectored(int nr, struct
target_revectored_struct *bitmap)
return (((uint8_t *)bitmap)[nr 3] (nr 7)) 1;
}
-static inline void vm_putw(uint32_t segptr, unsigned int reg16, unsigned int
val)
+static inline void vm_putw(CPUX86State *env, uint32_t segptr,
+ unsigned int reg16, unsigned int val)
{
-stw(segptr + (reg16 0x), val);
+cpu_stw_data(env, segptr + (reg16 0x), val);
}
-static inline void vm_putl(uint32_t segptr, unsigned int reg16, unsigned int
val)
+static inline void vm_putl(CPUX86State *env, uint32_t segptr,
+ unsigned int reg16, unsigned int val)
{
-stl(segptr + (reg16 0x), val);
+cpu_stl_data(env, segptr + (reg16 0x), val);
}
-static inline unsigned int vm_getb(uint32_t segptr, unsigned int reg16)
+static inline unsigned int vm_getb(CPUX86State *env,
+ uint32_t segptr, unsigned int reg16)
{
-return ldub(segptr + (reg16 0x));
+return cpu_ldub_data(env, segptr + (reg16 0x));
}
-static inline unsigned int vm_getw(uint32_t segptr, unsigned int reg16)
+static inline unsigned int vm_getw(CPUX86State *env,
+ uint32_t segptr, unsigned int reg16)
{
-return lduw(segptr + (reg16 0x));
+return cpu_lduw_data(env, segptr + (reg16 0x));
}
-static inline unsigned int vm_getl(uint32_t segptr, unsigned int reg16)
+static inline unsigned int vm_getl(CPUX86State *env,
+ uint32_t segptr, unsigned int reg16)
{
-return ldl(segptr + (reg16 0x));
+return cpu_ldl_data(env, segptr + (reg16 0x));
}
void save_v86_state(CPUX86State *env)
@@ -221,7 +226,7 @@ static void do_int(CPUX86State *env, int intno)
ts-vm86plus.int21_revectored))
goto cannot_handle;
int_addr = (intno 2);
-segoffs = ldl(int_addr);
+segoffs = cpu_ldl_data(env, int_addr);
if ((segoffs 16) == TARGET_BIOSSEG)
goto cannot_handle;
LOG_VM86(VM86: emulating int 0x%x. CS:IP=%04x:%04x\n,
@@ -229,9 +234,9 @@ static void do_int(CPUX86State *env, int intno)
/* save old state */
ssp = env-segs[R_SS].selector 4;
sp = env-regs[R_ESP] 0x;
-vm_putw(ssp, sp - 2, get_vflags(env));
-vm_putw(ssp, sp - 4, env-segs[R_CS].selector);
-vm_putw(ssp, sp - 6, env-eip);
+vm_putw(env, ssp, sp - 2, get_vflags(env));
+vm_putw(env, ssp, sp - 4, env-segs[R_CS].selector);
+vm_putw(env, ssp, sp - 6, env-eip);
ADD16(env-regs[R_ESP], -6);
/* goto interrupt handler */
env-eip = segoffs 0x;
@@ -285,7 +290,7 @@ void handle_vm86_fault(CPUX86State *env)
data32 = 0;
pref_done = 0;
do {
-opcode = vm_getb(csp, ip);
+opcode = vm_getb(env, csp, ip);
ADD16(ip, 1);
switch (opcode) {
case 0x66: /* 32-bit data */ data32=1; break;
@@ -306,10 +311,10 @@ void handle_vm86_fault(CPUX86State *env)
switch(opcode) {
case 0x9c: /* pushf */
if (data32) {
-vm_putl(ssp, sp - 4, get_vflags(env));
+vm_putl(env, ssp, sp - 4, get_vflags(env));
ADD16(env-regs[R_ESP], -4);
} else {
-vm_putw(ssp, sp - 2, get_vflags(env));
+vm_putw(env, ssp, sp - 2, get_vflags(env));
ADD16(env-regs[R_ESP], -2);
}
env-eip = ip;
@@ -317,10 +322,10 @@ void handle_vm86_fault(CPUX86State *env)
case 0x9d: /* popf */
if (data32) {
-newflags = vm_getl(ssp, sp);
+newflags = vm_getl(env, ssp, sp);
ADD16(env-regs[R_ESP], 4);
} else {
-newflags = vm_getw(ssp, sp);
+newflags = vm_getw(env, ssp, sp);
ADD16(env-regs[R_ESP], 2);
}
env-eip = ip;
@@ -335,7 +340,7 @@ void handle_vm86_fault(CPUX86State *env)
VM86_FAULT_RETURN;
case 0xcd: /* int */
-intno = vm_getb(csp, ip);
+intno = vm_getb(env, csp, ip);
ADD16(ip, 1);
env-eip = ip;
if (ts-vm86plus.vm86plus.flags TARGET_vm86dbg_active) {
@@ -350,14 +355,14 @@ void handle_vm86_fault(CPUX86State *env)
case 0xcf: /* iret */
if (data32) {
-newip = vm_getl(ssp, sp) 0x;
-newcs = vm_getl(ssp, sp + 4) 0x;
-newflags = vm_getl(ssp, sp + 8);
+newip = vm_getl(env, ssp, sp) 0x;
Re: [Qemu-devel] Help for beginner
Ady Wahyudi Paundu awpau...@gmail.com writes:
Hi all, Happy New Year (not too late I hope)
I also hope you guys don't' mind to be bothered by newbie questions
related to Qemu, because I really don't know where else to ask. I
want to learn how several aspects of qemu works, and it really hard to
find resources (physical or virtual) about it. From qemu
documentation QEMU does not have a high level design description
document - only the source code tells the full story
My question, if i want to learn CPU and/or Network related operation
within Qemu, what file (or function) should i put my focus into?
If you are interested in the TCG emulation then you'll probably want to
start with:
target-${PROCESSOR}/translate.c
Where the instruction decode is carried out to translate guest
instructions into TCG ops which are then used to generate host code.
for
example, simple ping operation from within a guest VM will use what
functions?
Thank you in advance.
regards,
ady
--
Alex Bennée
Re: [Qemu-devel] [PATCH 02/15] monitor.c: Use ld*_p() instead of ld*_raw()
Peter Maydell peter.mayd...@linaro.org writes:
The monitor code for doing a memory_dump() was using ld*_raw() to do
target-CPU accesses out of a local buf[] array. The correct functions
for this purpose are ld*_p(), which take a host pointer, rather than
ld*_raw(), which take an integer representing a guest address and
are somewhat meaningless in softmmu configurations. Nobody noticed
because for softmmu the _raw functions are the same as ldl_p but
with some extra casts thrown in. Switch to using the correct functions
instead.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
Reviewed-by: Alex Bennée alex.ben...@linaro.org
---
monitor.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/monitor.c b/monitor.c
index 1808e41..7e4f605 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1292,16 +1292,16 @@ static void memory_dump(Monitor *mon, int count, int
format, int wsize,
switch(wsize) {
default:
case 1:
-v = ldub_raw(buf + i);
+v = ldub_p(buf + i);
break;
case 2:
-v = lduw_raw(buf + i);
+v = lduw_p(buf + i);
break;
case 4:
-v = (uint32_t)ldl_raw(buf + i);
+v = (uint32_t)ldl_p(buf + i);
break;
case 8:
-v = ldq_raw(buf + i);
+v = ldq_p(buf + i);
break;
}
monitor_printf(mon, );
--
Alex Bennée
Re: [Qemu-devel] [PATCH 07/15] linux-user/main.c (m68k): Use get_user_u16 rather than lduw in cpu_loop
Peter Maydell peter.mayd...@linaro.org writes:
In the m68k cpu_loop() use get_user_u16 to read the immediate for
the simcall rahter than lduw, to bring it into line with how other
archs do it and to remove another user of the ldl family of functions.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
After getting lost tracing the many macro definitions from lduw ;-)
Reviewed-by: Alex Bennée alex.ben...@linaro.org
---
linux-user/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/linux-user/main.c b/linux-user/main.c
index 67b0231..65b5a36 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -2972,7 +2972,7 @@ void cpu_loop(CPUM68KState *env)
{
if (ts-sim_syscalls) {
uint16_t nr;
-nr = lduw(env-pc + 2);
+get_user_u16(nr, env-pc + 2);
env-pc += 4;
do_m68k_simcall(env, nr);
} else {
--
Alex Bennée
Re: [Qemu-devel] Press Inquiry: Qemu Advent Calendar (German Linux Magazin)
On Tue, Jan 13, 2015 at 01:35:55PM +0100, Tim Schürmann wrote: Hi Tim, In order to comply with the license on GPL images you will need to offer the source code (see links on http://qemu-advent-calendar.org/ for each image). The Ubuntu Core and Ceph sourcecodes won't fit on our DVD. So we have to provide links to the corresponding websites. Is this Ok with you? (My editor-in-chief said that this conform with the GPL.) I am not the (only) copyright holder of Ubuntu Core or Ceph, and I'm not a lawyer. You need to decide whether you are in compliance or not. My plan is to keep http://qemu-advent-calendar.org/ running in the foreseeable future so the sources should remain accessible. If you mirror the sources it would be best - that way you can continue providing source even if http://qemu-advent-calendar.org/ were to go offline. I'm CCing Matthew Hungerford at Pebble to confirm that the Pebble Smartwatch image can also be distributed. Did you got an answer already? Yes, Matthew responded. It was a Reply instead of Reply-All. I forgot to forward you his response (sorry): Date: Fri, 9 Jan 2015 11:12:52 -0800 From: Matthew Hungerford matthew.hungerf...@getpebble.com Sounds great, One of my german coworkers is a fan of Linux Magazin, and would get a kick out if it being featured there. Thanks for asking, Matthew All the best, Stefan pgplFE7LH3_5E.pgp Description: PGP signature
[Qemu-devel] [PATCH 08/15] target-mips: Don't use _raw load/store accessors
Use cpu_*_data instead of the direct *_raw load/store accessors.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
target-mips/op_helper.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/target-mips/op_helper.c b/target-mips/op_helper.c
index d619ba4..ea7d95f 100644
--- a/target-mips/op_helper.c
+++ b/target-mips/op_helper.c
@@ -74,7 +74,7 @@ void helper_raise_exception(CPUMIPSState *env, uint32_t
exception)
static inline type do_##name(CPUMIPSState *env, target_ulong addr, \
int mem_idx) \
{ \
-return (type) insn##_raw(addr); \
+return (type) cpu_##insn##_data(env, addr); \
}
#else
#define HELPER_LD(name, insn, type) \
@@ -101,7 +101,7 @@ HELPER_LD(ld, ldq, int64_t)
static inline void do_##name(CPUMIPSState *env, target_ulong addr, \
type val, int mem_idx) \
{ \
-insn##_raw(addr, val); \
+cpu_##insn##_data(env, addr, val); \
}
#else
#define HELPER_ST(name, insn, type) \
--
1.9.1
Re: [Qemu-devel] [RFC PATCH v2 3/3] hw/vfio: add pl330 device support
On 12/22/2014 05:23 PM, Baptiste Reynal wrote:
Create a meta-device for PL330 DMA.
Add add_arm_pl330_fdt_node function, with multiple compatible string
and clocks support.
Signed-off-by: Baptiste Reynal b.rey...@virtualopensystems.com
---
hw/arm/sysbus-fdt.c | 84
hw/vfio/Makefile.objs| 1 +
hw/vfio/pl330.c | 41 +
include/hw/vfio/vfio-pl330.h | 26 ++
4 files changed, 152 insertions(+)
create mode 100644 hw/vfio/pl330.c
create mode 100644 include/hw/vfio/vfio-pl330.h
diff --git a/hw/arm/sysbus-fdt.c b/hw/arm/sysbus-fdt.c
index f6ff8a7..efdeea7 100644
--- a/hw/arm/sysbus-fdt.c
+++ b/hw/arm/sysbus-fdt.c
@@ -28,6 +28,9 @@
#include sysemu/sysemu.h
#include hw/vfio/vfio-platform.h
#include hw/vfio/vfio-calxeda-xgmac.h
+#include hw/vfio/vfio-pl330.h
+
+#include libfdt.h
/*
* internal struct that contains the information to create dynamic
@@ -182,9 +185,90 @@ fail:
return -1;
}
+/**
+ * add_arm_pl330_fdt_node
+ *
+ * Generates a very simple node with following properties:
+ * compatible string, regs, interrupts, clocks, clock-names
+ */
+static int add_arm_pl330_fdt_node(SysBusDevice *sbdev, void *opaque)
+{
+PlatformBusFdtData *data = opaque;
+void *fdt = data-fdt;
+const char *parent_node = data-pbus_node_name;
+int compat_str_len;
+char *nodename;
+int ret;
+uint64_t mmio_base;
+VFIOPlatformDevice *vdev = VFIO_PLATFORM_DEVICE(sbdev);
+VFIODevice *vbasedev = vdev-vbasedev;
+Object *obj = OBJECT(sbdev);
+
+mmio_base = object_property_get_int(obj, mmio[0], NULL);
+
+nodename = g_strdup_printf(%s/%s@% PRIx64, parent_node,
+ vbasedev-name,
+ mmio_base);
+
+qemu_fdt_add_subnode(fdt, nodename);
+
+/*
+ * Process compatible string to deal with multiple strings
+ * (; is replaced by \0)
+ */
+char *compat = g_strdup(vdev-compat);
+compat_str_len = strlen(compat) + 1;
+
+char *semicolon = compat;
+while ((semicolon = strchr(semicolon, ';')) != NULL) {
+*semicolon = '\0';
+}
+
+qemu_fdt_setprop(fdt, nodename, compatible,
+ compat, compat_str_len);
+
+/* Setup clocks for AMBA device */
+/* Check clock existence */
+ret = fdt_path_offset(fdt, /apb-pclk);
+
+if (ret 0) {
+error_report(could not set clocks property of node %s, nodename);
in case apb-clk is not found shouldn't we jump to a fail section?
+} else {
+qemu_fdt_setprop_cells(fdt, nodename, clocks,
+qemu_fdt_getprop_cell(fdt, /apb-pclk, phandle));
+char clock_names[] = apb_pclk;
+qemu_fdt_setprop(fdt, nodename, clock-names, clock_names,
+sizeof(clock_names));
+}
+
+ret = set_regions_fdt_node(nodename, sbdev, opaque);
+
+if (ret 0) {
+error_report(could not set reg property of node %s, nodename);
+goto fail;
+}
+
+ret = set_interrupts_fdt_node(nodename, sbdev, opaque, 0, 0x4);
+
+if (ret 0) {
+error_report(could not set interrupts property of node %s,
+ nodename);
+goto fail;
+}
+
+g_free(nodename);
+
+return 0;
+
+fail:
+
I think we should free nodename too here.
Otherwise, to me, it fits with the original spirit now.
Thanks
Eric
+ return -1;
+}
+
/* list of supported dynamic sysbus devices */
static const NodeCreationPair add_fdt_node_functions[] = {
{TYPE_VFIO_CALXEDA_XGMAC, add_calxeda_midway_xgmac_fdt_node},
+{TYPE_VFIO_PL330, add_arm_pl330_fdt_node},
{, NULL}, /*last element*/
};
diff --git a/hw/vfio/Makefile.objs b/hw/vfio/Makefile.objs
index 913ab14..be3023b 100644
--- a/hw/vfio/Makefile.objs
+++ b/hw/vfio/Makefile.objs
@@ -3,4 +3,5 @@ obj-$(CONFIG_SOFTMMU) += common.o
obj-$(CONFIG_PCI) += pci.o
obj-$(CONFIG_SOFTMMU) += platform.o
obj-$(CONFIG_SOFTMMU) += calxeda_xgmac.o
+obj-$(CONFIG_SOFTMMU) += pl330.o
endif
diff --git a/hw/vfio/pl330.c b/hw/vfio/pl330.c
new file mode 100644
index 000..a409024
--- /dev/null
+++ b/hw/vfio/pl330.c
@@ -0,0 +1,41 @@
+#include hw/vfio/vfio-pl330.h
+
+static void pl330_realize(DeviceState *dev, Error **errp)
+{
+VFIOPlatformDevice *vdev = VFIO_PLATFORM_DEVICE(dev);
+VFIOPl330DeviceClass *k = VFIO_PL330_DEVICE_GET_CLASS(dev);
+
+vdev-compat = g_strdup(arm,pl330;arm,primecell);
+
+k-parent_realize(dev, errp);
+}
+
+static const VMStateDescription vfio_platform_vmstate = {
+.name = TYPE_VFIO_PL330,
+.unmigratable = 1,
+};
+
+static void vfio_pl330_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+VFIOPl330DeviceClass *vpc =
+VFIO_PL330_DEVICE_CLASS(klass);
+vpc-parent_realize = dc-realize;
+
Re: [Qemu-devel] [PATCH 06/15] linux-user/vm86.c: Use cpu_ldl_data c rather than plain ldl c
Peter Maydell peter.mayd...@linaro.org writes:
Use the cpu_ld*_data and cpu_st*_data family of functions to access
guest memory in vm86.c rather than the very short-named ldl/stl functions.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
Reviewed-by: Alex Bennée alex.ben...@linaro.org
---
linux-user/vm86.c | 57
++-
1 file changed, 31 insertions(+), 26 deletions(-)
diff --git a/linux-user/vm86.c b/linux-user/vm86.c
index 45ef559..22a4eb9 100644
--- a/linux-user/vm86.c
+++ b/linux-user/vm86.c
@@ -45,29 +45,34 @@ static inline int is_revectored(int nr, struct
target_revectored_struct *bitmap)
return (((uint8_t *)bitmap)[nr 3] (nr 7)) 1;
}
-static inline void vm_putw(uint32_t segptr, unsigned int reg16, unsigned int
val)
+static inline void vm_putw(CPUX86State *env, uint32_t segptr,
+ unsigned int reg16, unsigned int val)
{
-stw(segptr + (reg16 0x), val);
+cpu_stw_data(env, segptr + (reg16 0x), val);
}
-static inline void vm_putl(uint32_t segptr, unsigned int reg16, unsigned int
val)
+static inline void vm_putl(CPUX86State *env, uint32_t segptr,
+ unsigned int reg16, unsigned int val)
{
-stl(segptr + (reg16 0x), val);
+cpu_stl_data(env, segptr + (reg16 0x), val);
}
-static inline unsigned int vm_getb(uint32_t segptr, unsigned int reg16)
+static inline unsigned int vm_getb(CPUX86State *env,
+ uint32_t segptr, unsigned int reg16)
{
-return ldub(segptr + (reg16 0x));
+return cpu_ldub_data(env, segptr + (reg16 0x));
}
-static inline unsigned int vm_getw(uint32_t segptr, unsigned int reg16)
+static inline unsigned int vm_getw(CPUX86State *env,
+ uint32_t segptr, unsigned int reg16)
{
-return lduw(segptr + (reg16 0x));
+return cpu_lduw_data(env, segptr + (reg16 0x));
}
-static inline unsigned int vm_getl(uint32_t segptr, unsigned int reg16)
+static inline unsigned int vm_getl(CPUX86State *env,
+ uint32_t segptr, unsigned int reg16)
{
-return ldl(segptr + (reg16 0x));
+return cpu_ldl_data(env, segptr + (reg16 0x));
}
void save_v86_state(CPUX86State *env)
@@ -221,7 +226,7 @@ static void do_int(CPUX86State *env, int intno)
ts-vm86plus.int21_revectored))
goto cannot_handle;
int_addr = (intno 2);
-segoffs = ldl(int_addr);
+segoffs = cpu_ldl_data(env, int_addr);
if ((segoffs 16) == TARGET_BIOSSEG)
goto cannot_handle;
LOG_VM86(VM86: emulating int 0x%x. CS:IP=%04x:%04x\n,
@@ -229,9 +234,9 @@ static void do_int(CPUX86State *env, int intno)
/* save old state */
ssp = env-segs[R_SS].selector 4;
sp = env-regs[R_ESP] 0x;
-vm_putw(ssp, sp - 2, get_vflags(env));
-vm_putw(ssp, sp - 4, env-segs[R_CS].selector);
-vm_putw(ssp, sp - 6, env-eip);
+vm_putw(env, ssp, sp - 2, get_vflags(env));
+vm_putw(env, ssp, sp - 4, env-segs[R_CS].selector);
+vm_putw(env, ssp, sp - 6, env-eip);
ADD16(env-regs[R_ESP], -6);
/* goto interrupt handler */
env-eip = segoffs 0x;
@@ -285,7 +290,7 @@ void handle_vm86_fault(CPUX86State *env)
data32 = 0;
pref_done = 0;
do {
-opcode = vm_getb(csp, ip);
+opcode = vm_getb(env, csp, ip);
ADD16(ip, 1);
switch (opcode) {
case 0x66: /* 32-bit data */ data32=1; break;
@@ -306,10 +311,10 @@ void handle_vm86_fault(CPUX86State *env)
switch(opcode) {
case 0x9c: /* pushf */
if (data32) {
-vm_putl(ssp, sp - 4, get_vflags(env));
+vm_putl(env, ssp, sp - 4, get_vflags(env));
ADD16(env-regs[R_ESP], -4);
} else {
-vm_putw(ssp, sp - 2, get_vflags(env));
+vm_putw(env, ssp, sp - 2, get_vflags(env));
ADD16(env-regs[R_ESP], -2);
}
env-eip = ip;
@@ -317,10 +322,10 @@ void handle_vm86_fault(CPUX86State *env)
case 0x9d: /* popf */
if (data32) {
-newflags = vm_getl(ssp, sp);
+newflags = vm_getl(env, ssp, sp);
ADD16(env-regs[R_ESP], 4);
} else {
-newflags = vm_getw(ssp, sp);
+newflags = vm_getw(env, ssp, sp);
ADD16(env-regs[R_ESP], 2);
}
env-eip = ip;
@@ -335,7 +340,7 @@ void handle_vm86_fault(CPUX86State *env)
VM86_FAULT_RETURN;
case 0xcd: /* int */
-intno = vm_getb(csp, ip);
+intno = vm_getb(env, csp, ip);
ADD16(ip, 1);
env-eip = ip;
if (ts-vm86plus.vm86plus.flags TARGET_vm86dbg_active) {
@@ -350,14 +355,14 @@ void handle_vm86_fault(CPUX86State *env)
case 0xcf: /*
Re: [Qemu-devel] [PATCH] qemu-iotests: Fix supported_oses check
On Thu, Jan 15, 2015 at 01:44:34PM +0800, Fam Zheng wrote:
There is a bug in the recently added sys.platform test and we no longer
run python tests, because linux2 is the value to compare here. So do a
prefix match, although the python documentation claims Linux is always
linux2.
It would be good to mention that the docs explicitly suggest using
startswith().
When reviewing this I wasn't sure whether the startswith() comparison is
safe, but knowing the Python docs suggest it means I can be sure this
patch is correct.
Signed-off-by: Fam Zheng f...@redhat.com
---
tests/qemu-iotests/iotests.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
index 87002e0..4011725 100644
--- a/tests/qemu-iotests/iotests.py
+++ b/tests/qemu-iotests/iotests.py
@@ -288,7 +288,7 @@ def main(supported_fmts=[], supported_oses=['linux']):
if supported_fmts and (imgfmt not in supported_fmts):
notrun('not suitable for this image format: %s' % imgfmt)
-if sys.platform not in supported_oses:
+if not any([sys.platform.startswith(x) for x in supported_oses]):
notrun('not suitable for this OS: %s' % sys.platform)
Please don't use any(), we've avoided it to stay compatible with old
Python interpreters:
if True not in [sys.platform.startswith(x) for x in supported_oses]:
pgpdqF8oBJNJM.pgp
Description: PGP signature
Re: [Qemu-devel] [v3 4/5] Qemu-Xen-vTPM: Qemu vTPM xenstubdoms backen.
On 12/30/2014 06:03 PM, Quan Xu wrote:
This Patch provides the glue for the TPM_TIS(Qemu frontend) to Xen
stubdom vTPM domain that provides the actual TPM functionality. It
sends data and TPM commends with xen_vtpm_frontend. It is similar as
another two vTPM backens:
*vTPM passthrough backen Since QEMU 1.5.
*vTPM libtpms-based backen.
Some details:
This part of the patch provides support for the spawning of a thread
that will interact with stubdom vTPM domain by the xen_vtpm_frontend.
It expects a signal from the frontend to wake and pick up the TPM
command that is supposed to be processed and delivers the response
packet using a callback function provided by the frontend.
The backend connects itself to the frontend by filling out an interface
structure with pointers to the function implementing support for various
operations.
(QEMU) vTPM XenStubdoms backen is initialized by Qemu command line options,
-tpmdev xenstubdoms,id=xenvtpm0 -device tpm-tis,tpmdev=xenvtpm0
--Changes in v3:
-Call vtpm_send() and vtpm_recv() directly.
Signed-off-by: Quan Xu quan...@intel.com
---
hw/tpm/Makefile.objs | 2 +-
hw/tpm/tpm_xenstubdoms.c | 245 +++
2 files changed, 246 insertions(+), 1 deletion(-)
create mode 100644 hw/tpm/tpm_xenstubdoms.c
diff --git a/hw/tpm/Makefile.objs b/hw/tpm/Makefile.objs
index 57919fa..190e776 100644
--- a/hw/tpm/Makefile.objs
+++ b/hw/tpm/Makefile.objs
@@ -1,3 +1,3 @@
common-obj-$(CONFIG_TPM_TIS) += tpm_tis.o
common-obj-$(CONFIG_TPM_PASSTHROUGH) += tpm_passthrough.o
-common-obj-$(CONFIG_TPM_XENSTUBDOMS) += xen_vtpm_frontend.o
+common-obj-$(CONFIG_TPM_XENSTUBDOMS) += tpm_xenstubdoms.o xen_vtpm_frontend.o
diff --git a/hw/tpm/tpm_xenstubdoms.c b/hw/tpm/tpm_xenstubdoms.c
new file mode 100644
index 000..98ea496
--- /dev/null
+++ b/hw/tpm/tpm_xenstubdoms.c
@@ -0,0 +1,245 @@
+/*
+ * Xen Stubdom vTPM driver
+ *
+ * Copyright (c) 2014 Intel Corporation
+ * Authors:
+ *Quan Xu quan...@intel.com
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see http://www.gnu.org/licenses/
+ */
+
+#include dirent.h
+#include qemu-common.h
+#include qapi/error.h
+#include qemu/sockets.h
+#include qemu/log.h
+#include sysemu/tpm_backend.h
+#include tpm_int.h
+#include hw/hw.h
+#include hw/i386/pc.h
+#include hw/xen/xen_backend.h
+#include sysemu/tpm_backend_int.h
+#include tpm_tis.h
+
+#ifdef DEBUG_TPM
+#define DPRINTF(fmt, ...) \
+do { fprintf(stderr, fmt, ## __VA_ARGS__); } while (0)
+#else
+#define DPRINTF(fmt, ...) \
+do { } while (0)
+#endif
+
+#define TYPE_TPM_XENSTUBDOMS tpm-xenstubdoms
+#define TPM_XENSTUBDOMS(obj) \
+OBJECT_CHECK(TPMXenstubdomsState, (obj), TYPE_TPM_XENSTUBDOMS)
+
+static const TPMDriverOps tpm_xenstubdoms_driver;
+
+/* data structures */
+typedef struct TPMXenstubdomsThreadParams {
+TPMState *tpm_state;
+TPMRecvDataCB *recv_data_callback;
+TPMBackend *tb;
+} TPMXenstubdomsThreadParams;
+
+struct TPMXenstubdomsState {
+TPMBackend parent;
+TPMBackendThread tbt;
+TPMXenstubdomsThreadParams tpm_thread_params;
+bool had_startup_error;
+};
+
+typedef struct TPMXenstubdomsState TPMXenstubdomsState;
+
+/* functions */
+
+static void tpm_xenstubdoms_cancel_cmd(TPMBackend *tb);
+
+static int tpm_xenstubdoms_unix_transfer(const TPMLocality *locty_data)
+{
+size_t rlen;
+struct XenDevice *xendev;
+
+xendev = xen_be_find_xendev(vtpm, xen_domid, 0);
+if (xendev == NULL) {
+xen_be_printf(xendev, 0, Con not find vtpm device\n);
+return -1;
+}
+vtpm_send(xendev, locty_data-w_buffer.buffer, locty_data-w_offset);
+vtpm_recv(xendev, locty_data-r_buffer.buffer, rlen);
+return 0;
+}
+
+static void tpm_xenstubdoms_worker_thread(gpointer data,
+ gpointer user_data)
+{
+TPMXenstubdomsThreadParams *thr_parms = user_data;
+TPMBackendCmd cmd = (TPMBackendCmd)data;
+
+switch (cmd) {
+case TPM_BACKEND_CMD_PROCESS_CMD:
+/* here need a the cmd process function */
+tpm_xenstubdoms_unix_transfer(thr_parms-tpm_state-locty_data);
+thr_parms-recv_data_callback(thr_parms-tpm_state,
+ thr_parms-tpm_state-locty_number);
+break;
+case TPM_BACKEND_CMD_INIT:
+case TPM_BACKEND_CMD_END:
+case TPM_BACKEND_CMD_TPM_RESET:
+/* nothing to
Re: [Qemu-devel] [PATCH 05/15] bsd-user/elfload.c: Don't use ldl() or ldq_raw()
Peter Maydell peter.mayd...@linaro.org writes:
Use get_user_u64() and get_user_ual() instead of the ldl() and
ldq_raw() functions.
[Note that this change is not compile tested as it is actually
in dead code -- none of the bsd-user configurations are PPC.]
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
Reviewed-by: Alex Bennée alex.ben...@linaro.org
---
bsd-user/elfload.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/bsd-user/elfload.c b/bsd-user/elfload.c
index 93fd9e4..2bf57eb 100644
--- a/bsd-user/elfload.c
+++ b/bsd-user/elfload.c
@@ -351,8 +351,10 @@ static inline void init_thread(struct target_pt_regs
*_regs, struct image_info *
_regs-gpr[1] = infop-start_stack;
#if defined(TARGET_PPC64) !defined(TARGET_ABI32)
-entry = ldq_raw(infop-entry) + infop-load_addr;
-toc = ldq_raw(infop-entry + 8) + infop-load_addr;
+get_user_u64(entry, infop-entry);
+entry += infop-load_addr;
+get_user_u64(toc, infop-entry + 8);
+toc += infop-load_addr;
_regs-gpr[2] = toc;
infop-entry = entry;
#endif
@@ -365,8 +367,9 @@ static inline void init_thread(struct target_pt_regs
*_regs, struct image_info *
get_user_ual(_regs-gpr[3], pos);
pos += sizeof(abi_ulong);
_regs-gpr[4] = pos;
-for (tmp = 1; tmp != 0; pos += sizeof(abi_ulong))
-tmp = ldl(pos);
+for (tmp = 1; tmp != 0; pos += sizeof(abi_ulong)) {
+get_user_ual(tmp, pos);
+}
_regs-gpr[5] = pos;
}
--
Alex Bennée
[Qemu-devel] [PATCH 03/15] target-sparc: Don't use {ld, st}*_raw functions
Instead of using the _raw family of ld/st accessor functions, use
cpu_*_data. All this code is CONFIG_USER_ONLY, so the two are the
same semantically, but the _raw functions are really a detail of
the implementation which has leaked into a few callsites like this one.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
target-sparc/ldst_helper.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/target-sparc/ldst_helper.c b/target-sparc/ldst_helper.c
index 1a62e19..e62228c 100644
--- a/target-sparc/ldst_helper.c
+++ b/target-sparc/ldst_helper.c
@@ -1122,17 +1122,17 @@ uint64_t helper_ld_asi(CPUSPARCState *env, target_ulong
addr, int asi, int size,
{
switch (size) {
case 1:
-ret = ldub_raw(addr);
+ret = cpu_ldub_data(env, addr);
break;
case 2:
-ret = lduw_raw(addr);
+ret = cpu_lduw_data(env, addr);
break;
case 4:
-ret = ldl_raw(addr);
+ret = cpu_ldl_data(env, addr);
break;
default:
case 8:
-ret = ldq_raw(addr);
+ret = cpu_ldq_data(env, addr);
break;
}
}
@@ -1239,17 +1239,17 @@ void helper_st_asi(CPUSPARCState *env, target_ulong
addr, target_ulong val,
{
switch (size) {
case 1:
-stb_raw(addr, val);
+cpu_stb_data(env, addr, val);
break;
case 2:
-stw_raw(addr, val);
+cpu_stw_data(env, addr, val);
break;
case 4:
-stl_raw(addr, val);
+cpu_stl_data(env, addr, val);
break;
case 8:
default:
-stq_raw(addr, val);
+cpu_stq_data(env, addr, val);
break;
}
}
@@ -2289,8 +2289,8 @@ void helper_ldqf(CPUSPARCState *env, target_ulong addr,
int mem_idx)
break;
}
#else
-u.ll.upper = ldq_raw(address_mask(env, addr));
-u.ll.lower = ldq_raw(address_mask(env, addr + 8));
+u.ll.upper = cpu_ldq_data(env, address_mask(env, addr));
+u.ll.lower = cpu_ldq_data(env, address_mask(env, addr + 8));
QT0 = u.q;
#endif
}
@@ -2326,8 +2326,8 @@ void helper_stqf(CPUSPARCState *env, target_ulong addr,
int mem_idx)
}
#else
u.q = QT0;
-stq_raw(address_mask(env, addr), u.ll.upper);
-stq_raw(address_mask(env, addr + 8), u.ll.lower);
+cpu_stq_data(env, address_mask(env, addr), u.ll.upper);
+cpu_stq_data(env, address_mask(env, addr + 8), u.ll.lower);
#endif
}
--
1.9.1
[Qemu-devel] [PATCH 09/15] cpu_ldst.h: Drop unused ld/st*_kernel defines
The ld*_kernel and st*_kernel defines are not used anywhere; delete them. Signed-off-by: Peter Maydell peter.mayd...@linaro.org --- include/exec/cpu_ldst.h | 15 --- 1 file changed, 15 deletions(-) diff --git a/include/exec/cpu_ldst.h b/include/exec/cpu_ldst.h index 4700831..64d9087 100644 --- a/include/exec/cpu_ldst.h +++ b/include/exec/cpu_ldst.h @@ -126,21 +126,6 @@ #define cpu_stl_kernel(env, addr, data) stl_raw(addr, data) #define cpu_stq_kernel(env, addr, data) stq_raw(addr, data) -#define ldub_kernel(p) ldub_raw(p) -#define ldsb_kernel(p) ldsb_raw(p) -#define lduw_kernel(p) lduw_raw(p) -#define ldsw_kernel(p) ldsw_raw(p) -#define ldl_kernel(p) ldl_raw(p) -#define ldq_kernel(p) ldq_raw(p) -#define ldfl_kernel(p) ldfl_raw(p) -#define ldfq_kernel(p) ldfq_raw(p) -#define stb_kernel(p, v) stb_raw(p, v) -#define stw_kernel(p, v) stw_raw(p, v) -#define stl_kernel(p, v) stl_raw(p, v) -#define stq_kernel(p, v) stq_raw(p, v) -#define stfl_kernel(p, v) stfl_raw(p, v) -#define stfq_kernel(p, vt) stfq_raw(p, v) - #define cpu_ldub_data(env, addr) ldub_raw(addr) #define cpu_lduw_data(env, addr) lduw_raw(addr) #define cpu_ldl_data(env, addr) ldl_raw(addr) -- 1.9.1
Re: [Qemu-devel] [PATCH] WIP: add GCoroutine support
Am 09.01.2015 um 18:19 hat Marc-André Lureau geschrieben: Learn to use the GCoroutine library instead of qemu own coroutine implementation. GCoroutine is hosted on github: https://github.com/elmarco/gcoroutine This allows to share the same coroutine implementation between various projects (gtk-vnc and spice-gtk). It is related to the effort to push coroutine support in GLib. See also: https://bugzilla.gnome.org/show_bug.cgi?id=719362 Hm, I guess there might be uses for holding references after the coroutine has exited if there are external references to the coroutine, but is it useful not to drop one reference after the coroutine exits? I guess in most cases, and in qemu always, the caller isn't aware that the coroutine ended, so requiring an explicit call isn't as nice as it could be. Also, you modified the copyright lines. Would you mind restoring the author names as in the original code, as their license requires? I see that you also converted MIT licensed code into LGPL, without keeping the original license text as required. For my code, I'm fine with the conversion, but you should either have asked or left the original text in place. Kevin
[Qemu-devel] [PATCH 11/15] cpu_ldst.h: Use inline functions for usermode cpu_ld/st accessors
Use inline functions rather than macros for cpu_ld/st accessors for the *-user configurations, as we already do for softmmu. This has a two advantages: * we can actually typecheck our arguments * we don't need to leak the _raw macros everywhere Since the _kernel functions were only used by target-i386/seg_helper.c, put the definitions for them in that file too. (It already has the similar template include code to define them for the softmmu case, so it makes sense to have it deal with defining them for user-only.) Signed-off-by: Peter Maydell peter.mayd...@linaro.org --- include/exec/cpu_ldst.h | 70 -- include/exec/cpu_ldst_useronly_template.h | 81 +++ target-i386/seg_helper.c | 16 +- 3 files changed, 127 insertions(+), 40 deletions(-) create mode 100644 include/exec/cpu_ldst_useronly_template.h diff --git a/include/exec/cpu_ldst.h b/include/exec/cpu_ldst.h index 2dc4775..bef2e5f 100644 --- a/include/exec/cpu_ldst.h +++ b/include/exec/cpu_ldst.h @@ -78,47 +78,39 @@ #define stfl_raw(p, v) stfl_p(saddr((p)), v) #define stfq_raw(p, v) stfq_p(saddr((p)), v) - #if defined(CONFIG_USER_ONLY) -/* if user mode, no other memory access functions */ - -#define cpu_ldub_code(env1, p) ldub_raw(p) -#define cpu_ldsb_code(env1, p) ldsb_raw(p) -#define cpu_lduw_code(env1, p) lduw_raw(p) -#define cpu_ldsw_code(env1, p) ldsw_raw(p) -#define cpu_ldl_code(env1, p) ldl_raw(p) -#define cpu_ldq_code(env1, p) ldq_raw(p) - -#define cpu_ldub_data(env, addr) ldub_raw(addr) -#define cpu_lduw_data(env, addr) lduw_raw(addr) -#define cpu_ldsw_data(env, addr) ldsw_raw(addr) -#define cpu_ldl_data(env, addr) ldl_raw(addr) -#define cpu_ldq_data(env, addr) ldq_raw(addr) - -#define cpu_stb_data(env, addr, data) stb_raw(addr, data) -#define cpu_stw_data(env, addr, data) stw_raw(addr, data) -#define cpu_stl_data(env, addr, data) stl_raw(addr, data) -#define cpu_stq_data(env, addr, data) stq_raw(addr, data) - -#define cpu_ldub_kernel(env, addr) ldub_raw(addr) -#define cpu_lduw_kernel(env, addr) lduw_raw(addr) -#define cpu_ldsw_kernel(env, addr) ldsw_raw(addr) -#define cpu_ldl_kernel(env, addr) ldl_raw(addr) -#define cpu_ldq_kernel(env, addr) ldq_raw(addr) - -#define cpu_stb_kernel(env, addr, data) stb_raw(addr, data) -#define cpu_stw_kernel(env, addr, data) stw_raw(addr, data) -#define cpu_stl_kernel(env, addr, data) stl_raw(addr, data) -#define cpu_stq_kernel(env, addr, data) stq_raw(addr, data) - -#define cpu_ldub_data(env, addr) ldub_raw(addr) -#define cpu_lduw_data(env, addr) lduw_raw(addr) -#define cpu_ldl_data(env, addr) ldl_raw(addr) - -#define cpu_stb_data(env, addr, data) stb_raw(addr, data) -#define cpu_stw_data(env, addr, data) stw_raw(addr, data) -#define cpu_stl_data(env, addr, data) stl_raw(addr, data) +/* In user-only mode we provide only the _code and _data accessors. */ + +#define MEMSUFFIX _data +#define DATA_SIZE 1 +#include exec/cpu_ldst_useronly_template.h + +#define DATA_SIZE 2 +#include exec/cpu_ldst_useronly_template.h + +#define DATA_SIZE 4 +#include exec/cpu_ldst_useronly_template.h + +#define DATA_SIZE 8 +#include exec/cpu_ldst_useronly_template.h +#undef MEMSUFFIX + +#define MEMSUFFIX _code +#define CODE_ACCESS +#define DATA_SIZE 1 +#include exec/cpu_ldst_useronly_template.h + +#define DATA_SIZE 2 +#include exec/cpu_ldst_useronly_template.h + +#define DATA_SIZE 4 +#include exec/cpu_ldst_useronly_template.h + +#define DATA_SIZE 8 +#include exec/cpu_ldst_useronly_template.h +#undef MEMSUFFIX +#undef CODE_ACCESS #else diff --git a/include/exec/cpu_ldst_useronly_template.h b/include/exec/cpu_ldst_useronly_template.h new file mode 100644 index 000..b3b865f --- /dev/null +++ b/include/exec/cpu_ldst_useronly_template.h @@ -0,0 +1,81 @@ +/* + * User-only accessor function support + * + * Generate inline load/store functions for one data size. + * + * Generate a store function as well as signed and unsigned loads. + * + * Not used directly but included from cpu_ldst.h. + * + * Copyright (c) 2015 Linaro Limited + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, see http://www.gnu.org/licenses/. + */ +#if DATA_SIZE == 8 +#define SUFFIX q +#define USUFFIX q +#define DATA_TYPE uint64_t +#elif DATA_SIZE == 4 +#define SUFFIX l +#define USUFFIX l +#define DATA_TYPE uint32_t +#elif DATA_SIZE == 2 +#define SUFFIX w +#define USUFFIX uw
[Qemu-devel] [PATCH 13/15] cpu_ldst.h: Drop unused _raw macros, saddr() and laddr()
The _raw macros and their helpers saddr() and laddr() are now totally unused -- delete them. Signed-off-by: Peter Maydell peter.mayd...@linaro.org --- include/exec/cpu_ldst.h | 23 --- 1 file changed, 23 deletions(-) diff --git a/include/exec/cpu_ldst.h b/include/exec/cpu_ldst.h index bef2e5f..16f4e30 100644 --- a/include/exec/cpu_ldst.h +++ b/include/exec/cpu_ldst.h @@ -53,31 +53,8 @@ h2g_nocheck(x); \ }) -#define saddr(x) g2h(x) -#define laddr(x) g2h(x) - -#else /* !CONFIG_USER_ONLY */ -/* NOTE: we use double casts if pointers and target_ulong have - different sizes */ -#define saddr(x) (uint8_t *)(intptr_t)(x) -#define laddr(x) (uint8_t *)(intptr_t)(x) #endif -#define ldub_raw(p) ldub_p(laddr((p))) -#define ldsb_raw(p) ldsb_p(laddr((p))) -#define lduw_raw(p) lduw_p(laddr((p))) -#define ldsw_raw(p) ldsw_p(laddr((p))) -#define ldl_raw(p) ldl_p(laddr((p))) -#define ldq_raw(p) ldq_p(laddr((p))) -#define ldfl_raw(p) ldfl_p(laddr((p))) -#define ldfq_raw(p) ldfq_p(laddr((p))) -#define stb_raw(p, v) stb_p(saddr((p)), v) -#define stw_raw(p, v) stw_p(saddr((p)), v) -#define stl_raw(p, v) stl_p(saddr((p)), v) -#define stq_raw(p, v) stq_p(saddr((p)), v) -#define stfl_raw(p, v) stfl_p(saddr((p)), v) -#define stfq_raw(p, v) stfq_p(saddr((p)), v) - #if defined(CONFIG_USER_ONLY) /* In user-only mode we provide only the _code and _data accessors. */ -- 1.9.1
[Qemu-devel] [PATCH 14/15] cpu_ldst_template.h: Drop unused cpu_ldfq/stfq/ldfl/stfl accessors
The cpu_ldfq/stfq/ldfl/stfl accessors for loading and storing
float32 and float64 are completely unused, so delete them.
(The union they use for converting from the float32/float64
type to uint32_t or uint64_t is the wrong way to do it anyway:
they should be using make_float* and float*_val.)
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
include/exec/cpu_ldst_template.h | 54 +---
1 file changed, 1 insertion(+), 53 deletions(-)
diff --git a/include/exec/cpu_ldst_template.h b/include/exec/cpu_ldst_template.h
index 3b53605..95ab750 100644
--- a/include/exec/cpu_ldst_template.h
+++ b/include/exec/cpu_ldst_template.h
@@ -4,9 +4,7 @@
* Generate inline load/store functions for one MMU mode and data
* size.
*
- * Generate a store function as well as signed and unsigned loads. For
- * 32 and 64 bit cases, also generate floating point functions with
- * the same size.
+ * Generate a store function as well as signed and unsigned loads.
*
* Not used directly but included from cpu_ldst.h.
*
@@ -131,56 +129,6 @@ glue(glue(cpu_st, SUFFIX), MEMSUFFIX)(CPUArchState *env,
target_ulong ptr,
}
}
-
-
-#if DATA_SIZE == 8
-static inline float64 glue(cpu_ldfq, MEMSUFFIX)(CPUArchState *env,
-target_ulong ptr)
-{
-union {
-float64 d;
-uint64_t i;
-} u;
-u.i = glue(cpu_ldq, MEMSUFFIX)(env, ptr);
-return u.d;
-}
-
-static inline void glue(cpu_stfq, MEMSUFFIX)(CPUArchState *env,
- target_ulong ptr, float64 v)
-{
-union {
-float64 d;
-uint64_t i;
-} u;
-u.d = v;
-glue(cpu_stq, MEMSUFFIX)(env, ptr, u.i);
-}
-#endif /* DATA_SIZE == 8 */
-
-#if DATA_SIZE == 4
-static inline float32 glue(cpu_ldfl, MEMSUFFIX)(CPUArchState *env,
-target_ulong ptr)
-{
-union {
-float32 f;
-uint32_t i;
-} u;
-u.i = glue(cpu_ldl, MEMSUFFIX)(env, ptr);
-return u.f;
-}
-
-static inline void glue(cpu_stfl, MEMSUFFIX)(CPUArchState *env,
- target_ulong ptr, float32 v)
-{
-union {
-float32 f;
-uint32_t i;
-} u;
-u.f = v;
-glue(cpu_stl, MEMSUFFIX)(env, ptr, u.i);
-}
-#endif /* DATA_SIZE == 4 */
-
#endif /* !SOFTMMU_CODE_ACCESS */
#undef RES_TYPE
--
1.9.1
[Qemu-devel] [PATCH 01/15] cpu_ldst.h: Remove unused ldul_ macros
The five ldul_ macros are not used anywhere and are marked up with an XXX comment. ldul is a non-standard prefix for our family of load instructions: we don't mark 32-bit accesses for signedness because they return a 32 bit quantity. So just delete them. Signed-off-by: Peter Maydell peter.mayd...@linaro.org Reviewed-by: Paolo Bonzini pbonz...@redhat.com --- include/exec/cpu_ldst.h | 9 - 1 file changed, 9 deletions(-) diff --git a/include/exec/cpu_ldst.h b/include/exec/cpu_ldst.h index e5550e7..4700831 100644 --- a/include/exec/cpu_ldst.h +++ b/include/exec/cpu_ldst.h @@ -151,15 +151,6 @@ #else -/* XXX: find something cleaner. - * Furthermore, this is false for 64 bits targets - */ -#define ldul_user ldl_user -#define ldul_kernel ldl_kernel -#define ldul_hypv ldl_hypv -#define ldul_executive ldl_executive -#define ldul_supervisor ldl_supervisor - /* The memory helpers for tcg-generated code need tcg_target_long etc. */ #include tcg.h -- 1.9.1
[Qemu-devel] [PATCH 02/15] monitor.c: Use ld*_p() instead of ld*_raw()
The monitor code for doing a memory_dump() was using ld*_raw() to do
target-CPU accesses out of a local buf[] array. The correct functions
for this purpose are ld*_p(), which take a host pointer, rather than
ld*_raw(), which take an integer representing a guest address and
are somewhat meaningless in softmmu configurations. Nobody noticed
because for softmmu the _raw functions are the same as ldl_p but
with some extra casts thrown in. Switch to using the correct functions
instead.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
monitor.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/monitor.c b/monitor.c
index 1808e41..7e4f605 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1292,16 +1292,16 @@ static void memory_dump(Monitor *mon, int count, int
format, int wsize,
switch(wsize) {
default:
case 1:
-v = ldub_raw(buf + i);
+v = ldub_p(buf + i);
break;
case 2:
-v = lduw_raw(buf + i);
+v = lduw_p(buf + i);
break;
case 4:
-v = (uint32_t)ldl_raw(buf + i);
+v = (uint32_t)ldl_p(buf + i);
break;
case 8:
-v = ldq_raw(buf + i);
+v = ldq_p(buf + i);
break;
}
monitor_printf(mon, );
--
1.9.1
[Qemu-devel] [PATCH 04/15] linux-user/elfload.c: Don't use _raw accessor functions
The _raw accessor functions are an implementation detail that has
leaked out to some callsites. Use get_user_u64() instead of ldq_raw().
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
linux-user/elfload.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index e2596a4..399c021 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -829,8 +829,11 @@ static inline void init_thread(struct target_pt_regs
*_regs, struct image_info *
_regs-gpr[1] = infop-start_stack;
#if defined(TARGET_PPC64) !defined(TARGET_ABI32)
if (get_ppc64_abi(infop) 2) {
-_regs-gpr[2] = ldq_raw(infop-entry + 8) + infop-load_bias;
-infop-entry = ldq_raw(infop-entry) + infop-load_bias;
+uint64_t val;
+get_user_u64(val, infop-entry + 8);
+_regs-gpr[2] = val + infop-load_bias;
+get_user_u64(val, infop-entry);
+infop-entry = val + infop-load_bias;
} else {
_regs-gpr[12] = infop-entry; /* r12 set to global entry address */
}
--
1.9.1
Re: [Qemu-devel] Help for beginner
On Tue, Jan 13, 2015 at 10:40:01AM +0900, Ady Wahyudi Paundu wrote: Hi all, Happy New Year (not too late I hope) I also hope you guys don't' mind to be bothered by newbie questions related to Qemu, because I really don't know where else to ask. I want to learn how several aspects of qemu works, and it really hard to find resources (physical or virtual) about it. From qemu documentation QEMU does not have a high level design description document - only the source code tells the full story My question, if i want to learn CPU and/or Network related operation within Qemu, what file (or function) should i put my focus into? for example, simple ping operation from within a guest VM will use what functions? Assuming you run qemu-system-x86_64 the default network card is an emulated Intel e1000 NIC. See hw/net/e1000.c:start_xmit() for the function that emulates packet transmission. It loops over the transmit descriptor ring and send off each packet that the guest has enqueued using qemu_send_packet(). qemu_send_packet() is a QEMU network subsystem API that passes the packet to a host network device (for example, -netdev tap). What happens next depends on which netdev the user launched QEMU with (the default is 'user'). The most popular netdev in production is tap. Look at net/tap.c:tap_receive() to see how QEMU writes the guest's packet to the tap device on the host. The tap driver in the host kernel will then receive the packet from the guest and process it further (often the user has configured a software bridge device so the packet will be forwarded onto the host's physical NIC). Just to recap the structure is: guest - emulated e1000 NIC - tap netdev - host kernel Use tcpdump in the guest or host, or add printfs to QEMU if you want to follow traffic further. Good luck, Stefan pgp2j9QMfyUUW.pgp Description: PGP signature
Re: [Qemu-devel] [PATCH 00/15] Clean up cpu-ldst ld/st memory accessors
Peter Maydell writes:
I was looking at our confusing mess of memory accessor functions,
and I realised that partly it was confusing because we have a
bunch of unnecessary junk lurking in there :-) This series
attempts to clean things up by removing things we weren't using
at all or were only using by mistake in a few places:
* ldul_*: not used
* ld* (ldl, etc): hardly used
* ld*_kernel: not used
* ld*_raw: hardly used
* cpu_{ld,st}{fq,fl}: not used
The dull parts of this series are removing the unused macros
and fixing uses of the hardly-used macros so those can be
deleted too. This series also switches to using inline functions
rather than macros for the user-only cpu_ld/st* accessors, bringing
them into line with the softmmu configs. This has the nice
side effect of letting us get rid of the _raw accessor macros too.
I've also thrown in a commit which cleans up the doc comments.
I haven't reviewed the patches, but that's a much appreciated cleanup! I was
also trying to make sense of all the variants while implementing guest memory
access tracing (let's see if I can find some time to polish and post the
series).
Thanks!
Lluis
--
And it's much the same thing with knowledge, for whenever you learn
something new, the whole world becomes that much richer.
-- The Princess of Pure Reason, as told by Norton Juster in The Phantom
Tollbooth
Re: [Qemu-devel] [PATCH v3 4/5] Split the QEMU buffered file code out
On 12/18/2014 04:24 AM, Dr. David Alan Gilbert wrote: * David Gibson (da...@gibson.dropbear.id.au) wrote: On Fri, Dec 12, 2014 at 11:13:41AM +, Dr. David Alan Gilbert (git) wrote: From: Dr. David Alan Gilbert dgilb...@redhat.com The splitting of qemu-file and addition of the buffered file landed at the same time; so now split the buffered file code out. Signed-off-by: Dr. David Alan Gilbert dgilb...@redhat.com --- migration/Makefile.objs | 2 +- migration/qemu-file-buf.c | 486 ++ migration/qemu-file.c | 455 --- tests/Makefile| 3 +- 4 files changed, 489 insertions(+), 457 deletions(-) create mode 100644 migration/qemu-file-buf.c diff --git a/migration/Makefile.objs b/migration/Makefile.objs index ce1e3c7..d929e96 100644 --- a/migration/Makefile.objs +++ b/migration/Makefile.objs @@ -1,6 +1,6 @@ common-obj-y += migration.o tcp.o common-obj-y += vmstate.o -common-obj-y += qemu-file.o qemu-file-unix.o qemu-file-stdio.o +common-obj-y += qemu-file.o qemu-file-buf.o qemu-file-unix.o qemu-file-stdio.o common-obj-y += xbzrle.o common-obj-$(CONFIG_RDMA) += rdma.o diff --git a/migration/qemu-file-buf.c b/migration/qemu-file-buf.c new file mode 100644 index 000..d33dd44 --- /dev/null +++ b/migration/qemu-file-buf.c @@ -0,0 +1,486 @@ +/* + * QEMU System Emulator + * + * Copyright (c) 2003-2008 Fabrice Bellard Bit hard to believe that only Fabrice listed on this file is correct, given the buffered file stuff is fairly new. Yes, I'd be happy to add Stefan and Joel's name to that, although they never added it in their original patch, and when splitting files we do normally take the copyright header from what we split out of; but you are right it's misleading. I'll add IBM as an additional copyright holder to the qemu-file-buf.c and myself as an author. Whoever else wants to be added as an author, either let me know or submit a patch. Stefan
Re: [Qemu-devel] [PATCH v2 1/2] configure: Default to enable module build
On Tue, Jan 13, 2015 at 04:53:58PM +0800, Fam Zheng wrote:
We have module build support around for a while, but also had it bitrot
several times. It probably makes sense to enable it by default so that
people can notice and use it.
Counterpart to --enable-modules, which is turned as default,
--disable-modules is added to suppress it. If both are omitted, the
support is guesses as usual.
Add --disable-modules as a counterpart to --enable-modules, which is
now turned on by default. If both are omitted, support is guessed as
usual.
Signed-off-by: Fam Zheng f...@redhat.com
---
configure | 95
---
1 file changed, 66 insertions(+), 29 deletions(-)
diff --git a/configure b/configure
index 7539645..8280e8a 100755
--- a/configure
+++ b/configure
@@ -271,7 +271,7 @@ gcov_tool=gcov
EXESUF=
DSOSUF=.so
LDFLAGS_SHARED=-shared
-modules=no
+modules=
prefix=/usr/local
mandir=\${prefix}/share/man
datadir=\${prefix}/share
@@ -768,6 +768,9 @@ for opt do
--enable-modules)
modules=yes
;;
+ --disable-modules)
+ modules=no
+ ;;
--cpu=*)
;;
--target-list=*) target_list=$optarg
@@ -1259,7 +1262,8 @@ Advanced options (experts only):
--sysconfdir=PATHinstall config in PATH$confsuffix
--localstatedir=PATH install local state in PATH (set at runtime on
win32)
--with-confsuffix=SUFFIX suffix for QEMU data inside
datadir/libdir/sysconfdir [$confsuffix]
- --enable-modules enable modules support
+ --enable-modules enable modules support (default)
+ --disable-modulesenable modules support
--enable-debug-tcg enable TCG debugging
--disable-debug-tcg disable TCG debugging (default)
--enable-debug-info enable debugging information (default)
@@ -2699,22 +2703,25 @@ if test $mingw32 = yes; then
else
glib_req_ver=2.12
fi
-glib_modules=gthread-2.0
-if test $modules = yes; then
-glib_modules=$glib_modules gmodule-2.0
-fi
-for i in $glib_modules; do
-if $pkg_config --atleast-version=$glib_req_ver $i; then
-glib_cflags=`$pkg_config --cflags $i`
-glib_libs=`$pkg_config --libs $i`
-CFLAGS=$glib_cflags $CFLAGS
-LIBS=$glib_libs $LIBS
-libs_qga=$glib_libs $libs_qga
-else
-error_exit glib-$glib_req_ver $i is required to compile QEMU
-fi
-done
+glib_module_try_config()
I guess module here means glib package or component?
It's a little confusing since gmodule-2.0 is needed for QEMU modular
build support :).
How about just glib_pkg_config()?
+ if ! glib_module_try_config gmodule-2.0; then
+if $force; then
+ error_exit glib-$glib_req_ver gthread-2.0 is required to compile QEMU
s/gthread-2.0/gmodule-2.0/
pgpB2BG_285kI.pgp
Description: PGP signature
[Qemu-devel] [PATCH 07/15] linux-user/main.c (m68k): Use get_user_u16 rather than lduw in cpu_loop
In the m68k cpu_loop() use get_user_u16 to read the immediate for
the simcall rahter than lduw, to bring it into line with how other
archs do it and to remove another user of the ldl family of functions.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
linux-user/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/linux-user/main.c b/linux-user/main.c
index 67b0231..65b5a36 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -2972,7 +2972,7 @@ void cpu_loop(CPUM68KState *env)
{
if (ts-sim_syscalls) {
uint16_t nr;
-nr = lduw(env-pc + 2);
+get_user_u16(nr, env-pc + 2);
env-pc += 4;
do_m68k_simcall(env, nr);
} else {
--
1.9.1
[Qemu-devel] [PATCH 00/15] Clean up cpu-ldst ld/st memory accessors
I was looking at our confusing mess of memory accessor functions,
and I realised that partly it was confusing because we have a
bunch of unnecessary junk lurking in there :-) This series
attempts to clean things up by removing things we weren't using
at all or were only using by mistake in a few places:
* ldul_*: not used
* ld* (ldl, etc): hardly used
* ld*_kernel: not used
* ld*_raw: hardly used
* cpu_{ld,st}{fq,fl}: not used
The dull parts of this series are removing the unused macros
and fixing uses of the hardly-used macros so those can be
deleted too. This series also switches to using inline functions
rather than macros for the user-only cpu_ld/st* accessors, bringing
them into line with the softmmu configs. This has the nice
side effect of letting us get rid of the _raw accessor macros too.
I've also thrown in a commit which cleans up the doc comments.
Peter Maydell (15):
cpu_ldst.h: Remove unused ldul_ macros
monitor.c: Use ld*_p() instead of ld*_raw()
target-sparc: Don't use {ld,st}*_raw functions
linux-user/elfload.c: Don't use _raw accessor functions
bsd-user/elfload.c: Don't use ldl() or ldq_raw()
linux-user/vm86.c: Use cpu_ldl_data c rather than plain ldl c
linux-user/main.c (m68k): Use get_user_u16 rather than lduw in
cpu_loop
target-mips: Don't use _raw load/store accessors
cpu_ldst.h: Drop unused ld/st*_kernel defines
cpu_ldst.h: Remove unused very short ld*/st* defines
cpu_ldst.h: Use inline functions for usermode cpu_ld/st accessors
cpu_ldst_template.h: Use ld*_p directly rather than via ld*_raw macros
cpu_ldst.h: Drop unused _raw macros, saddr() and laddr()
cpu_ldst_template.h: Drop unused cpu_ldfq/stfq/ldfl/stfl accessors
cpu_ldst.h, cpu-all.h, bswap.h: Update documentation on ld/st
accessors
bsd-user/elfload.c| 11 +-
include/exec/cpu-all.h| 38 +--
include/exec/cpu_ldst.h | 162 +-
include/exec/cpu_ldst_template.h | 60 +--
include/exec/cpu_ldst_useronly_template.h | 81 +++
include/qemu/bswap.h | 11 +-
linux-user/elfload.c | 7 +-
linux-user/main.c | 2 +-
linux-user/vm86.c | 57 ++-
monitor.c | 8 +-
target-i386/seg_helper.c | 16 ++-
target-mips/op_helper.c | 4 +-
target-sparc/ldst_helper.c| 24 ++---
13 files changed, 224 insertions(+), 257 deletions(-)
create mode 100644 include/exec/cpu_ldst_useronly_template.h
--
1.9.1
Re: [Qemu-devel] [PATCH 0/2] qed: additional input validation
On Mon, Jan 12, 2015 at 12:31:31PM +, Stefan Hajnoczi wrote: These patches add an overflow check and a test case for invalid QED headers. Note that this has no security impact because reading the backing filename is limited to sizeof(bs-backing_file). Stefan Hajnoczi (2): qed: check for header size overflow qemu-iotests: add 116 invalid QED input file tests block/qed.c| 6 +++ tests/qemu-iotests/116 | 96 ++ tests/qemu-iotests/116.out | 37 ++ tests/qemu-iotests/group | 1 + 4 files changed, 140 insertions(+) create mode 100755 tests/qemu-iotests/116 create mode 100644 tests/qemu-iotests/116.out Kevin: Thanks for the style suggestion, I have applied your tweak. It does read clearer when the expression checks UINT32_MAX. Thanks, applied to my block tree: https://github.com/stefanha/qemu/commits/block Stefan pgpFiu83Rrelw.pgp Description: PGP signature
Re: [Qemu-devel] [RFC PATCH 3/4] hw/arm/sysbus-fdt: vfio device property for interrupts
Hi Baptiste
On 01/12/2015 02:21 PM, Baptiste Reynal wrote:
Use the VFIO device property API to retrieve interrupt
information (type and flags) during device node creation.
Signed-off-by: Baptiste Reynal b.rey...@virtualopensystems.com
---
hw/arm/sysbus-fdt.c | 26 ++
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/hw/arm/sysbus-fdt.c b/hw/arm/sysbus-fdt.c
index efdeea7..087e788 100644
--- a/hw/arm/sysbus-fdt.c
+++ b/hw/arm/sysbus-fdt.c
@@ -31,6 +31,7 @@
#include hw/vfio/vfio-pl330.h
#include libfdt.h
+#include linux/vfio.h
/*
* internal struct that contains the information to create dynamic
@@ -66,7 +67,7 @@ typedef struct NodeCreationPair {
* Helper function, generate interrupts property for a given node
might be worth adding something like based on host device tree node
*/
static int set_interrupts_fdt_node(char *nodename, SysBusDevice *sbdev,
-void *opaque, int type, int flags)
+void *opaque)
{
PlatformBusFdtData *data = opaque;
PlatformBusDevice *pbus = data-pbus;
@@ -76,23 +77,32 @@ static int set_interrupts_fdt_node(char *nodename,
SysBusDevice *sbdev,
int i, ret;
VFIOPlatformDevice *vdev = VFIO_PLATFORM_DEVICE(sbdev);
VFIODevice *vbasedev = vdev-vbasedev;
+struct vfio_dev_property *irq_prop;
+
+irq_prop = vfio_get_dev_property(vbasedev-fd, interrupts,
+VFIO_DEV_PROPERTY_TYPE_U32);
+
+if (irq_prop == NULL) {
+return -1;
+}
irq_attr = g_new(uint32_t, vbasedev-num_irqs*3);
for (i = 0; i vbasedev-num_irqs; i++) {
irq_number = platform_bus_get_irqn(pbus, sbdev , i)
+ data-irq_start;
-irq_attr[3*i] = cpu_to_be32(type);
+irq_attr[3*i] = cpu_to_be32(((__u32 *) irq_prop-data)[3*i]);
irq_attr[3*i+1] = cpu_to_be32(irq_number);
-irq_attr[3*i+2] = cpu_to_be32(flags);
+irq_attr[3*i+2] = cpu_to_be32(((__u32 *) irq_prop-data)[3*i+2]);
}
- ret = qemu_fdt_setprop(fdt, nodename, interrupts,
- irq_attr, vbasedev-num_irqs*3*sizeof(uint32_t));
+ret = qemu_fdt_setprop(fdt, nodename, interrupts,
+irq_attr, vbasedev-num_irqs*3*sizeof(uint32_t));
delta may be removed?
g_free(irq_attr);
+g_free(irq_prop);
- return ret;
+return ret;
delta may be removed?
Best Regards
Eric
}
/**
@@ -168,7 +178,7 @@ static int add_calxeda_midway_xgmac_fdt_node(SysBusDevice
*sbdev, void *opaque)
goto fail;
}
-ret = set_interrupts_fdt_node(nodename, sbdev, opaque, 0, 0x4);
+ret = set_interrupts_fdt_node(nodename, sbdev, opaque);
if (ret 0) {
error_report(could not set interrupts property of node %s,
@@ -248,7 +258,7 @@ static int add_arm_pl330_fdt_node(SysBusDevice *sbdev,
void *opaque)
goto fail;
}
-ret = set_interrupts_fdt_node(nodename, sbdev, opaque, 0, 0x4);
+ret = set_interrupts_fdt_node(nodename, sbdev, opaque);
if (ret 0) {
error_report(could not set interrupts property of node %s,
Re: [Qemu-devel] [PATCH 2/4] console: add opengl rendering helper functions
On 2015-01-12 at 07:35, Gerd Hoffmann wrote:
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
include/ui/console.h | 23 ++
ui/Makefile.objs | 5 ++
ui/console-gl.c | 127 +++
3 files changed, 155 insertions(+)
create mode 100644 ui/console-gl.c
diff --git a/include/ui/console.h b/include/ui/console.h
index 22ef8ca..5cb169c 100644
--- a/include/ui/console.h
+++ b/include/ui/console.h
@@ -9,6 +9,11 @@
#include qapi-types.h
#include qapi/error.h
+#ifdef CONFIG_OPENGL
+#include GL/gl.h
+#include GL/glext.h
+#endif
+
/* keyboard/mouse support */
#define MOUSE_EVENT_LBUTTON 0x01
@@ -118,6 +123,11 @@ struct DisplaySurface {
pixman_format_code_t format;
pixman_image_t *image;
uint8_t flags;
+#ifdef CONFIG_OPENGL
+GLenum glformat;
+GLenum gltype;
+GLuint texture;
+#endif
};
typedef struct QemuUIInfo {
@@ -320,6 +330,19 @@ void qemu_console_copy(QemuConsole *con, int src_x, int
src_y,
DisplaySurface *qemu_console_surface(QemuConsole *con);
DisplayState *qemu_console_displaystate(QemuConsole *console);
+#ifdef CONFIG_OPENGL
+/* console-gl.c */
+bool console_gl_check_format(DisplayChangeListener *dcl,
+ pixman_format_code_t format);
+void surface_gl_create_texture(DisplaySurface *surface);
+void surface_gl_update_texture(DisplaySurface *surface,
+ int x, int y, int w, int h);
+void surface_gl_render_texture(DisplaySurface *surface);
+void surface_gl_destroy_texture(DisplaySurface *surface);
+void surface_gl_setup_viewport(DisplaySurface *surface,
+ int ww, int wh);
+#endif
+
/* sdl.c */
void sdl_display_init(DisplayState *ds, int full_screen, int no_frame);
diff --git a/ui/Makefile.objs b/ui/Makefile.objs
index 13b5cfb..3173778 100644
--- a/ui/Makefile.objs
+++ b/ui/Makefile.objs
@@ -24,4 +24,9 @@ sdl.mo-objs := sdl2.o sdl2-input.o sdl2-2d.o
endif
sdl.mo-cflags := $(SDL_CFLAGS)
+ifeq ($(CONFIG_OPENGL),y)
+common-obj-y += console-gl.o
+libs_softmmu += $(OPENGL_LIBS)
+endif
+
gtk.o-cflags := $(GTK_CFLAGS) $(VTE_CFLAGS)
diff --git a/ui/console-gl.c b/ui/console-gl.c
new file mode 100644
index 000..470dd61
--- /dev/null
+++ b/ui/console-gl.c
@@ -0,0 +1,127 @@
+/*
+ * QEMU graphical console -- opengl helper bits
+ *
+ * Copyright (c) 2004 Fabrice Bellard
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+#include qemu-common.h
+#include ui/console.h
+
+bool console_gl_check_format(DisplayChangeListener *dcl,
+ pixman_format_code_t format)
+{
+switch (format) {
+case PIXMAN_x8r8g8b8:
+case PIXMAN_a8r8g8b8:
+case PIXMAN_r5g6b5:
+return true;
+default:
+return false;
+}
+}
What is this function supposed to be used for?
+
+void surface_gl_create_texture(DisplaySurface *surface)
+{
+switch (surface-format) {
+case PIXMAN_x8r8g8b8:
+case PIXMAN_a8r8g8b8:
+surface-glformat = GL_BGRA;
Why does the format code seem to imply ARGB order but you're using the
exact opposite? I could imagine something like endianness being the
reason, but you're using RGB below where the format code says exactly that.
+surface-gltype = GL_UNSIGNED_BYTE;
+break;
+case PIXMAN_r5g6b5:
+surface-glformat = GL_RGB;
+surface-gltype = GL_UNSIGNED_SHORT_5_6_5;
+break;
+default:
+g_assert_not_reached();
+}
+
+glGenTextures(1, surface-texture);
+glEnable(GL_TEXTURE_2D);
+glBindTexture(GL_TEXTURE_2D, surface-texture);
+glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB,
Discarding the alpha channel is intentional, I suppose?
+ surface_width(surface),
+ surface_height(surface),
+ 0, surface-glformat, surface-gltype,
+ surface_data(surface));
Is
Re: [Qemu-devel] global_mutex and multithread.
On 15 Jan 2015, at 21:27, Paolo Bonzini pbonz...@redhat.com wrote: On 15/01/2015 20:07, Mark Burton wrote: However - if we go this route -the current patch is only for x86. (apart from the fact that we still seem to land in a deadlock…) Jan said he had it working at least on ARM (MusicPal). yeah - our problem is when we enable multi-threads - which I dont believe Jan did… Indeed - he specifically says that doesn’t work…. :-) One thing I wonder - why do we need to go to the extent of mutexing in the TCG like this? Why can’t you simply put a mutex get/release on the slow path? If the core is going to do ‘fast path’ access to the memory, - even if that memory was IO mapped - would it matter if it didn’t have the mutex? Because there is no guarantee that the memory map isn't changed by a core under the feet of another. The TLB (in particular the iotlb) is only valid with reference to a particular memory map. Changes to the memory map certainly happen in the slow path, but lookups are part of the fast path. Even an rwlocks is too slow for a fast path, hence the plan of going with RCU. Could we arrange the world such that lookups ‘succeed’ (the wheels dont fall off) -ether getting the old value, or the new, but not getting rubbish - and we still only take the mutex if we are going to make alterations to the MM itself? (I have’t looked at the code around that… so sorry if the question is ridiculous). Cheers Mark. Paolo +44 (0)20 7100 3485 x 210 +33 (0)5 33 52 01 77x 210 +33 (0)603762104 mark.burton
Re: [Qemu-devel] [PATCH 00/15] Clean up cpu-ldst ld/st memory accessors
On 15/01/2015 20:10, Lluís Vilanova wrote:
Peter Maydell writes:
On 15 January 2015 at 15:32, Lluís Vilanova vilan...@ac.upc.edu wrote:
I haven't reviewed the patches, but that's a much appreciated cleanup! I was
also trying to make sense of all the variants while implementing guest
memory
access tracing
I drew the following terrible ASCII art diagram of the remaining
memory access functions...
(pastebin link for those without fixed-width mail clients:
http://pastebin.ubuntu.com/9757219/ )
If anybody feels they can rearrange it into something less
confusing do feel free :-)
Technically, I did not rearrange it :)
http://pastebin.ubuntu.com/9757456/
PS: some info from the original is missing
Removing even more info, ld/st_*_phys is just an optimized version of
address_space_rw/read/write, so we can merge them and get to something
readable...
Paolo
# dot -T pdf -o qemu-mem.pdf qemu-mem.dot
digraph QEMU {
mr [label=MemoryRegion callbacks];
host_mem [label=ld/st_*_p, memcpy, etc.\n(host memory)];
io_mem_mem [label=io_mem_read/write];
io_mem [label=io_read/write*];
as_mem [label=address_space_rw/read/write\nld/st_*_phys];
helper_mem [label=helper_ld_*];
cpu_phys_mem [label=cpu_physical_memory_rw];
cpu_phys_rom [label=cpu_physical_memory_write_rom];
dma_mem [label=dma_memory_rw];
cpu_mem [label=cpu_ld/st_*];
tcg [label=Generated TCG code];
cpu_phys_mem_debug [label=cpu_physical_memory_rw_debug];
io_mem_mem - mr;
io_mem - io_mem_mem;
as_mem - io_mem_mem;
as_mem - host_mem;
helper_mem - io_mem;
helper_mem - host_mem;
cpu_phys_mem - as_mem;
cpu_phys_rom - host_mem;
dma_mem - as_mem;
cpu_mem - helper_mem;
cpu_mem - host_mem;
tcg - helper_mem;
tcg - host_mem;
cpu_phys_mem_debug - cpu_phys_mem;
cpu_phys_mem_debug - cpu_phys_rom;
}
Re: [Qemu-devel] [PATCH 00/15] Clean up cpu-ldst ld/st memory accessors
Peter Maydell writes: On 15 January 2015 at 15:32, Lluís Vilanova vilan...@ac.upc.edu wrote: I haven't reviewed the patches, but that's a much appreciated cleanup! I was also trying to make sense of all the variants while implementing guest memory access tracing I drew the following terrible ASCII art diagram of the remaining memory access functions... (pastebin link for those without fixed-width mail clients: http://pastebin.ubuntu.com/9757219/ ) If anybody feels they can rearrange it into something less confusing do feel free :-) Technically, I did not rearrange it :) http://pastebin.ubuntu.com/9757456/ PS: some info from the original is missing Lluis -- And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer. -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth
[Qemu-devel] [Bug 1409246] Re: ARM GIC / PL061 error on uni-processor system
In arch/arm/mach-realview/realview_*.c pl061_platform_data irq_base members are statically (default) initialised to 0 (whereas for versatile they are explicitly set via defines in the platform headers). In pl061_probe, -ENODEV is returned for irq_base = 0. Changing this to 0, results in irq_domain_add_simple dynamically allocating irqs - and in the case of qemu resolves booting from MMC / SD, where pl061 is linked to pl181 in realview.c I assume this is also valid for real hardware, but have no way to test. I have not figured out what stops the 2.6 kernel booting, which is what I actually need... (seems to be coupled to mmci.c, or possibly the ext2 filesystem) ** Patch added: 0001-fix-pl061-for-realview-boards-dynamically-allocate-i.patch https://bugs.launchpad.net/qemu/+bug/1409246/+attachment/4299488/+files/0001-fix-pl061-for-realview-boards-dynamically-allocate-i.patch -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1409246 Title: ARM GIC / PL061 error on uni-processor system Status in QEMU: Invalid Bug description: chorler@linux-foxtrot:~/projects/src/qemu git describe v2.2.0-369-gab0302e When booting Linux 3.19.1 (default buildroot), configured for realview-pb-a8 on qemu from git (as above). The following message appears (line 253/ 254 of attached log): GIC CPU mask not found - kernel will fail to boot. The kernel does boot - so perhaps this is a misleading error message? (though temporarily tweaking commit 6b9680bb does remove the message) later the following three lines appear when pl061 is probed (resulting in ENODEV): pl061_gpio dev:gpio0: invalid IRQ base in pdata pl061_gpio dev:gpio1: invalid IRQ base in pdata pl061_gpio dev:gpio2: invalid IRQ base in pdata (from linux-3.18.1/drivers/gpio/gpio-pl061.c line 253) qemu/hw/arm/realview.c has some code that suggests to me pl061 is required for the MMC. Where should I look to see how to initialise the irq_base member of the platform data in QEmu? To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1409246/+subscriptions
[Qemu-devel] [Bug 1297218] Re: guest hangs after live migration due to tsc jump
It looks as though the relevant commits were re-committed to upstream git HEAD (9a48bcd1b82494671c09b0eefdb882581499 and 317b0a6d8ba44e9bf8f9c3dbd776c4536843d82c). So this may be fixed in vivid, and we might be able to cherrypick the final patches to trusty. ** Package changed: libvirt (Ubuntu) = qemu (Ubuntu) ** Also affects: qemu (Ubuntu Trusty) Importance: Undecided Status: New ** Also affects: glusterfs (Ubuntu Trusty) Importance: Undecided Status: New ** Changed in: qemu (Ubuntu Trusty) Status: New = Triaged ** Changed in: qemu (Ubuntu Trusty) Status: Triaged = Confirmed ** Changed in: qemu (Ubuntu Trusty) Importance: Undecided = High -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1297218 Title: guest hangs after live migration due to tsc jump Status in QEMU: New Status in glusterfs package in Ubuntu: Invalid Status in qemu package in Ubuntu: Triaged Status in glusterfs source package in Trusty: New Status in qemu source package in Trusty: Confirmed Bug description: We have two identical Ubuntu servers running libvirt/kvm/qemu, sharing a Gluster filesystem. Guests can be live migrated between them. However, live migration often leads to the guest being stuck at 100% for a while. In that case, the dmesg output for such a guest will show (once it recovers): Clocksource tsc unstable (delta = 662463064082 ns). In this particular example, a guest was migrated and only after 11 minutes (662 seconds) did it become responsive again. It seems that newly booted guests doe not suffer from this problem, these can be migrated back and forth at will. After a day or so, the problem becomes apparent. It also seems that migrating from server A to server B causes much more problems than going from B back to A. If necessary, I can do more measurements to qualify these observations. The VM servers run Ubuntu 13.04 with these packages: Kernel: 3.8.0-35-generic x86_64 Libvirt: 1.0.2 Qemu: 1.4.0 Gluster-fs: 3.4.2 (libvirt access the images via the filesystem, not using libgfapi yet as the Ubuntu libvirt is not linked against libgfapi). The interconnect between both machines (both for migration and gluster) is 10GbE. Both servers are synced to NTP and well within 1ms form one another. Guests are either Ubuntu 13.04 or 13.10. On the guests, the current_clocksource is kvm-clock. The XML definition of the guests only contains: clock offset='utc'/ Now as far as I've read in the documentation of kvm-clock, it specifically supports live migrations, so I'm a bit surprised at these problems. There isn't all that much information to find on these issue, although I have found postings by others that seem to have run into the same issues, but without a solution. --- ApportVersion: 2.14.1-0ubuntu3 Architecture: amd64 DistroRelease: Ubuntu 14.04 Package: libvirt (not installed) ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-3.13.0-24-generic root=UUID=1b0c3c6d-a9b8-4e84-b076-117ae267d178 ro console=ttyS1,115200n8 BOOTIF=01-00-25-90-75-b5-c8 ProcVersionSignature: Ubuntu 3.13.0-24.47-generic 3.13.9 Tags: trusty apparmor apparmor apparmor apparmor apparmor Uname: Linux 3.13.0-24-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: _MarkForUpload: True modified.conffile..etc.default.libvirt.bin: [modified] modified.conffile..etc.libvirt.libvirtd.conf: [modified] modified.conffile..etc.libvirt.qemu.conf: [modified] modified.conffile..etc.libvirt.qemu.networks.default.xml: [deleted] mtime.conffile..etc.default.libvirt.bin: 2014-05-12T19:07:40.020662 mtime.conffile..etc.libvirt.libvirtd.conf: 2014-05-13T14:40:25.894837 mtime.conffile..etc.libvirt.qemu.conf: 2014-05-12T18:58:27.885506 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1297218/+subscriptions
[Qemu-devel] [Bug 1297218] Re: guest hangs after live migration due to tsc jump
@Paul, could you confirm whether qemu 1:2.2+dfsg-3exp~ubuntu1 from https://launchpad.net/~ubuntu-virt/+archive/ubuntu/virt-daily-upstream fixes this issue? If it does then I'll go ahead and backport the patch. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1297218 Title: guest hangs after live migration due to tsc jump Status in QEMU: New Status in glusterfs package in Ubuntu: Invalid Status in qemu package in Ubuntu: Triaged Status in glusterfs source package in Trusty: New Status in qemu source package in Trusty: Confirmed Bug description: We have two identical Ubuntu servers running libvirt/kvm/qemu, sharing a Gluster filesystem. Guests can be live migrated between them. However, live migration often leads to the guest being stuck at 100% for a while. In that case, the dmesg output for such a guest will show (once it recovers): Clocksource tsc unstable (delta = 662463064082 ns). In this particular example, a guest was migrated and only after 11 minutes (662 seconds) did it become responsive again. It seems that newly booted guests doe not suffer from this problem, these can be migrated back and forth at will. After a day or so, the problem becomes apparent. It also seems that migrating from server A to server B causes much more problems than going from B back to A. If necessary, I can do more measurements to qualify these observations. The VM servers run Ubuntu 13.04 with these packages: Kernel: 3.8.0-35-generic x86_64 Libvirt: 1.0.2 Qemu: 1.4.0 Gluster-fs: 3.4.2 (libvirt access the images via the filesystem, not using libgfapi yet as the Ubuntu libvirt is not linked against libgfapi). The interconnect between both machines (both for migration and gluster) is 10GbE. Both servers are synced to NTP and well within 1ms form one another. Guests are either Ubuntu 13.04 or 13.10. On the guests, the current_clocksource is kvm-clock. The XML definition of the guests only contains: clock offset='utc'/ Now as far as I've read in the documentation of kvm-clock, it specifically supports live migrations, so I'm a bit surprised at these problems. There isn't all that much information to find on these issue, although I have found postings by others that seem to have run into the same issues, but without a solution. --- ApportVersion: 2.14.1-0ubuntu3 Architecture: amd64 DistroRelease: Ubuntu 14.04 Package: libvirt (not installed) ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-3.13.0-24-generic root=UUID=1b0c3c6d-a9b8-4e84-b076-117ae267d178 ro console=ttyS1,115200n8 BOOTIF=01-00-25-90-75-b5-c8 ProcVersionSignature: Ubuntu 3.13.0-24.47-generic 3.13.9 Tags: trusty apparmor apparmor apparmor apparmor apparmor Uname: Linux 3.13.0-24-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: _MarkForUpload: True modified.conffile..etc.default.libvirt.bin: [modified] modified.conffile..etc.libvirt.libvirtd.conf: [modified] modified.conffile..etc.libvirt.qemu.conf: [modified] modified.conffile..etc.libvirt.qemu.networks.default.xml: [deleted] mtime.conffile..etc.default.libvirt.bin: 2014-05-12T19:07:40.020662 mtime.conffile..etc.libvirt.libvirtd.conf: 2014-05-13T14:40:25.894837 mtime.conffile..etc.libvirt.qemu.conf: 2014-05-12T18:58:27.885506 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1297218/+subscriptions
Re: [Qemu-devel] global_mutex and multithread.
Still in agony on this issue - I’ve CC’d Jan as his patch looks important… the patch below would seem to offer by far and away the best result here. (If only we could get it working ;-) ) it allows threads to proceed as we want them to, it means we dont have to ‘count’ the number of CPU’s that are executing code (and could therefor potentially access IO space)… However - if we go this route -the current patch is only for x86. (apart from the fact that we still seem to land in a deadlock…) One thing I wonder - why do we need to go to the extent of mutexing in the TCG like this? Why can’t you simply put a mutex get/release on the slow path? If the core is going to do ‘fast path’ access to the memory, - even if that memory was IO mapped - would it matter if it didn’t have the mutex? (It would help - I think - if we understood why you believed this patch wouldn’t work with SMP - I thought that was to do with the ‘round-robin’ mechanism - we’ve removed that for multi-thread anyway - but I guess we may have missed something there?) Cheers Mark. On 15 Jan 2015, at 12:12, Paolo Bonzini pbonz...@redhat.com wrote: [now with correct listserver address] On 15/01/2015 11:25, Frederic Konrad wrote: Hi everybody, In case of multithread TCG what is the best way to handle qemu_global_mutex? We though to have one mutex per vcpu and then synchronize vcpu threads when they exit (eg: in tcg_exec_all). Is that making sense? The basic ideas from Jan's patch in http://article.gmane.org/gmane.comp.emulators.qemu/118807 still apply. RAM block reordering doesn't exist anymore, having been replaced with mru_block. The patch reacquired the lock when entering MMIO or PIO emulation. That's enough while there is only one VCPU thread. Once you have 1 VCPU thread you'll need the RCU work that I am slowly polishing and sending out. That's because one device can change the memory map, and that will cause a tlb_flush for all CPUs in tcg_commit, and that's not thread-safe. And later on, once devices start being converted to run outside the BQL, that can be changed to use new functions address_space_rw_unlocked / io_mem_read_unlocked / io_mem_write_unlocked. Something like that is already visible at https://github.com/bonzini/qemu/commits/rcu (ignore patches after kvm: Switch to unlocked MMIO). Paolo +44 (0)20 7100 3485 x 210 +33 (0)5 33 52 01 77x 210 +33 (0)603762104 mark.burton
Re: [Qemu-devel] Press Inquiry: Qemu Advent Calendar (German Linux Magazin)
Hi Stefan, if nothing went wrong the (whole) advent calendar will be on the DVD published with the Linux Magazin issue 03/2015. The release date is the 05. Feb. 2015 (in germany). Best regards, Tim Schürmann i...@tim-schuermann.de Am 15.01.2015 um 15:47 schrieb Stefan Hajnoczi: On Tue, Jan 13, 2015 at 01:35:55PM +0100, Tim Schürmann wrote: Hi Tim, In order to comply with the license on GPL images you will need to offer the source code (see links on http://qemu-advent-calendar.org/ for each image). The Ubuntu Core and Ceph sourcecodes won't fit on our DVD. So we have to provide links to the corresponding websites. Is this Ok with you? (My editor-in-chief said that this conform with the GPL.) I am not the (only) copyright holder of Ubuntu Core or Ceph, and I'm not a lawyer. You need to decide whether you are in compliance or not. My plan is to keep http://qemu-advent-calendar.org/ running in the foreseeable future so the sources should remain accessible. If you mirror the sources it would be best - that way you can continue providing source even if http://qemu-advent-calendar.org/ were to go offline. I'm CCing Matthew Hungerford at Pebble to confirm that the Pebble Smartwatch image can also be distributed. Did you got an answer already? Yes, Matthew responded. It was a Reply instead of Reply-All. I forgot to forward you his response (sorry): Date: Fri, 9 Jan 2015 11:12:52 -0800 From: Matthew Hungerford matthew.hungerf...@getpebble.com Sounds great, One of my german coworkers is a fan of Linux Magazin, and would get a kick out if it being featured there. Thanks for asking, Matthew All the best, Stefan
Re: [Qemu-devel] [PATCH] arm: define version-based machine type for ARM
On 15 January 2015 at 18:52, Wei Huang w...@redhat.com wrote: On 01/15/2015 12:10 PM, Peter Maydell wrote: I don't think we're anywhere ready yet to support between version migration compatibility. We will want this *eventually* but we are a long long way away from needing it...(maybe a year?) Thanks, Peter. I think migration support is getting closer than one year. It might not create problems at the beginning. So I understand your point. Well, at the moment in mainline migration doesn't work at all! So we need to spend a period of time stabilising it, and making sure that the 'virt' machine has all the capabilities we need and that we've made any further breaking changes which we need to do. Then we need to have somebody who's willing to do the extensive between-version migration testing that you need in order for the feature to actually work in practice. It's only when we are sure that we can actually support cross-version migration and we have the necessary demand from users (ie: distros, I think), that we should start creating per-version machines and backwards-compatibility property settings and so on. thanks -- PMM
Re: [Qemu-devel] global_mutex and multithread.
On 15/01/2015 20:07, Mark Burton wrote: However - if we go this route -the current patch is only for x86. (apart from the fact that we still seem to land in a deadlock…) Jan said he had it working at least on ARM (MusicPal). One thing I wonder - why do we need to go to the extent of mutexing in the TCG like this? Why can’t you simply put a mutex get/release on the slow path? If the core is going to do ‘fast path’ access to the memory, - even if that memory was IO mapped - would it matter if it didn’t have the mutex? Because there is no guarantee that the memory map isn't changed by a core under the feet of another. The TLB (in particular the iotlb) is only valid with reference to a particular memory map. Changes to the memory map certainly happen in the slow path, but lookups are part of the fast path. Even an rwlocks is too slow for a fast path, hence the plan of going with RCU. Paolo
[Qemu-devel] [PATCH v2] Fixes key mapping so all keys work
Fixes keyboard mapping so right shift, right command, right option, right
control, keypad period, keypad '=', keypad enter, and F13 all work.
Signed-off-by: John Arbuckle programmingk...@gmail.com
---
Undid most changes to keyboard map in cocoa.m.
Most changes made to keyboard map in adb.c.
Since there is no keypad '=' key for the PC/AT or PC/XT layouts, I had to
invent my own number for it. It works for the Mac OS X guest. Guest like
Windows XP are not effected because they don't use the Macintosh keyboard
layout.
Signed-off-by: John Arbuckle programmingk...@gmail.com
---
hw/input/adb.c |8
ui/cocoa.m |4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/hw/input/adb.c b/hw/input/adb.c
index 34c8058..aa7287f 100644
--- a/hw/input/adb.c
+++ b/hw/input/adb.c
@@ -182,12 +182,12 @@ static const uint8_t pc_to_adb_keycode[256] = {
84, 85, 82, 65, 0, 0, 10,103,111, 0, 0,110, 81, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
- 0, 0, 0, 94, 0, 93, 0, 0, 0, 0, 0, 0,104,102, 0, 0,
- 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 76,125, 0, 0,
+ 0, 81, 0, 94, 0, 93, 0, 0, 0, 0, 0, 0,104,102, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 76, 0, 0, 0, 76, 54, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,105, 0, 0, 0, 0, 0,
- 0, 0, 0, 0, 0, 75, 0, 0,124, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0, 75, 0,105, 58, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0,115, 62,116, 0, 59, 0, 60, 0,119,
- 61,121,114,117, 0, 0, 0, 0, 0, 0, 0, 55,126, 0,127, 0,
+ 61,121,114,117, 0, 0, 0, 0, 0, 0, 0, 55, 55, 0,127, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 95, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
};
diff --git a/ui/cocoa.m b/ui/cocoa.m
index c8535a3..456f942 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -139,7 +139,7 @@ int keymap[] =
157,// 62 0x3E0x9dE0,1D R CTRL QZ_RCTRL
0, // 63 0x3FUndefined
0, // 64 0x40Undefined
-0, // 65 0x41Undefined
+83, // 65 0x410x53KP .QZ_KP_PERIOD
0, // 66 0x42Undefined
55, // 67 0x430x37KP *QZ_KP_MULTIPLY
0, // 68 0x44Undefined
@@ -155,7 +155,7 @@ int keymap[] =
74, // 78 0x4E0x4aKP -QZ_KP_MINUS
0, // 79 0x4FUndefined
0, // 80 0x50Undefined
-0, // 81 0x51QZ_KP_EQUALS
+129,// 81 0x510x51KP =QZ_KP_EQUALS
82, // 82 0x520x52KP 0QZ_KP0
79, // 83 0x530x4fKP 1QZ_KP1
80, // 84 0x540x50KP 2QZ_KP2
--
1.7.5.4
Re: [Qemu-devel] [PATCH 4/4] sdl2: move SDL_* includes to sdl2.h
On 2015-01-12 at 07:35, Gerd Hoffmann wrote: Signed-off-by: Gerd Hoffmann kra...@redhat.com --- include/ui/sdl2.h | 7 +++ ui/sdl2-2d.c | 6 -- ui/sdl2-gl.c | 7 --- ui/sdl2-input.c | 6 -- ui/sdl2.c | 6 -- 5 files changed, 7 insertions(+), 25 deletions(-) Reviewed-by: Max Reitz mre...@redhat.com
Re: [Qemu-devel] [PATCH 3/4] sdl2: add support for display rendering using opengl.
On 2015-01-12 at 07:35, Gerd Hoffmann wrote:
Add new sdl2-gl.c file, with display
rendering functions using opengl.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
include/ui/console.h | 1 +
include/ui/sdl2.h| 10 +
ui/Makefile.objs | 4 ++
ui/sdl.c | 11 +
ui/sdl2-2d.c | 7
ui/sdl2-gl.c | 114 +++
ui/sdl2.c| 67 ++
vl.c | 11 +
8 files changed, 218 insertions(+), 7 deletions(-)
create mode 100644 ui/sdl2-gl.c
diff --git a/include/ui/console.h b/include/ui/console.h
index 5cb169c..7496dee 100644
--- a/include/ui/console.h
+++ b/include/ui/console.h
@@ -344,6 +344,7 @@ void surface_gl_setup_viewport(DisplaySurface *surface,
#endif
/* sdl.c */
+void sdl_display_early_init(int opengl);
void sdl_display_init(DisplayState *ds, int full_screen, int no_frame);
/* cocoa.m */
diff --git a/include/ui/sdl2.h b/include/ui/sdl2.h
index f56c596..5c962da 100644
--- a/include/ui/sdl2.h
+++ b/include/ui/sdl2.h
@@ -11,6 +11,9 @@ struct sdl2_console {
int last_vm_running; /* per console for caption reasons */
int x, y;
int hidden;
+int opengl;
+int updates;
+SDL_GLContext winctx;
};
void sdl2_window_create(struct sdl2_console *scon);
@@ -29,4 +32,11 @@ void sdl2_2d_switch(DisplayChangeListener *dcl,
void sdl2_2d_refresh(DisplayChangeListener *dcl);
void sdl2_2d_redraw(struct sdl2_console *scon);
+void sdl2_gl_update(DisplayChangeListener *dcl,
+int x, int y, int w, int h);
+void sdl2_gl_switch(DisplayChangeListener *dcl,
+DisplaySurface *new_surface);
+void sdl2_gl_refresh(DisplayChangeListener *dcl);
+void sdl2_gl_redraw(struct sdl2_console *scon);
+
#endif /* SDL2_H */
diff --git a/ui/Makefile.objs b/ui/Makefile.objs
index 3173778..c1f4299 100644
--- a/ui/Makefile.objs
+++ b/ui/Makefile.objs
@@ -21,6 +21,10 @@ sdl.mo-objs := sdl.o sdl_zoom.o
endif
ifeq ($(CONFIG_SDLABI),2.0)
sdl.mo-objs := sdl2.o sdl2-input.o sdl2-2d.o
+ifeq ($(CONFIG_OPENGL),y)
+sdl.mo-objs += sdl2-gl.o
+libs_softmmu += $(OPENGL_LIBS)
+endif
endif
sdl.mo-cflags := $(SDL_CFLAGS)
diff --git a/ui/sdl.c b/ui/sdl.c
index 3e9d810..1fe002d 100644
--- a/ui/sdl.c
+++ b/ui/sdl.c
@@ -873,6 +873,17 @@ static const DisplayChangeListenerOps dcl_ops = {
.dpy_cursor_define = sdl_mouse_define,
};
+void sdl_display_early_init(int opengl)
+{
+if (opengl == 1 /* on */) {
+fprintf(stderr,
+SDL1 display code has no opengl support.\n
+Please recompile qemu with SDL2, using\n
+./configure --enable-sdl --with-sdlabi=2.0\n);
+exit(1);
+}
+}
+
void sdl_display_init(DisplayState *ds, int full_screen, int no_frame)
{
int flags;
diff --git a/ui/sdl2-2d.c b/ui/sdl2-2d.c
index 9264817..85f1be4 100644
--- a/ui/sdl2-2d.c
+++ b/ui/sdl2-2d.c
@@ -42,6 +42,8 @@ void sdl2_2d_update(DisplayChangeListener *dcl,
DisplaySurface *surf = qemu_console_surface(dcl-con);
SDL_Rect rect;
+assert(!scon-opengl);
+
if (!surf) {
return;
}
@@ -67,6 +69,8 @@ void sdl2_2d_switch(DisplayChangeListener *dcl,
DisplaySurface *old_surface = scon-surface;
int format = 0;
+assert(!scon-opengl);
+
scon-surface = new_surface;
if (scon-texture) {
@@ -107,12 +111,15 @@ void sdl2_2d_refresh(DisplayChangeListener *dcl)
{
struct sdl2_console *scon = container_of(dcl, struct sdl2_console, dcl);
+assert(!scon-opengl);
graphic_hw_update(dcl-con);
sdl2_poll_events(scon);
}
void sdl2_2d_redraw(struct sdl2_console *scon)
{
+assert(!scon-opengl);
+
if (!scon-surface) {
return;
}
diff --git a/ui/sdl2-gl.c b/ui/sdl2-gl.c
new file mode 100644
index 000..b8620ca
--- /dev/null
+++ b/ui/sdl2-gl.c
@@ -0,0 +1,114 @@
+/*
+ * QEMU SDL display driver
+ *
+ * Copyright (c) 2003 Fabrice Bellard
Just as mentioned by Paolo on patch 2, this may be supposed to mention
you instead.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE
[Qemu-devel] [PATCH v7] block/raw-posix.c: Fixes raw_getlength() on Mac OS X so that it reports the correct length of a real CD
This patch allows Mac OS X to use a real CDROM disc in QEMU. Testing this patch
will require using QEMU v2.2.0 because the current git version has a bug in it
that prevents /dev/cdrom from being used. make check did pass and my Debian
boot disc did work.
Signed-off-by: John Arbuckle programmingk...@gmail.com
---
Totally rewritten.
block/raw-posix.c | 15 ++-
1 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/block/raw-posix.c b/block/raw-posix.c
index e51293a..a95cfcf 100644
--- a/block/raw-posix.c
+++ b/block/raw-posix.c
@@ -1312,7 +1312,20 @@ again:
if (size == 0)
#endif
#if defined(__APPLE__) defined(__MACH__)
-size = LLONG_MAX;
+ {
+ uint64_t sectors = 0;
+ uint32_t sector_size = 0;
+
+ if (ioctl(fd, DKIOCGETBLOCKCOUNT, sectors) == 0
+ioctl(fd, DKIOCGETBLOCKSIZE, sector_size) == 0) {
+ size = sectors * sector_size;
+ } else {
+ size = lseek(fd, 0LL, SEEK_END);
+ if (size 0) {
+ return -errno;
+ }
+ }
+ }
#else
size = lseek(fd, 0LL, SEEK_END);
if (size 0) {
--
1.7.5.4
[Qemu-devel] [PATCH] pc-dimm: fix checking for backend memory size
If hot add 100MiB memory like this:
(monitor) object_add memory-backend-ram,id=ram0,size=100M
(monitor) device_add pc-dimm,id=d0,memdev=ram0
The hotplug operation will faile, and the guest will print error message:
Section-unaligned hotplug range: start 0x1, size 0x640
acpi PNP0C80:00: add_memory failed
acpi PNP0C80:00: acpi_memory_enable_device() error
Then I found that, according to the func check_hotplug_memory_range() in linux
kernel, backend memory size must be multiple of 128MiB, not 2MiB.
So this patch checks whether backend memory size is multiple of 128MiB.
Signed-off-by: Zhu Guihua zhugh.f...@cn.fujitsu.com
---
hw/mem/pc-dimm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/mem/pc-dimm.c b/hw/mem/pc-dimm.c
index d431834..3b8a015 100644
--- a/hw/mem/pc-dimm.c
+++ b/hw/mem/pc-dimm.c
@@ -161,9 +161,9 @@ uint64_t pc_dimm_get_free_addr(uint64_t address_space_start,
goto out;
}
-if (QEMU_ALIGN_UP(size, align) != size) {
+if (QEMU_ALIGN_UP(size, align * 64) != size) {
error_setg(errp, backend memory size must be multiple of 0x%
- PRIx64, align);
+ PRIx64, align * 64);
goto out;
}
--
1.9.3
Re: [Qemu-devel] [PATCH] pc-dimm: fix checking for backend memory size
Hi all,
I am sorry that this method to fix this bug was not perfect.
I will find another way to do this.
Plz ignore this patch.
Regards,
Zhu
On Fri, 2015-01-16 at 13:45 +0800, Zhu Guihua wrote:
If hot add 100MiB memory like this:
(monitor) object_add memory-backend-ram,id=ram0,size=100M
(monitor) device_add pc-dimm,id=d0,memdev=ram0
The hotplug operation will faile, and the guest will print error message:
Section-unaligned hotplug range: start 0x1, size 0x640
acpi PNP0C80:00: add_memory failed
acpi PNP0C80:00: acpi_memory_enable_device() error
Then I found that, according to the func check_hotplug_memory_range() in linux
kernel, backend memory size must be multiple of 128MiB, not 2MiB.
So this patch checks whether backend memory size is multiple of 128MiB.
Signed-off-by: Zhu Guihua zhugh.f...@cn.fujitsu.com
---
hw/mem/pc-dimm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/mem/pc-dimm.c b/hw/mem/pc-dimm.c
index d431834..3b8a015 100644
--- a/hw/mem/pc-dimm.c
+++ b/hw/mem/pc-dimm.c
@@ -161,9 +161,9 @@ uint64_t pc_dimm_get_free_addr(uint64_t
address_space_start,
goto out;
}
-if (QEMU_ALIGN_UP(size, align) != size) {
+if (QEMU_ALIGN_UP(size, align * 64) != size) {
error_setg(errp, backend memory size must be multiple of 0x%
- PRIx64, align);
+ PRIx64, align * 64);
goto out;
}
Re: [Qemu-devel] [PATCH] Add 'setup' phase to docs for query-migrate QMP command
On (Mon) 15 Dec 2014 [10:05:40], Markus Armbruster wrote:
Copying migration maintainers.
Thanks, Eric, pls give this a look too.
Alex Bligh a...@alex.org.uk writes:
The QMP command 'query-migrate' returns the state 'setup' during
the setup phase. This patch documents it.
Signed-off-by: Alex Bligh a...@alex.org.uk
---
qmp-commands.hx | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 3348782..e9cff2c 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -3092,7 +3092,12 @@ Examples:
- { execute: query-migrate }
- { return: { status: failed } }
-4. Migration is being performed and is not a block migration:
+4. Migration has been requested but is still in setup phase
+
+- { execute: query-migrate }
+- { return: { status: setup } }
+
+5. Migration is being performed and is not a block migration:
- { execute: query-migrate }
- {
@@ -3113,7 +3118,7 @@ Examples:
}
}
-5. Migration is being performed and is a block migration:
+6. Migration is being performed and is a block migration:
- { execute: query-migrate }
- {
@@ -3139,7 +3144,7 @@ Examples:
}
}
-6. Migration is being performed and XBZRLE is active:
+7. Migration is being performed and XBZRLE is active:
- { execute: query-migrate }
- {
Amit
Re: [Qemu-devel] [PATCH v4 01/17] docs: add sPAPR hotplug/dynamic-reconfiguration documentation
On Tue, Dec 23, 2014 at 06:30:15AM -0600, Michael Roth wrote: This adds a general overview of hotplug/dynamic-reconfiguration for sPAPR/pSeries guest. As specified in PAPR+ v2.7. Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com --- docs/specs/ppc-spapr-hotplug.txt | 287 +++ 1 file changed, 287 insertions(+) create mode 100644 docs/specs/ppc-spapr-hotplug.txt diff --git a/docs/specs/ppc-spapr-hotplug.txt b/docs/specs/ppc-spapr-hotplug.txt new file mode 100644 index 000..6f2863f --- /dev/null +++ b/docs/specs/ppc-spapr-hotplug.txt @@ -0,0 +1,287 @@ += sPAPR Dynamic Reconfiguration = + +sPAPR/pseries guests make use a facility called dynamic-reconfiguration to +handle hotplugging of dynamic physical resources like PCI cards, or +logical/paravirtual resources like memory, CPUs, and physical +host-bridges, which are generally managed by the host/hypervisor and provided +to guests as virtualized resources. The specifics of dynamic-reconfiguration +are documented extensively in PAPR+ v2.7, Section 13.1. This document +provides a summary of that information as it applies to the implementation +within QEMU. + +== Dynamic-reconfiguration Connectors == + +To manage hotplug/unplug of these resources, a firmware abstraction known as +a Dynamic Resource Connector (DRC) is used to assign a particular dynamic +resource to the guest, and provide an interface for the guest to manage +configuration/removal of the resource associated with it. + +== Device-tree description of DRCs == + +A set of 4 array Open Firmware device tree properties are used to describe +the name/index/power-domain/type of each DRC allocated to a guest at +boot-time. There may be multiple sets of these arrays, rooted at different +paths in the device tree depending on the type of resource the DRCs manage. + +In some cases, the DRCs themselves may be provided by a dynamic resource, +such as the DRCs managed PCI slots on a hotplugged PHB. In this case the +arrays would be fetched as part of the device tree retrieval interfaces +for hotplugged resources described under Guest-Host interface. + +The array properties are described below. Each entry/element in an array +describes the DRC identified by the element in the corresponding position +of ibm,drc-indexes: + +ibm,drc-names: + first 4-bytes: BE-encoded integer denoting the number of entries + each entry: a NULL-terminated name string encoded as a byte array + + name values for logical/virtual resources are defined in PAPR+ v2.7, + Section 13.5.2.4, and basically consist of the type of the resource + followed by a space and a numerical value that's unique across resources + of that type. + + name values for physical resources such as PCI or VIO devices are + defined as being location codes, which are the location labels of + each encapsulating device, starting from the chassis down to the + individual slot for the device, concatenated by a hyphen. This provides + a mapping of resources to a physical location in a chassis for debugging + purposes. For QEMU, this mapping is less important, so we assign a + location code that confirms to naming specifications, but is simply a s/confirms/conforms/ Otherwise, nice write up. Reviewed-by: David Gibson da...@gibson.dropbear.id.au -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson pgpkgCFi9ikTL.pgp Description: PGP signature
Re: [Qemu-devel] [PATCH v4 02/17] spapr_drc: initial implementation of sPAPRDRConnector device
On Tue, Dec 23, 2014 at 06:30:16AM -0600, Michael Roth wrote:
This device emulates a firmware abstraction used by pSeries guests to
manage hotplug/dynamic-reconfiguration of host-bridges, PCI devices,
memory, and CPUs. It is conceptually similar to an SHPC device,
complete with LED indicators to identify individual slots to physical
physical users and indicate when it is safe to remove a device. In
some cases it is also used to manage virtualized resources, such a
memory, CPUs, and physical-host bridges, which in the case of pSeries
guests are virtualized resources where the physical components are
managed by the host.
Guests communicate with these DR Connectors using RTAS calls,
generally by addressing the unique DRC index associated with a
particular connector for a particular resource. For introspection
purposes we expose this state initially as QOM properties, and
in subsequent patches will introduce the RTAS calls that make use of
it. This constitutes to the 'guest' interface.
On the QEMU side we provide an attach/detach interface to associate
or cleanup a DeviceState with a particular sPAPRDRConnector in
response to hotplug/unplug, respectively. This constitutes the
'physical' interface to the DR Connector.
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
hw/ppc/Makefile.objs | 2 +-
hw/ppc/spapr_drc.c | 503
+
include/hw/ppc/spapr_drc.h | 201 ++
3 files changed, 705 insertions(+), 1 deletion(-)
create mode 100644 hw/ppc/spapr_drc.c
create mode 100644 include/hw/ppc/spapr_drc.h
diff --git a/hw/ppc/Makefile.objs b/hw/ppc/Makefile.objs
index 19d9920..ea010fd 100644
--- a/hw/ppc/Makefile.objs
+++ b/hw/ppc/Makefile.objs
@@ -3,7 +3,7 @@ obj-y += ppc.o ppc_booke.o
# IBM pSeries (sPAPR)
obj-$(CONFIG_PSERIES) += spapr.o spapr_vio.o spapr_events.o
obj-$(CONFIG_PSERIES) += spapr_hcall.o spapr_iommu.o spapr_rtas.o
-obj-$(CONFIG_PSERIES) += spapr_pci.o
+obj-$(CONFIG_PSERIES) += spapr_pci.o spapr_drc.o
ifeq ($(CONFIG_PCI)$(CONFIG_PSERIES)$(CONFIG_LINUX), yyy)
obj-y += spapr_pci_vfio.o
endif
diff --git a/hw/ppc/spapr_drc.c b/hw/ppc/spapr_drc.c
new file mode 100644
index 000..f81c6d1
--- /dev/null
+++ b/hw/ppc/spapr_drc.c
@@ -0,0 +1,503 @@
+/*
+ * QEMU SPAPR Dynamic Reconfiguration Connector Implementation
+ *
+ * Copyright IBM Corp. 2014
+ *
+ * Authors:
+ * Michael Roth mdr...@linux.vnet.ibm.com
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include hw/ppc/spapr_drc.h
+#include qom/object.h
+#include hw/qdev.h
+#include qapi/visitor.h
+#include qemu/error-report.h
+
+/* #define DEBUG_SPAPR_DRC */
+
+#ifdef DEBUG_SPAPR_DRC
+#define DPRINTF(fmt, ...) \
+do { fprintf(stderr, fmt, ## __VA_ARGS__); } while (0)
+#define DPRINTFN(fmt, ...) \
+do { DPRINTF(fmt, ## __VA_ARGS__); fprintf(stderr, \n); } while (0)
+#else
+#define DPRINTF(fmt, ...) \
+do { } while (0)
+#define DPRINTFN(fmt, ...) \
+do { } while (0)
+#endif
+
+#define DRC_CONTAINER_PATH /dr-connector
+#define DRC_INDEX_TYPE_SHIFT 28
+#define DRC_INDEX_ID_MASK ~(~0 DRC_INDEX_TYPE_SHIFT)
I'm not sure if there are actually any situations where it can break,
but safest to put parens around the whole macro body, just in case of
macro vs. precedence weirdness.
+static int set_isolation_state(sPAPRDRConnector *drc,
+ sPAPRDRIsolationState state)
+{
+sPAPRDRConnectorClass *drck = SPAPR_DR_CONNECTOR_GET_CLASS(drc);
+
+DPRINTFN(set_isolation_state: %x, state);
+drc-isolation_state = state;
+if (drc-awaiting_release
+drc-isolation_state == SPAPR_DR_ISOLATION_STATE_ISOLATED) {
+drck-detach(drc, DEVICE(drc-dev), drc-detach_cb,
+ drc-detach_cb_opaque);
+}
+return 0;
+}
+
+static int set_indicator_state(sPAPRDRConnector *drc,
+ sPAPRDRIndicatorState state)
+{
+DPRINTFN(set_indicator_state: %x, state);
+drc-indicator_state = state;
+return 0;
+}
+
+static int set_allocation_state(sPAPRDRConnector *drc,
+sPAPRDRAllocationState state)
+{
+DPRINTFN(set_allocation_state: %x, state);
+drc-indicator_state = state;
This should be drc-allocation_state, surely.
+return 0;
+}
+
+static uint32_t get_id(sPAPRDRConnector *drc)
+{
+/* this value is unique for DRCs of a particular type, but may
+ * overlap with the id's of other DRCs. the value is used both
+ * to calculate a unique (across all DRC types) index, as well
+ * as generating the ibm,drc-names OFDT property that describes
+ * DRCs
+ */
+return drc-id;
+}
Since this is static anyway, why not just reference drc-id directly?
+static sPAPRDRConnectorTypeShift
Re: [Qemu-devel] [PATCH v4 03/17] spapr_rtas: add get/set-power-level RTAS interfaces
On Tue, Dec 23, 2014 at 06:30:17AM -0600, Michael Roth wrote:
From: Nathan Fontenot nf...@linux.vnet.ibm.com
Signed-off-by: Nathan Fontenot nf...@linux.vnet.ibm.com
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
hw/ppc/spapr_rtas.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/hw/ppc/spapr_rtas.c b/hw/ppc/spapr_rtas.c
index 2ec2a8e..a2fb533 100644
--- a/hw/ppc/spapr_rtas.c
+++ b/hw/ppc/spapr_rtas.c
@@ -290,6 +290,27 @@ static void rtas_ibm_os_term(PowerPCCPU *cpu,
rtas_st(rets, 0, ret);
}
+static void rtas_set_power_level(PowerPCCPU *cpu, sPAPREnvironment *spapr,
+ uint32_t token, uint32_t nargs,
+ target_ulong args, uint32_t nret,
+ target_ulong rets)
+{
+/* we currently only use a single, live insert powerdomain for
+ * hotplugged/dlpar'd resources, so the power is always live/full (100)
+ */
Even so, you should at least validate the number of args and rets, and
preferably check that the user isn't attempt to set something for some
other, non-existent power domain.
+rtas_st(rets, 0, RTAS_OUT_SUCCESS);
+rtas_st(rets, 1, 100);
+}
+
+static void rtas_get_power_level(PowerPCCPU *cpu, sPAPREnvironment *spapr,
+ uint32_t token, uint32_t nargs,
+ target_ulong args, uint32_t nret,
+ target_ulong rets)
+{
+rtas_st(rets, 0, RTAS_OUT_SUCCESS);
+rtas_st(rets, 1, 100);
+}
+
static struct rtas_call {
const char *name;
spapr_rtas_fn fn;
@@ -419,6 +440,10 @@ static void core_rtas_register_types(void)
rtas_ibm_set_system_parameter);
spapr_rtas_register(RTAS_IBM_OS_TERM, ibm,os-term,
rtas_ibm_os_term);
+spapr_rtas_register(RTAS_SET_POWER_LEVEL, set-power-level,
+rtas_set_power_level);
+spapr_rtas_register(RTAS_GET_POWER_LEVEL, get-power-level,
+rtas_get_power_level);
}
type_init(core_rtas_register_types)
This code should probably go in spapr_drc.c. The idea that spapr_rtas
was just the RTAS dispatch code, and RTAS functions that had no other
home. Generally RTAS functions should live with the devices they're
connected to.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
pgpn6a6hXnB0r.pgp
Description: PGP signature
Re: [Qemu-devel] [PATCH v4 04/17] spapr_rtas: add set-indicator RTAS interface
On Tue, Dec 23, 2014 at 06:30:18AM -0600, Michael Roth wrote:
From: Mike Day ncm...@ncultra.org
Signed-off-by: Mike Day ncm...@ncultra.org
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
hw/ppc/spapr_rtas.c | 80
+
1 file changed, 80 insertions(+)
diff --git a/hw/ppc/spapr_rtas.c b/hw/ppc/spapr_rtas.c
index a2fb533..6aa325f 100644
--- a/hw/ppc/spapr_rtas.c
+++ b/hw/ppc/spapr_rtas.c
@@ -35,6 +35,18 @@
#include qapi-event.h
#include libfdt.h
+#include hw/ppc/spapr_drc.h
+
+/* #define DEBUG_SPAPR */
+
+#ifdef DEBUG_SPAPR
+#define DPRINTF(fmt, ...) \
+do { fprintf(stderr, fmt, ## __VA_ARGS__); } while (0)
+#else
+#define DPRINTF(fmt, ...) \
+do { } while (0)
+#endif
+
static void rtas_display_character(PowerPCCPU *cpu, sPAPREnvironment *spapr,
uint32_t token, uint32_t nargs,
@@ -311,6 +323,72 @@ static void rtas_get_power_level(PowerPCCPU *cpu,
sPAPREnvironment *spapr,
rtas_st(rets, 1, 100);
}
+/*
+ * indicator/sensor types
+ * as defined by PAPR+ 2.7 7.3.5.4, Table 41
+ *
+ * NOTE: currently only DR-related sensors are implemented here
+ */
+#define RTAS_SENSOR_TYPE_ISOLATION_STATE 9001
+#define RTAS_SENSOR_TYPE_DR 9002
+#define RTAS_SENSOR_TYPE_ALLOCATION_STATE 9003
+#define RTAS_SENSOR_TYPE_ENTITY_SENSE RTAS_SENSOR_TYPE_ALLOCATION_STATE
These should probably go in a header.
+static bool sensor_type_is_dr(uint32_t sensor_type)
+{
+switch (sensor_type) {
+case RTAS_SENSOR_TYPE_ISOLATION_STATE:
+case RTAS_SENSOR_TYPE_DR:
+case RTAS_SENSOR_TYPE_ALLOCATION_STATE:
+return true;
+}
+
+return false;
+}
+
+static void rtas_set_indicator(PowerPCCPU *cpu, sPAPREnvironment *spapr,
+ uint32_t token, uint32_t nargs,
+ target_ulong args, uint32_t nret,
+ target_ulong rets)
+{
+uint32_t sensor_type = rtas_ld(args, 0);
+uint32_t sensor_index = rtas_ld(args, 1);
+uint32_t sensor_state = rtas_ld(args, 2);
You must validate nargs anr nret before reading the RTAS parameters.
+sPAPRDRConnector *drc;
+sPAPRDRConnectorClass *drck;
+
+if (sensor_type_is_dr(sensor_type)) {
+/* if this is a DR sensor we can assume sensor_index == drc_index */
+drc = spapr_dr_connector_by_index(sensor_index);
+drck = SPAPR_DR_CONNECTOR_GET_CLASS(drc);
I'd reverse the sense of the if, and move these initializations after
the if. That makes it more obvious that these can't be uninitialized
when you use them below.
+} else {
+/* currently only DR-related sensors are implemented */
+goto out_unimplemented;
+}
+
+switch (sensor_type) {
+case RTAS_SENSOR_TYPE_ISOLATION_STATE:
+drck-set_isolation_state(drc, sensor_state);
+break;
+case RTAS_SENSOR_TYPE_DR:
+drck-set_indicator_state(drc, sensor_state);
+break;
+case RTAS_SENSOR_TYPE_ALLOCATION_STATE:
+drck-set_allocation_state(drc, sensor_state);
+break;
+default:
+goto out_unimplemented;
+}
+
+rtas_st(rets, 0, RTAS_OUT_SUCCESS);
+return;
+
+out_unimplemented:
+DPRINTF(rtas_set_indicator: sensor/indicator not implemented: %d\n,
+sensor_type);
+rtas_st(rets, 0, RTAS_OUT_PARAM_ERROR);
+}
+
static struct rtas_call {
const char *name;
spapr_rtas_fn fn;
@@ -444,6 +522,8 @@ static void core_rtas_register_types(void)
rtas_set_power_level);
spapr_rtas_register(RTAS_GET_POWER_LEVEL, get-power-level,
rtas_get_power_level);
+spapr_rtas_register(RTAS_SET_INDICATOR, set-indicator,
+rtas_set_indicator);
}
type_init(core_rtas_register_types)
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
pgpFvm3KIE2Xb.pgp
Description: PGP signature
Re: [Qemu-devel] [PATCH v4 05/17] spapr_rtas: add get-sensor-state RTAS interface
On Tue, Dec 23, 2014 at 06:30:19AM -0600, Michael Roth wrote:
From: Mike Day ncm...@ncultra.org
Even simple patches should have commit messages.
Signed-off-by: Mike Day ncm...@ncultra.org
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
hw/ppc/spapr_rtas.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/hw/ppc/spapr_rtas.c b/hw/ppc/spapr_rtas.c
index 6aa325f..13e6e55 100644
--- a/hw/ppc/spapr_rtas.c
+++ b/hw/ppc/spapr_rtas.c
@@ -389,6 +389,39 @@ out_unimplemented:
rtas_st(rets, 0, RTAS_OUT_PARAM_ERROR);
}
+static void rtas_get_sensor_state(PowerPCCPU *cpu, sPAPREnvironment *spapr,
+ uint32_t token, uint32_t nargs,
+ target_ulong args, uint32_t nret,
+ target_ulong rets)
+{
+uint32_t sensor_type = rtas_ld(args, 0);
+uint32_t sensor_index = rtas_ld(args, 1);
Need to validate nargs and nret first.
+sPAPRDRConnector *drc;
+sPAPRDRConnectorClass *drck;
+uint32_t entity_sense;
+
+if (sensor_type != RTAS_SENSOR_TYPE_ENTITY_SENSE) {
+/* currently only DR-related sensors are implemented */
+DPRINTF(rtas_get_sensor_state: sensor/indicator not implemented:
%d\n,
+sensor_type);
+rtas_st(rets, 0, RTAS_OUT_NOT_SUPPORTED);
I think your previous patch used RTAS_OUT_PARAM_ERROR instead of
RTAS_OUT_NOT_SUPORTED in the case of an unsupported indicator type. I
imagine these should be consistent.
+return;
+}
+
+drc = spapr_dr_connector_by_index(sensor_index);
+if (!drc) {
+DPRINTF(rtas_get_sensor_state: invalid sensor/DRC index: %xh\n,
+sensor_index);
+rtas_st(rets, 0, RTAS_OUT_PARAM_ERROR);
+return;
+}
+drck = SPAPR_DR_CONNECTOR_GET_CLASS(drc);
+entity_sense = drck-entity_sense(drc);
+
+rtas_st(rets, 0, RTAS_OUT_SUCCESS);
+rtas_st(rets, 1, entity_sense);
+}
+
static struct rtas_call {
const char *name;
spapr_rtas_fn fn;
@@ -524,6 +557,8 @@ static void core_rtas_register_types(void)
rtas_get_power_level);
spapr_rtas_register(RTAS_SET_INDICATOR, set-indicator,
rtas_set_indicator);
+spapr_rtas_register(RTAS_GET_SENSOR_STATE, get-sensor-state,
+rtas_get_sensor_state);
}
type_init(core_rtas_register_types)
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
pgpX1XLRuWJ9t.pgp
Description: PGP signature
Re: [Qemu-devel] [RFC PATCH v7 21/21] replay: recording of the user input
From: Paolo Bonzini [mailto:pbonz...@redhat.com]
On 12/01/2015 13:01, Pavel Dovgalyuk wrote:
+void qemu_input_event_send(QemuConsole *src, InputEvent *evt)
{
-QemuInputHandlerState *s;
-
if (!runstate_is_running() !runstate_check(RUN_STATE_SUSPENDED)) {
return;
}
+if (replay_mode == REPLAY_MODE_PLAY) {
+/* Nothing */
+} else if (replay_mode == REPLAY_MODE_RECORD) {
+replay_add_input_event(evt);
+} else {
+qemu_input_event_send_impl(src, evt);
+}
Similar to other cases, please wrap this into a single function,
something like
if (replay_handle_input_event(evt)) {
return;
}
/* ... original contents of qemu_input_event_send ... */
I can wrap this, but cannot get rid of _impl function.
In replay mode we have to make two things:
- Deny real user imput (qemu_input_event_send should do nothing)
- Read input from the log (qemu_input_event_send should process read data)
Pavel Dovgalyuk
Re: [Qemu-devel] global_mutex and multithread.
On 15 Jan 2015, at 22:41, Paolo Bonzini pbonz...@redhat.com wrote: On 15/01/2015 21:53, Mark Burton wrote: Jan said he had it working at least on ARM (MusicPal). yeah - our problem is when we enable multi-threads - which I dont believe Jan did… Multithreaded TCG, or single-threaded TCG with SMP? He mentions SMP, - I assume thats single-threaded …. One thing I wonder - why do we need to go to the extent of mutexing in the TCG like this? Why can’t you simply put a mutex get/release on the slow path? If the core is going to do ‘fast path’ access to the memory, - even if that memory was IO mapped - would it matter if it didn’t have the mutex? Because there is no guarantee that the memory map isn't changed by a core under the feet of another. The TLB (in particular the iotlb) is only valid with reference to a particular memory map. Changes to the memory map certainly happen in the slow path, but lookups are part of the fast path. Even an rwlocks is too slow for a fast path, hence the plan of going with RCU. Could we arrange the world such that lookups ‘succeed’ (the wheels dont fall off) -ether getting the old value, or the new, but not getting rubbish - and we still only take the mutex if we are going to make alterations to the MM itself? (I have’t looked at the code around that… so sorry if the question is ridiculous). That's the definition of RCU. :) Look at the docs in http://permalink.gmane.org/gmane.comp.emulators.qemu/313929 for more information. :) Ahh - I see ! It's still not trivial to make it 100% correct, but at the same time it's not too hard to prepare something decent to play with. Also, most of the work can be done with KVM so it's more or less independent from what you guys have been doing so far. Yes - the issue is if we end up relying on it. But - I see what you mean - these 2 things can ‘dovetail’ together “independently” - so - Jan’s patch will be good for now, and then later we can use RCU to make it work more generally (and more efficiently). So - our only small problem is getting Jan’s patch to work for multi-thread :-)) Cheers Mark. Paolo +44 (0)20 7100 3485 x 210 +33 (0)5 33 52 01 77x 210 +33 (0)603762104 mark.burton
[Qemu-devel] [PULL] migration patches
The following changes since commit df58887b20fab8fe8a6dcca4db30cd4e4077d53a: Merge remote-tracking branch 'remotes/mjt/tags/pull-trivial-patches-2015-01-15' into staging (2015-01-15 10:08:46 +) are available in the git repository at: git://git.kernel.org/pub/scm/virt/qemu/amit/migration.git tags/mig-2.3-1 for you to fetch changes up to ea987c2c21d4326bb58ee28f6888fdcf8fbda067: vmstate: type-check sub-arrays (2015-01-16 13:06:17 +0530) A set of patches collected over the holidays. Mix of optimizations and fixes. ChenLiang (2): xbzrle: optimize XBZRLE to decrease the cache misses xbzrle: rebuild the cache_is_cached function Cristian Klein (1): Handle bi-directional communication for fd migration Dr. David Alan Gilbert (2): socket shutdown migration_cancel: shutdown migration socket Paolo Bonzini (1): vmstate: type-check sub-arrays Yang Hongyang (2): QEMUSizedBuffer: only free qsb that qemu_bufopen allocated Tests: QEMUSizedBuffer/QEMUBuffer arch_init.c| 8 +--- docs/xbzrle.txt| 8 include/migration/page_cache.h | 10 +++--- include/migration/qemu-file.h | 10 ++ include/migration/vmstate.h| 2 +- include/qemu/sockets.h | 7 +++ migration/fd.c | 24 +-- migration/migration.c | 12 migration/qemu-file-buf.c | 10 ++ migration/qemu-file-unix.c | 23 ++ migration/qemu-file.c | 12 page_cache.c | 43 +- tests/test-vmstate.c | 20 13 files changed, 143 insertions(+), 46 deletions(-) Amit
Re: [Qemu-devel] [PATCH 1/4] configure: opengl overhaul
On 2015-01-12 at 07:35, Gerd Hoffmann wrote:
Rename config option from glx to opengl, glx will not be the only
option for opengl in near future. Also switch over to pkg-config for
opengl support detection.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
configure| 39 +--
default-configs/lm32-softmmu.mak | 2 +-
hw/display/Makefile.objs | 2 +-
hw/lm32/milkymist-hw.h | 4 ++--
include/sysemu/sysemu.h | 1 +
vl.c | 1 +
6 files changed, 23 insertions(+), 26 deletions(-)
diff --git a/configure b/configure
index cae588c..ee1693b 100755
--- a/configure
+++ b/configure
@@ -309,7 +309,7 @@ rbd=
smartcard_nss=
libusb=
usb_redir=
-glx=
+opengl=
zlib=yes
lzo=
snappy=
@@ -1026,9 +1026,9 @@ for opt do
;;
--enable-vhost-scsi) vhost_scsi=yes
;;
- --disable-glx) glx=no
+ --disable-opengl) opengl=no
;;
- --enable-glx) glx=yes
+ --enable-opengl) opengl=yes
;;
--disable-rbd) rbd=no
;;
@@ -3056,23 +3056,18 @@ fi
libs_softmmu=$libs_softmmu $fdt_libs
##
-# GLX probe, used by milkymist-tmu2
-if test $glx != no ; then
- glx_libs=-lGL -lX11
- cat $TMPC EOF
-#include X11/Xlib.h
-#include GL/gl.h
-#include GL/glx.h
-int main(void) { glBegin(0); glXQueryVersion(0,0,0); return 0; }
-EOF
- if compile_prog -lGL -lX11 ; then
-glx=yes
+# opengl probe, used by milkymist-tmu2
Maybe remove this part of the comment about milkymist?
+if test $opengl != no ; then
+ opengl_pkgs=gl
+ if $pkg_config $opengl_pkgs; then
+opengl_libs=$($pkg_config --libs $opengl_pkgs) -lX11
+opengl=yes
`pkg-config gl` might be successful even without X11 available. In this
case, $opengl will be set to 'yes', but linking will probably fail.
Maybe we should keep GLX separated from OpenGL; for SDL we don't need
X11, but for milkymist-tmu2 we apparently do.
Max
else
-if test $glx = yes ; then
- feature_not_found glx Install GL devel (e.g. MESA)
+if test $opengl = yes ; then
+ feature_not_found opengl Install GL devel (e.g. MESA)
fi
-glx_libs=
-glx=no
+opengl_libs=
+opengl=no
fi
fi
@@ -4320,7 +4315,7 @@ echo xfsctl support$xfs
echo nss used $smartcard_nss
echo libusb$libusb
echo usb net redir $usb_redir
-echo GLX support $glx
+echo OpenGL support$opengl
echo libiscsi support $libiscsi
echo libnfs support$libnfs
echo build guest agent $guest_agent
@@ -4682,9 +4677,9 @@ if test $usb_redir = yes ; then
echo CONFIG_USB_REDIR=y $config_host_mak
fi
-if test $glx = yes ; then
- echo CONFIG_GLX=y $config_host_mak
- echo GLX_LIBS=$glx_libs $config_host_mak
+if test $opengl = yes ; then
+ echo CONFIG_OPENGL=y $config_host_mak
+ echo OPENGL_LIBS=$opengl_libs $config_host_mak
fi
if test $lzo = yes ; then
diff --git a/default-configs/lm32-softmmu.mak b/default-configs/lm32-softmmu.mak
index 7df58c8..4889348 100644
--- a/default-configs/lm32-softmmu.mak
+++ b/default-configs/lm32-softmmu.mak
@@ -2,7 +2,7 @@
CONFIG_LM32=y
CONFIG_MILKYMIST=y
-CONFIG_MILKYMIST_TMU2=$(CONFIG_GLX)
+CONFIG_MILKYMIST_TMU2=$(CONFIG_OPENGL)
CONFIG_FRAMEBUFFER=y
CONFIG_PTIMER=y
CONFIG_PFLASH_CFI01=y
diff --git a/hw/display/Makefile.objs b/hw/display/Makefile.objs
index 7ed76a9..e18ea57 100644
--- a/hw/display/Makefile.objs
+++ b/hw/display/Makefile.objs
@@ -20,7 +20,7 @@ common-obj-$(CONFIG_ZAURUS) += tc6393xb.o
ifeq ($(CONFIG_MILKYMIST_TMU2),y)
common-obj-y += milkymist-tmu2.o
-libs_softmmu += $(GLX_LIBS)
+libs_softmmu += $(OPENGL_LIBS)
endif
obj-$(CONFIG_OMAP) += omap_dss.o
diff --git a/hw/lm32/milkymist-hw.h b/hw/lm32/milkymist-hw.h
index 5317ce6..8d20cac 100644
--- a/hw/lm32/milkymist-hw.h
+++ b/hw/lm32/milkymist-hw.h
@@ -86,7 +86,7 @@ static inline DeviceState *milkymist_pfpu_create(hwaddr base,
return dev;
}
-#ifdef CONFIG_GLX
+#ifdef CONFIG_OPENGL
#include X11/Xlib.h
#include GL/glx.h
static const int glx_fbconfig_attr[] = {
@@ -100,7 +100,7 @@ static const int glx_fbconfig_attr[] = {
static inline DeviceState *milkymist_tmu2_create(hwaddr base,
qemu_irq irq)
{
-#ifdef CONFIG_GLX
+#ifdef CONFIG_OPENGL
DeviceState *dev;
Display *d;
GLXFBConfig *configs;
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index 503e5a4..e5c91eb 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -117,6 +117,7 @@ extern int graphic_width;
extern int graphic_height;
extern int graphic_depth;
extern DisplayType display_type;
+extern int display_opengl;
extern const char *keyboard_layout;
extern int win2k_install_hack;
extern int alt_grab;
diff --git a/vl.c b/vl.c
index bea9656..06e8f44 100644
--- a/vl.c
+++ b/vl.c
@@ -129,6 +129,7 @@ static int data_dir_idx;
const char *bios_name = NULL;
enum
Re: [Qemu-devel] global_mutex and multithread.
On 15/01/2015 21:53, Mark Burton wrote: Jan said he had it working at least on ARM (MusicPal). yeah - our problem is when we enable multi-threads - which I dont believe Jan did… Multithreaded TCG, or single-threaded TCG with SMP? One thing I wonder - why do we need to go to the extent of mutexing in the TCG like this? Why can’t you simply put a mutex get/release on the slow path? If the core is going to do ‘fast path’ access to the memory, - even if that memory was IO mapped - would it matter if it didn’t have the mutex? Because there is no guarantee that the memory map isn't changed by a core under the feet of another. The TLB (in particular the iotlb) is only valid with reference to a particular memory map. Changes to the memory map certainly happen in the slow path, but lookups are part of the fast path. Even an rwlocks is too slow for a fast path, hence the plan of going with RCU. Could we arrange the world such that lookups ‘succeed’ (the wheels dont fall off) -ether getting the old value, or the new, but not getting rubbish - and we still only take the mutex if we are going to make alterations to the MM itself? (I have’t looked at the code around that… so sorry if the question is ridiculous). That's the definition of RCU. :) Look at the docs in http://permalink.gmane.org/gmane.comp.emulators.qemu/313929 for more information. :) It's still not trivial to make it 100% correct, but at the same time it's not too hard to prepare something decent to play with. Also, most of the work can be done with KVM so it's more or less independent from what you guys have been doing so far. Paolo
Re: [Qemu-devel] global_mutex and multithread.
On 15/01/2015 21:53, Mark Burton wrote: Jan said he had it working at least on ARM (MusicPal). yeah - our problem is when we enable multi-threads - which I dont believe Jan did… Multithreaded TCG, or single-threaded TCG with SMP? One thing I wonder - why do we need to go to the extent of mutexing in the TCG like this? Why can’t you simply put a mutex get/release on the slow path? If the core is going to do ‘fast path’ access to the memory, - even if that memory was IO mapped - would it matter if it didn’t have the mutex? Because there is no guarantee that the memory map isn't changed by a core under the feet of another. The TLB (in particular the iotlb) is only valid with reference to a particular memory map. Changes to the memory map certainly happen in the slow path, but lookups are part of the fast path. Even an rwlocks is too slow for a fast path, hence the plan of going with RCU. Could we arrange the world such that lookups ‘succeed’ (the wheels dont fall off) -ether getting the old value, or the new, but not getting rubbish - and we still only take the mutex if we are going to make alterations to the MM itself? (I have’t looked at the code around that… so sorry if the question is ridiculous). That's the definition of RCU. :) Look at the docs in http://permalink.gmane.org/gmane.comp.emulators.qemu/313929 for more information. :) It's still not trivial to make it 100% correct, but at the same time it's not too hard to prepare something decent to play with. Also, most of the work can be done with KVM so it's more or less independent from what you guys have been doing so far. Paolo
[Qemu-devel] [PATCH v2] qemu-iotests: Fix supported_oses check
There is a bug in the recently added sys.platform test, and we no longer
run python tests, because linux2 is the value to compare here. So do a
prefix match. According to python doc [1], the way to use sys.platform
is unless you want to test for a specific system version, it is
therefore recommended to use the following idiom:
if sys.platform.startswith('freebsd'):
# FreeBSD-specific code here...
elif sys.platform.startswith('linux'):
# Linux-specific code here...
[1]: https://docs.python.org/2.7/library/sys.html#sys.platform
Signed-off-by: Fam Zheng f...@redhat.com
---
v2: Don't use any().
Explain why prefix match is fine.
(Thanks, Stefan)
---
tests/qemu-iotests/iotests.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
index 87002e0..241b5ee 100644
--- a/tests/qemu-iotests/iotests.py
+++ b/tests/qemu-iotests/iotests.py
@@ -288,7 +288,7 @@ def main(supported_fmts=[], supported_oses=['linux']):
if supported_fmts and (imgfmt not in supported_fmts):
notrun('not suitable for this image format: %s' % imgfmt)
-if sys.platform not in supported_oses:
+if True not in [sys.platform.startswith(x) for x in supported_oses]:
notrun('not suitable for this OS: %s' % sys.platform)
# We need to filter out the time taken from the output so that qemu-iotest
--
1.9.3
Re: [Qemu-devel] [PATCH 3/8] rcu: add rcutorture
On Tue, 01/13 18:52, Paolo Bonzini wrote:
+int main(int argc, char *argv[])
+{
+int nreaders = 1;
+int duration = 1;
+
+if (argc = 2 argv[1][0] == '-') {
+g_test_init(argc, argv, NULL);
+g_test_add_func(/rcu/torture/short/1reader, gtest_stress_1_1);
+g_test_add_func(/rcu/torture/short/10readers, gtest_stress_10_1);
+g_test_add_func(/rcu/torture/long/1reader, gtest_stress_1_5);
+g_test_add_func(/rcu/torture/long/10readers, gtest_stress_10_5);
Why do we need short tests when we have long tests? What are different other
than the durations?
+return g_test_run();
+}
+
+if (argc = 2) {
+nreaders = strtoul(argv[1], NULL, 0);
+}
+if (argc 3) {
+duration = strtoul(argv[3], NULL, 0);
+}
+if (argc 3 || strcmp(argv[2], stress) == 0) {
+stresstest(nreaders, duration);
+} else if (strcmp(argv[2], rperf) == 0) {
+rperftest(nreaders, duration);
+} else if (strcmp(argv[2], uperf) == 0) {
+uperftest(nreaders, duration);
+} else if (strcmp(argv[2], perf) == 0) {
+perftest(nreaders, duration);
+}
+usage(argc, argv);
+return 0;
+}
diff --git a/util/rcu.c b/util/rcu.c
index f8f52ae..8df16d9 100644
--- a/util/rcu.c
+++ b/util/rcu.c
@@ -169,5 +169,4 @@ static void __attribute__((__constructor__))
rcu_init(void)
{
qemu_mutex_init(rcu_gp_lock);
qemu_event_init(rcu_gp_event, true);
-rcu_register_thread();
Maybe don't add this line in patch 2?
Fam
[Qemu-devel] [PATCH v3 0/2] buildsys: Fix and enable module build
v3: Fix commit message, error message and function name. (Stefan) Fam Zheng (2): configure: Default to enable module build .travis.yml: Add --disable-modules .travis.yml | 3 ++ configure | 95 ++--- 2 files changed, 69 insertions(+), 29 deletions(-) -- 1.9.3
[Qemu-devel] [PATCH v3 2/2] .travis.yml: Add --disable-modules
Now we default to --enable-modules, let's cover the old way in travis. Signed-off-by: Fam Zheng f...@redhat.com --- .travis.yml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/.travis.yml b/.travis.yml index ad66e5b..12bf1db 100644 --- a/.travis.yml +++ b/.travis.yml @@ -98,3 +98,6 @@ matrix: EXTRA_PKGS=liblttng-ust-dev liburcu-dev EXTRA_CONFIG=--enable-trace-backends=ust compiler: gcc +- env: TARGETS=i386-softmmu,x86_64-softmmu + EXTRA_CONFIG=--disable-modules + compiler: gcc -- 1.9.3
Re: [Qemu-devel] [PATCH v3] spapr-pci: Enable huge BARs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/14/2015 03:51 PM, David Gibson wrote:
On Fri, Jan 09, 2015 at 12:11:14PM +1100, Alexey Kardashevskiy wrote:
At the moment sPAPR only supports 512MB window for MMIO BARs.
However modern devices might want bigger 64bit BARs.
This extends MMIO window from 512MB to 62GB (aligned to
SPAPR_PCI_WINDOW_SPACING) and advertises it in 2 records in the PHB
ranges property. 32bit gets the space from
SPAPR_PCI_MEM_WIN_BUS_OFFSET till the end of 4GB, 64bit gets the
rest of the space.
The approach changes the device tree which is a guest visible
change, however it won't break migration as: 1. we do not support
migration to older QEMU versions 2. migration to newer QEMU will
migrate the device tree as well and since the new layout only
extends the old one and does not change address mappigns, no
breakage is expected here too.
SLOF change is required to utilize this extension.
Suggested-by: Benjamin Herrenschmidt b...@kernel.crashing.org
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru --- Changes:
v3: * used SPAPR_PCI_WINDOW_SPACING in SPAPR_PCI_MMIO_WIN_SIZE *
extended commit log
v2: * do not change existing memory layout * do not create another
mmio window --- hw/ppc/spapr_pci.c | 8 +++-
include/hw/pci-host/spapr.h | 7 --- 2 files changed, 11
insertions(+), 4 deletions(-)
diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c index
c0d8c1c..7b73106 100644 --- a/hw/ppc/spapr_pci.c +++
b/hw/ppc/spapr_pci.c @@ -862,6 +862,7 @@ int
spapr_populate_pci_dt(sPAPRPHBState *phb, int bus_off, i, j; char
nodename[256]; uint32_t bus_range[] = { cpu_to_be32(0),
cpu_to_be32(0xff) }; +const uint64_t win32size = (1ULL 32) -
SPAPR_PCI_MEM_WIN_BUS_OFFSET; struct { uint32_t hi; uint64_t child;
@@ -876,7 +877,12 @@ int spapr_populate_pci_dt(sPAPRPHBState *phb,
{ cpu_to_be32(b_ss(2)), cpu_to_be64(SPAPR_PCI_MEM_WIN_BUS_OFFSET),
cpu_to_be64(phb-mem_win_addr), -
cpu_to_be64(memory_region_size(phb-memwindow)), +
cpu_to_be64(win32size), +}, +{ +
cpu_to_be32(b_ss(3)), cpu_to_be64(1ULL 32), +
cpu_to_be64(phb-mem_win_addr + win32size), +
cpu_to_be64(memory_region_size(phb-memwindow) - win32size) },
I think this needs to be a little fancier. It will work in the case
of the normal PHB configuration. But the user can override the size
of the memory window size, in which case you may need to omit the
second range, or even limit the size of the 32-bit range.
Ah, right, the memory_region_size(phb-memwindow) win32size check is
missing here. Will fix, thanks.
}; uint64_t bus_reg[] = { cpu_to_be64(phb-buid), 0 }; diff --git
a/include/hw/pci-host/spapr.h b/include/hw/pci-host/spapr.h index
4ea2a0d..92695b6 100644 --- a/include/hw/pci-host/spapr.h +++
b/include/hw/pci-host/spapr.h @@ -96,17 +96,18 @@ struct
sPAPRPHBVFIOState {
#define SPAPR_PCI_BASE_BUID 0x8002000ULL
+#define SPAPR_PCI_MEM_WIN_BUS_OFFSET 0x8000ULL + #define
SPAPR_PCI_WINDOW_BASE0x100ULL #define
SPAPR_PCI_WINDOW_SPACING 0x10ULL #define
SPAPR_PCI_MMIO_WIN_OFF 0xA000 -#define
SPAPR_PCI_MMIO_WIN_SIZE 0x2000 +#define
SPAPR_PCI_MMIO_WIN_SIZE (SPAPR_PCI_WINDOW_SPACING - \ +
SPAPR_PCI_MEM_WIN_BUS_OFFSET) #define SPAPR_PCI_IO_WIN_OFF
0x8000 #define SPAPR_PCI_IO_WIN_SIZE0x1
#define SPAPR_PCI_MSI_WINDOW 0x400ULL
-#define SPAPR_PCI_MEM_WIN_BUS_OFFSET 0x8000ULL - static inline
qemu_irq spapr_phb_lsi_qirq(struct sPAPRPHBState *phb, int pin) {
return xics_get_qirq(spapr-icp, phb-lsi_table[pin].irq);
I think you also should disable the extended window for older machine
revisions. It would probably work anyway, but I think it's going to
be safer for backwards compat if you keep the windows the same for a
given machine revision.
Hos is it safer? What can possibly break it? I understand the intention
but in this particular case I cannot see any possible problems, can you?
- --
Alexey
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQIcBAEBAgAGBQJUuF5hAAoJEIYTPdgrwSC5pPIP/iBfFOzM7NKC09Jir1TxeODg
dEAI4tBEWeF6yuoE5u6sN74SoT9kX3/FaUQoWAIT+6W4HVj7Sbd65J7O4yK2XTEa
XGsU3UN4qqp7rYP5OClHqXAiltN5saHe4MmPNLW5zqTl7bLkW1ExIZ18VdTrsZDI
5DNXqkhNdawTtQtu9URe1x5YmiHiaD1tKEn8v9yAXZwGMbjb+HWhkWXRuGER1WdO
V/+AuNTOsNGh+3PJE8WScOw/I1bHkCX4EQmevXVXcNQ1MLa5uI3h0cpCChDhppvV
Qj3CLk+PA8Ik3sq2uGEBnVI20jhRFb2o9LzO504EtEJMuqTbNbJrVX80WrgnzyWD
tqsE2tx6Pj/znhNRioHKBXqBYDcYaZ67Ut42PXbLOGm0Bha/1BrZEq7N0U+17xcT
diMsGcgMTEfBSfR+T3hCFOZVEBNYzvxeMfdTTIu2cysf6XYV3qMK7EopM4xMF1s6
dAUY6/TzTceOfBC6+6nfd3VWmxvC0CCd/upuV9x/a/0It6WOiYzwkMM4Tnu9AME+
gOEnY6GOwe1qw8/EQmUZcDqY0zC41KgTeuUyKk65juhmJjJuBUhn9p1YWfQ4xniD
Ra2CxoOkuO2BS3tAPxIdU0zPjm+NHOrwAOV5qC0MEmDzS2iixGEoG5ytbE1qNcg1
pwdxlDx2jOMbEfAny72s
=juwo
-END PGP SIGNATURE-
[Qemu-devel] [PULL 05/12] target-tricore: Fix new typos
From: Stefan Weil s...@weilnetz.de
adress - address
managment - management
Cc: Bastian Koppelmann kbast...@mail.uni-paderborn.de
Signed-off-by: Stefan Weil s...@weilnetz.de
Signed-off-by: Michael Tokarev m...@tls.msk.ru
---
target-tricore/csfr.def | 2 +-
target-tricore/translate.c | 2 +-
target-tricore/tricore-opcodes.h | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/target-tricore/csfr.def b/target-tricore/csfr.def
index 5b219b4..05c45dd 100644
--- a/target-tricore/csfr.def
+++ b/target-tricore/csfr.def
@@ -90,7 +90,7 @@ A(0xE200, CPM0, TRICORE_FEATURE_13)
A(0xE280, CPM1, TRICORE_FEATURE_13)
A(0xE300, CPM2, TRICORE_FEATURE_13)
A(0xE380, CPM3, TRICORE_FEATURE_13)
-/* memory Managment Registers */
+/* memory management registers */
A(0x8000, MMU_CON, TRICORE_FEATURE_13)
A(0x8004, MMU_ASI, TRICORE_FEATURE_13)
A(0x800C, MMU_TVA, TRICORE_FEATURE_13)
diff --git a/target-tricore/translate.c b/target-tricore/translate.c
index 3b83782..def7f4a 100644
--- a/target-tricore/translate.c
+++ b/target-tricore/translate.c
@@ -5022,7 +5022,7 @@ static void decode_32Bit_opc(CPUTriCoreState *env,
DisasContext *ctx)
case OPCM_32_RR_LOGICAL_SHIFT:
decode_rr_logical_shift(env, ctx);
break;
-case OPCM_32_RR_ADRESS:
+case OPCM_32_RR_ADDRESS:
decode_rr_address(env, ctx);
break;
case OPCM_32_RR_IDIRECT:
diff --git a/target-tricore/tricore-opcodes.h b/target-tricore/tricore-opcodes.h
index 919063e..82bd161 100644
--- a/target-tricore/tricore-opcodes.h
+++ b/target-tricore/tricore-opcodes.h
@@ -503,7 +503,7 @@ enum {
/* RR Format */
OPCM_32_RR_LOGICAL_SHIFT = 0x0f,
OPCM_32_RR_ACCUMULATOR = 0x0b,
-OPCM_32_RR_ADRESS= 0x01,
+OPCM_32_RR_ADDRESS = 0x01,
OPCM_32_RR_DIVIDE= 0x4b,
OPCM_32_RR_IDIRECT = 0x2d,
/* RR1 Format */
@@ -1082,7 +1082,7 @@ enum {
OPC2_32_RR_XOR_LT_U = 0x32,
OPC2_32_RR_XOR_NE= 0x30,
};
-/* OPCM_32_RR_ADRESS*/
+/* OPCM_32_RR_ADDRESS */
enum {
OPC2_32_RR_ADD_A = 0x01,
OPC2_32_RR_ADDSC_A = 0x60,
--
2.1.4
[Qemu-devel] [PULL 10/12] Makefile: Remove config.status and common.env during 'make distclean'
From: Thomas Huth th...@linux.vnet.ibm.com config.status and tests/qemu-iotests/common.env are generated files that should be deleted during 'make distclean'. Signed-off-by: Thomas Huth th...@linux.vnet.ibm.com Signed-off-by: Michael Tokarev m...@tls.msk.ru --- Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index f505202..6817c6f 100644 --- a/Makefile +++ b/Makefile @@ -313,8 +313,8 @@ qemu-%.tar.bz2: distclean: clean rm -f config-host.mak config-host.h* config-host.ld $(DOCS) qemu-options.texi qemu-img-cmds.texi qemu-monitor.texi - rm -f config-all-devices.mak config-all-disas.mak - rm -f po/*.mo + rm -f config-all-devices.mak config-all-disas.mak config.status + rm -f po/*.mo tests/qemu-iotests/common.env rm -f roms/seabios/config.mak roms/vgabios/config.mak rm -f qemu-doc.info qemu-doc.aux qemu-doc.cp qemu-doc.cps qemu-doc.dvi rm -f qemu-doc.fn qemu-doc.fns qemu-doc.info qemu-doc.ky qemu-doc.kys -- 2.1.4
Re: [Qemu-devel] [RFC v3 1/2] pci/pci-host: Add generic-pci PCI host controller device
Hi Claudio,
Sorry, I should have missed this one.
On Wed, Jan 14, 2015 at 2:12 PM, Claudio Fontana
claudio.font...@huawei.com wrote:
On 14.01.2015 11:16, Alvise Rigo wrote:
Add a generic PCI host controller for virtual platforms, based on the
previous work by Rob Herring:
http://lists.gnu.org/archive/html/qemu-devel/2014-06/msg03482.html
The controller relies on a configuration memory region and provides two
PCI memory regions for I/O (one port and one memory mapped). The device
needs the following qdev properties to configure the memory regions:
- cfg_win_size: size of the configuration memory
- pio_win_size: size of the port I/O space
- mmio_win_size: size of the MMIO space
- mmio_win_addr: offset of MMIO space in the system memory
Signed-off-by: Alvise Rigo a.r...@virtualopensystems.com
---
hw/pci-host/Makefile.objs | 2 +-
hw/pci-host/generic-pci.c | 140
++
include/hw/pci-host/generic-pci.h | 45
3 files changed, 186 insertions(+), 1 deletion(-)
create mode 100644 hw/pci-host/generic-pci.c
create mode 100644 include/hw/pci-host/generic-pci.h
diff --git a/hw/pci-host/Makefile.objs b/hw/pci-host/Makefile.objs
index bb65f9c..8ef9fac 100644
--- a/hw/pci-host/Makefile.objs
+++ b/hw/pci-host/Makefile.objs
@@ -1,4 +1,4 @@
-common-obj-y += pam.o
+common-obj-y += pam.o generic-pci.o
# PPC devices
common-obj-$(CONFIG_PREP_PCI) += prep.o
diff --git a/hw/pci-host/generic-pci.c b/hw/pci-host/generic-pci.c
new file mode 100644
index 000..54c9647
--- /dev/null
+++ b/hw/pci-host/generic-pci.c
@@ -0,0 +1,140 @@
+/*
+ * Generic PCI host controller
+ *
+ * Copyright (c) 2014 Linaro, Ltd.
+ * Author: Rob Herring rob.herr...@linaro.org
+ *
+ * Based on ARM Versatile PCI controller (hw/pci-host/versatile.c):
+ * Copyright (c) 2006-2009 CodeSourcery.
+ * Written by Paul Brook
+ *
+ * This code is licensed under the LGPL.
+ */
+
+#include hw/sysbus.h
+#include hw/pci-host/generic-pci.h
+#include exec/address-spaces.h
+#include sysemu/device_tree.h
+
+static const VMStateDescription pci_generic_host_vmstate = {
+.name = generic-host-pci,
+.version_id = 1,
+.minimum_version_id = 1,
+};
+
+static void pci_cam_config_write(void *opaque, hwaddr addr,
+ uint64_t val, unsigned size)
+{
+PCIGenState *s = opaque;
+pci_data_write(s-pci_bus, addr, val, size);
+}
+
+static uint64_t pci_cam_config_read(void *opaque, hwaddr addr, unsigned
size)
+{
+PCIGenState *s = opaque;
+uint32_t val;
+val = pci_data_read(s-pci_bus, addr, size);
+return val;
+}
+
+static const MemoryRegionOps pci_generic_config_ops = {
+.read = pci_cam_config_read,
+.write = pci_cam_config_write,
+.endianness = DEVICE_LITTLE_ENDIAN,
+};
+
+static void pci_generic_set_irq(void *opaque, int irq_num, int level)
+{
+qemu_irq *pic = opaque;
+qemu_set_irq(pic[irq_num], level);
+}
+
+static void pci_generic_host_realize(DeviceState *dev, Error **errp)
+{
+PCIHostState *h = PCI_HOST_BRIDGE(dev);
+PCIGenState *s = PCI_GEN(dev);
+GenericPCIHostState *gps = s-pci_gen;
+SysBusDevice *sbd = SYS_BUS_DEVICE(dev);
+int i;
+
+memory_region_init(s-pci_io_window, OBJECT(s), pci_io,
s-pio_win_size);
+memory_region_init(s-pci_mem_space, OBJECT(s), pci_mem, 1ULL 32);
+
+pci_bus_new_inplace(s-pci_bus, sizeof(s-pci_bus), dev, pci,
+s-pci_mem_space, s-pci_io_window,
+PCI_DEVFN(0, 0), TYPE_PCI_BUS);
+h-bus = s-pci_bus;
+
+object_initialize(gps, sizeof(*gps), TYPE_GENERIC_PCI_HOST);
+qdev_set_parent_bus(DEVICE(gps), BUS(s-pci_bus));
+
+for (i = 0; i s-irqs; i++) {
+sysbus_init_irq(sbd, s-irq[i]);
+}
+
+pci_bus_irqs(s-pci_bus, pci_generic_set_irq, pci_swizzle_map_irq_fn,
+ s-irq, s-irqs);
+memory_region_init_io(s-mem_config, OBJECT(s),
pci_generic_config_ops, s,
+ pci-config, s-cfg_win_size);
+memory_region_init_alias(s-pci_mem_window, OBJECT(s), pci-mem-win,
+s-pci_mem_space, s-mmio_win_addr, s-mmio_win_size);
+
+sysbus_init_mmio(sbd, s-mem_config);
+sysbus_init_mmio(sbd, s-pci_io_window);
+sysbus_init_mmio(sbd, s-pci_mem_window);
+}
+
+static void pci_generic_host_class_init(ObjectClass *klass, void *data)
+{
+PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+DeviceClass *dc = DEVICE_CLASS(klass);
+
+k-vendor_id = PCI_VENDOR_ID_REDHAT;
+k-device_id = PCI_DEVICE_ID_REDHAT_BRIDGE;
+k-class_id = PCI_CLASS_PROCESSOR_CO;
+/*
+ * PCI-facing part of the host bridge, not usable without the
+ * host-facing part, which can't be device_add'ed, yet.
+ */
+dc-cannot_instantiate_with_device_add_yet = true;
+}
+
+static const
[Qemu-devel] [PULL 00/12] Trivial patches for 2015-01-15
This is a next trivial-patches pull request, since the previous one which was at 2014-12-11 - 4 weeks ago. Only 12 patches in 4 weeks. There's nothing exciting in there, but there are several (small) bugfixes. Please consider applying/pulling. With the introduction of pbonzini's misc patches tree I'm not sure current trivial-patches is worth to keep. Paolo does much better job in this area than me. Thanks, /mjt The following changes since commit b629a38a13745d62d44de8ebb00f4e38ec6d8f7e: Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging (2015-01-14 18:02:47 +) are available in the git repository at: git://git.corpit.ru/qemu.git tags/pull-trivial-patches-2015-01-15 for you to fetch changes up to 99efa84d5c02e33bcca7be83dd7cabc4b0f22f14: vl.c: fix some alignment issues (2015-01-15 10:44:13 +0300) trivial patches for 2015-01-15 David Morrison (1): target-openrisc: bugfix for dec_sys to decode instructions correctly Don Slutz (1): Do not hang on full PTY Marcel Apfelbaum (1): vl.c: fix some alignment issues Paolo Bonzini (2): vt82c686: avoid out-of-bounds read blizzard: do not depend on VGA internals Peter Maydell (2): tests/hd-geo-test.c: Remove unused test_image variable migration/qemu-file.c: Don't shift left into sign bit SeokYeon Hwang (1): translate-all: Mark map_exec() with the 'unused' attribute Stefan Weil (3): target-tricore: Fix new typos target-arm: Fix typo in comment (seperately - separately) misc: Fix new typos in comments Thomas Huth (1): Makefile: Remove config.status and common.env during 'make distclean' Makefile | 4 ++-- hw/display/blizzard.c| 1 - hw/isa/vt82c686.c| 2 +- include/hw/hotplug.h | 2 +- migration/qemu-file.c| 2 +- qemu-char.c | 1 + target-arm/helper.c | 2 +- target-openrisc/translate.c | 2 +- target-tricore/csfr.def | 2 +- target-tricore/translate.c | 2 +- target-tricore/tricore-opcodes.h | 4 ++-- tests/ahci-test.c| 2 +- tests/hd-geo-test.c | 2 -- translate-all.c | 4 ++-- vl.c | 38 +++--- 15 files changed, 34 insertions(+), 36 deletions(-)
[Qemu-devel] [PULL 07/12] misc: Fix new typos in comments
From: Stefan Weil s...@weilnetz.de
recieve - receive
suprise - surprise
Cc: Igor Mammedov imamm...@redhat.com
Cc: John Snow js...@redhat.com
Signed-off-by: Stefan Weil s...@weilnetz.de
Reviewed-by: John Snow js...@redhat.com
Signed-off-by: Michael Tokarev m...@tls.msk.ru
---
include/hw/hotplug.h | 2 +-
tests/ahci-test.c| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/hw/hotplug.h b/include/hw/hotplug.h
index 050d2f0..2db025d 100644
--- a/include/hw/hotplug.h
+++ b/include/hw/hotplug.h
@@ -52,7 +52,7 @@ typedef void (*hotplug_fn)(HotplugHandler *plug_handler,
* require asynchronous unplug handling.
* @unplug: unplug callback.
* Used for device removal with devices that implement
- * asynchronous and synchronous (suprise) removal.
+ * asynchronous and synchronous (surprise) removal.
*/
typedef struct HotplugHandlerClass {
/* private */
diff --git a/tests/ahci-test.c b/tests/ahci-test.c
index e77fa3a..b1a59f2 100644
--- a/tests/ahci-test.c
+++ b/tests/ahci-test.c
@@ -1289,7 +1289,7 @@ static void ahci_test_identify(QPCIDevice *ahci, void
*hba_base)
PX_WREG(i, AHCI_PX_IS, reg);
g_assert_cmphex(PX_RREG(i, AHCI_PX_IS), ==, 0);
-/* Wipe the FIS-Recieve Buffer */
+/* Wipe the FIS-Receive Buffer */
fb = PX_RREG(i, AHCI_PX_FB);
g_assert_cmphex(fb, !=, 0);
qmemset(fb, 0x00, 0x100);
--
2.1.4
[Qemu-devel] [PULL 01/12] vt82c686: avoid out-of-bounds read
From: Paolo Bonzini pbonz...@redhat.com
superio_ioport_readb can read the 256th element of the array.
Coverity reports an out-of-bounds write in superio_ioport_writeb,
but it does not show the corresponding out-of-bounds read
because it cannot prove that it can happen. Fix the root
cause of the problem (zhanghailang's patch instead fixes
the logic in superio_ioport_writeb).
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Reviewed-by: zhanghailiang zhang.zhanghaili...@huawei.com
Signed-off-by: Michael Tokarev m...@tls.msk.ru
Cc: qemu-sta...@nongnu.org
---
hw/isa/vt82c686.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/isa/vt82c686.c b/hw/isa/vt82c686.c
index 223b947..2f53bf8 100644
--- a/hw/isa/vt82c686.c
+++ b/hw/isa/vt82c686.c
@@ -36,7 +36,7 @@
typedef struct SuperIOConfig
{
-uint8_t config[0xff];
+uint8_t config[0x100];
uint8_t index;
uint8_t data;
} SuperIOConfig;
--
2.1.4
[Qemu-devel] [PULL 12/12] vl.c: fix some alignment issues
From: Marcel Apfelbaum mar...@redhat.com
The misalignment was caused by tabs which were used instead of spaces.
Signed-off-by: Marcel Apfelbaum mar...@redhat.com
Reviewed-by: Stefan Weil s...@weilnetz.de
Signed-off-by: Michael Tokarev m...@tls.msk.ru
---
vl.c | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/vl.c b/vl.c
index 6adb36e..fbf4240 100644
--- a/vl.c
+++ b/vl.c
@@ -2873,7 +2873,7 @@ int main(int argc, char **argv, char **envp)
if (optind = argc)
break;
if (argv[optind][0] != '-') {
- hda_opts = drive_add(IF_DEFAULT, 0, argv[optind++], HD_OPTS);
+hda_opts = drive_add(IF_DEFAULT, 0, argv[optind++], HD_OPTS);
} else {
const QEMUOption *popt;
@@ -2918,15 +2918,15 @@ int main(int argc, char **argv, char **envp)
if (drive_def(optarg) == NULL) {
exit(1);
}
- break;
+break;
case QEMU_OPTION_set:
if (qemu_set_option(optarg) != 0)
exit(1);
- break;
+break;
case QEMU_OPTION_global:
if (qemu_global_option(optarg) != 0)
exit(1);
- break;
+break;
case QEMU_OPTION_mtdblock:
drive_add(IF_MTD, -1, optarg, MTD_OPTS);
break;
@@ -2978,7 +2978,7 @@ int main(int argc, char **argv, char **envp)
fprintf(stderr, qemu: invalid physical CHS format\n);
exit(1);
}
- if (hda_opts != NULL) {
+if (hda_opts != NULL) {
char num[16];
snprintf(num, sizeof(num), %d, cyls);
qemu_opt_set(hda_opts, cyls, num);
@@ -3152,9 +3152,9 @@ int main(int argc, char **argv, char **envp)
case QEMU_OPTION_S:
autostart = 0;
break;
- case QEMU_OPTION_k:
- keyboard_layout = optarg;
- break;
+case QEMU_OPTION_k:
+keyboard_layout = optarg;
+break;
case QEMU_OPTION_localtime:
rtc_utc = 0;
break;
@@ -3362,9 +3362,9 @@ int main(int argc, char **argv, char **envp)
case QEMU_OPTION_debugcon:
add_device_config(DEV_DEBUGCON, optarg);
break;
- case QEMU_OPTION_loadvm:
- loadvm = optarg;
- break;
+case QEMU_OPTION_loadvm:
+loadvm = optarg;
+break;
case QEMU_OPTION_full_screen:
full_screen = 1;
break;
@@ -3476,7 +3476,7 @@ int main(int argc, char **argv, char **envp)
exit(1);
}
break;
- case QEMU_OPTION_vnc:
+case QEMU_OPTION_vnc:
#ifdef CONFIG_VNC
display_remote++;
vnc_display = optarg;
@@ -3514,11 +3514,11 @@ int main(int argc, char **argv, char **envp)
}
qemu_uuid_set = true;
break;
- case QEMU_OPTION_option_rom:
- if (nb_option_roms = MAX_OPTION_ROMS) {
- fprintf(stderr, Too many option ROMs\n);
- exit(1);
- }
+case QEMU_OPTION_option_rom:
+if (nb_option_roms = MAX_OPTION_ROMS) {
+fprintf(stderr, Too many option ROMs\n);
+exit(1);
+}
opts = qemu_opts_parse(qemu_find_opts(option-rom), optarg,
1);
if (!opts) {
exit(1);
@@ -3530,8 +3530,8 @@ int main(int argc, char **argv, char **envp)
fprintf(stderr, Option ROM file is not specified\n);
exit(1);
}
- nb_option_roms++;
- break;
+nb_option_roms++;
+break;
case QEMU_OPTION_semihosting:
semihosting_enabled = 1;
semihosting_target = SEMIHOSTING_TARGET_AUTO;
--
2.1.4
[Qemu-devel] [PULL 06/12] target-arm: Fix typo in comment (seperately - separately)
From: Stefan Weil s...@weilnetz.de
Cc: Peter Maydell peter.mayd...@linaro.org
Cc: Greg Bellows greg.bell...@linaro.org
Signed-off-by: Stefan Weil s...@weilnetz.de
Signed-off-by: Michael Tokarev m...@tls.msk.ru
---
target-arm/helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target-arm/helper.c b/target-arm/helper.c
index 3ef0f1f..1a5e067 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -972,7 +972,7 @@ static const ARMCPRegInfo v7_cp_reginfo[] = {
* The override is necessary because of the overly-broad TLB_LOCKDOWN
* definition.
*/
- /* MAIR0/1 are defined seperately from their 64-bit counterpart which
+ /* MAIR0/1 are defined separately from their 64-bit counterpart which
* allows them to assign the correct fieldoffset based on the endianness
* handled in the field definitions.
*/
--
2.1.4
[Qemu-devel] [PULL 08/12] Do not hang on full PTY
From: Don Slutz dsl...@verizon.com Signed-off-by: Don Slutz dsl...@verizon.com Reviewed-by: Paolo Bonzini pbonz...@redhat.com Signed-off-by: Michael Tokarev m...@tls.msk.ru --- qemu-char.c | 1 + 1 file changed, 1 insertion(+) diff --git a/qemu-char.c b/qemu-char.c index 5430b87..98d4342 100644 --- a/qemu-char.c +++ b/qemu-char.c @@ -1402,6 +1402,7 @@ static CharDriverState *qemu_chr_open_pty(const char *id, } close(slave_fd); +qemu_set_nonblock(master_fd); chr = qemu_chr_alloc(); -- 2.1.4
Re: [Qemu-devel] [RFC PATCH 3/4] vfio-pci: add aer capability support
On 01/12/2015 09:14 PM, Paolo Bonzini wrote:
On 12/01/2015 04:04, Chen Fan wrote:
+static int vfio_add_ext_capabilities(VFIOPCIDevice *vdev)
+{
+PCIDevice *pdev = vdev-pdev;
+PCIExpressDevice *exp;
+uint32_t header;
+uint16_t next = PCI_CONFIG_SPACE_SIZE;
+
+if (pci_config_size(pdev) = PCI_CONFIG_SPACE_SIZE) {
+return 0;
+}
+
+header = pci_get_long(pdev-config + next);
+while (header) {
+switch (PCI_EXT_CAP_ID(header)) {
+case PCI_EXT_CAP_ID_ERR:
+ exp = pdev-exp;
+ exp-aer_cap = next;
+
+ /* enable the error report */
+ vfio_add_emulated_long(vdev, exp-exp_cap + PCI_EXP_DEVCTL,
+ PCI_EXP_DEVCTL_CERE | PCI_EXP_DEVCTL_NFERE |
+ PCI_EXP_DEVCTL_FERE | PCI_EXP_DEVCTL_URRE, ~0);
+ break;
+};
+
+next = PCI_EXT_CAP_NEXT(header);
+if (!next) {
+return 0;
+}
+header = pci_get_long(pdev-config + next);
+}
+
+return 0;
+}
+
Please add a property to the VFIO device, defaulting to true, and
disable it for older machine types.
Thanks for your suggestion.
Chen
Paolo
Re: [Qemu-devel] [PATCH 4/4] vmstate: accept QEMUTimer in VMSTATE_TIMER*, add VMSTATE_TIMER_PTR*
On 15/01/2015 10:04, Amit Shah wrote: diff --git a/include/migration/vmstate.h b/include/migration/vmstate.h index e45fc49..55ba584 100644 --- a/include/migration/vmstate.h +++ b/include/migration/vmstate.h @@ -642,17 +642,29 @@ extern const VMStateInfo vmstate_info_bitmap; #define VMSTATE_FLOAT64(_f, _s) \ VMSTATE_FLOAT64_V(_f, _s, 0) -#define VMSTATE_TIMER_TEST(_f, _s, _test) \ +#define VMSTATE_TIMER_PTR_TEST(_f, _s, _test) \ VMSTATE_POINTER_TEST(_f, _s, _test, vmstate_info_timer, QEMUTimer *) -#define VMSTATE_TIMER_V(_f, _s, _v) \ +#define VMSTATE_TIMER_PTR_V(_f, _s, _v) \ VMSTATE_POINTER(_f, _s, _v, vmstate_info_timer, QEMUTimer *) +#define VMSTATE_TIMER_PTR(_f, _s) \ +VMSTATE_TIMER_PTR_V(_f, _s, 0) + +#define VMSTATE_TIMER_PTR_ARRAY(_f, _s, _n) \ +VMSTATE_ARRAY_OF_POINTER(_f, _s, _n, 0, vmstate_info_timer, QEMUTimer *) + +#define VMSTATE_TIMER_TEST(_f, _s, _test) \ +VMSTATE_SINGLE_TEST(_f, _s, _test, 0, vmstate_info_timer, QEMUTimer) + +#define VMSTATE_TIMER_V(_f, _s, _v) \ +VMSTATE_SINGLE(_f, _s, _v, vmstate_info_timer, QEMUTimer) + #define VMSTATE_TIMER(_f, _s) \ VMSTATE_TIMER_V(_f, _s, 0) Why leave this around? Because further changes down the line will convert QEMUTimer* to QEMUTimer and thus go back to VMSTATE_TIMER. Having both around avoids having a single patch with -1000/+1000 diffstat. Paolo
Re: [Qemu-devel] global_mutex and multithread.
On 15 January 2015 at 10:25, Frederic Konrad fred.kon...@greensocs.com wrote: Hi everybody, In case of multithread TCG what is the best way to handle qemu_global_mutex? It shouldn't need any changes I think. You're basically bringing TCG into line with what KVM already has -- one thread per guest CPU; and qemu_global_mutex already works fine in that model. -- PMM
[Qemu-devel] [PATCH 0/3] multiboot: Fix offset of bootloader name
This fixes a recent Multiboot load regression (see patch 2) that we noticed while hacking on the advent calendar image for December 24. Kevin Wolf (3): tests/multiboot: Update reference output multiboot: Fix offset of bootloader name tests/multiboot: Add test for modules hw/i386/multiboot.c | 16 +++-- tests/multiboot/Makefile| 5 - tests/multiboot/libc.c | 12 ++ tests/multiboot/libc.h | 1 + tests/multiboot/mmap.out| 37 +++--- tests/multiboot/module.txt | 1 + tests/multiboot/modules.c | 55 + tests/multiboot/modules.out | 38 +++ tests/multiboot/run_test.sh | 9 +++- 9 files changed, 146 insertions(+), 28 deletions(-) create mode 100644 tests/multiboot/module.txt create mode 100644 tests/multiboot/modules.c create mode 100644 tests/multiboot/modules.out -- 1.8.3.1
Re: [Qemu-devel] [PATCH] tcg: Add doxygen documentation to the tcg frontend
Richard Henderson writes: On 01/14/2015 10:15 AM, Lluís Vilanova wrote: Sorry I wasn't clear. I meant that it might be better to remove tcg/README and instead document all the operations (those in the readme and the additional ones) in the header. If we did that, it would go somewhere else. Yes, I meant moving it to the header. There are two different (but clearly closely related) things that need documenting: (1) The functional interface used by target-*/translate.c. This is what Bastian is attempting to document now. (2) The intermediate language opcodes. This is what is currently documented in tcg/README. Ok, it just seemed to me that documenting the interface would add some duplication between both, making it less likely to keep all docs in sync when opcodes change. Maybe it's just me being paranoid, since opcodes rarely change. Thanks, Lluis -- And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer. -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth
[Qemu-devel] global_mutex and multithread.
Hi everybody, In case of multithread TCG what is the best way to handle qemu_global_mutex? We though to have one mutex per vcpu and then synchronize vcpu threads when they exit (eg: in tcg_exec_all). Is that making sense? Thanks, Fred
