[Qemu-devel] [PATCH RFC 6/8] exec: Clean up unnecessary S390 ifdeffery
Another issue missed in commit fdec991 is -mem-path: it needs to be
rejected only for old S390 KVM, not for any S390. Not that I
personally care, but the ifdeffery in qemu_ram_alloc_from_ptr() annoys
me.
Note that this doesn't actually make -mem-path work, as the kernel
doesn't (yet?) support large pages in the host for KVM guests. Clean
it up anyway.
Thanks to Christian Borntraeger for pointing out the S390 kernel
limitations.
Signed-off-by: Markus Armbruster
---
exec.c | 31 +++
1 file changed, 19 insertions(+), 12 deletions(-)
diff --git a/exec.c b/exec.c
index 8810d33..9f0355b 100644
--- a/exec.c
+++ b/exec.c
@@ -849,7 +849,7 @@ void qemu_mutex_unlock_ramlist(void)
qemu_mutex_unlock(&ram_list.mutex);
}
-#if defined(__linux__) && !defined(TARGET_S390X)
+#ifdef __linux__
#include
@@ -952,6 +952,14 @@ static void *file_ram_alloc(RAMBlock *block,
block->fd = fd;
return area;
}
+#else
+static void *file_ram_alloc(RAMBlock *block,
+ram_addr_t memory,
+const char *path)
+{
+fprintf(stderr, "-mem-path not supported on this host\n");
+exit(1);
+}
#endif
static ram_addr_t find_ram_offset(ram_addr_t size)
@@ -1088,22 +1096,21 @@ ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size,
void *host,
exit(1);
}
xen_ram_alloc(new_block->offset, size, mr);
+} else if (kvm_enabled() && kvm_arch_ram_alloc) {
+/* some s390/kvm configurations have special constraints */
+if (mem_path) {
+fprintf(stderr,
+"-mem-path not supported with this version of KVM\n");
+exit(1);
+}
+new_block->host = kvm_arch_ram_alloc(size);
+memory_try_enable_merging(new_block->host, size);
} else {
if (mem_path) {
-#if defined (__linux__) && !defined(TARGET_S390X)
new_block->host = file_ram_alloc(new_block, size, mem_path);
-#else
-fprintf(stderr, "-mem-path option unsupported\n");
-exit(1);
-#endif
}
if (!new_block->host) {
-if (kvm_enabled() && kvm_arch_ram_alloc) {
-/* some s390/kvm configurations have special constraints */
-new_block->host = kvm_arch_ram_alloc(size);
-} else {
-new_block->host = qemu_anon_ram_alloc(size);
-}
+new_block->host = qemu_anon_ram_alloc(size);
memory_try_enable_merging(new_block->host, size);
}
}
--
1.7.11.7
[Qemu-devel] [PATCH RFC 8/8] pc_sysfw: Fix ISA BIOS init for ridiculously big flash
pc_isa_bios_init() suffers integer overflow for flash larger than
INT_MAX.
Signed-off-by: Markus Armbruster
---
hw/block/pc_sysfw.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/hw/block/pc_sysfw.c b/hw/block/pc_sysfw.c
index 412d1b0..aebefc9 100644
--- a/hw/block/pc_sysfw.c
+++ b/hw/block/pc_sysfw.c
@@ -54,10 +54,7 @@ static void pc_isa_bios_init(MemoryRegion *rom_memory,
flash_size = memory_region_size(flash_mem);
/* map the last 128KB of the BIOS in ISA space */
-isa_bios_size = flash_size;
-if (isa_bios_size > (128 * 1024)) {
-isa_bios_size = 128 * 1024;
-}
+isa_bios_size = MIN(flash_size, 128 * 1024);
isa_bios = g_malloc(sizeof(*isa_bios));
memory_region_init_ram(isa_bios, "isa-bios", isa_bios_size);
vmstate_register_ram_global(isa_bios);
--
1.7.11.7
[Qemu-devel] [PATCH RFC 1/8] exec: Fix Xen RAM allocation with unusual options
Issues:
* We try to obey -mem-path even though it can't work with Xen.
* To implement -machine mem-merge, we call
memory_try_enable_merging(new_block->host, size). But with Xen,
new_block->host remains null. Oops.
Fix by separating Xen allocation from normal allocation.
Signed-off-by: Markus Armbruster
---
exec.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/exec.c b/exec.c
index 5b8b40d..b424e12 100644
--- a/exec.c
+++ b/exec.c
@@ -1081,6 +1081,12 @@ ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size, void
*host,
if (host) {
new_block->host = host;
new_block->flags |= RAM_PREALLOC_MASK;
+} else if (xen_enabled()) {
+if (mem_path) {
+fprintf(stderr, "-mem-path not supported with Xen\n");
+exit(1);
+}
+xen_ram_alloc(new_block->offset, size, mr);
} else {
if (mem_path) {
#if defined (__linux__) && !defined(TARGET_S390X)
@@ -1094,9 +1100,7 @@ ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size, void
*host,
exit(1);
#endif
} else {
-if (xen_enabled()) {
-xen_ram_alloc(new_block->offset, size, mr);
-} else if (kvm_enabled()) {
+if (kvm_enabled()) {
/* some s390/kvm configurations have special constraints */
new_block->host = kvm_ram_alloc(size);
} else {
@@ -1174,6 +1178,8 @@ void qemu_ram_free(ram_addr_t addr)
ram_list.version++;
if (block->flags & RAM_PREALLOC_MASK) {
;
+} else if (xen_enabled()) {
+xen_invalidate_map_cache_entry(block->host);
} else if (mem_path) {
#if defined (__linux__) && !defined(TARGET_S390X)
if (block->fd) {
@@ -1186,11 +1192,7 @@ void qemu_ram_free(ram_addr_t addr)
abort();
#endif
} else {
-if (xen_enabled()) {
-xen_invalidate_map_cache_entry(block->host);
-} else {
-qemu_anon_ram_free(block->host, block->length);
-}
+qemu_anon_ram_free(block->host, block->length);
}
g_free(block);
break;
@@ -1214,6 +1216,8 @@ void qemu_ram_remap(ram_addr_t addr, ram_addr_t length)
vaddr = block->host + offset;
if (block->flags & RAM_PREALLOC_MASK) {
;
+} else if (xen_enabled()) {
+abort();
} else {
flags = MAP_FIXED;
munmap(vaddr, length);
--
1.7.11.7
[Qemu-devel] [PATCH RFC 3/8] exec: Reduce ifdeffery around -mem-path
Instead of spreading its ifdeffery everywhere, confine it to
qemu_ram_alloc_from_ptr(). Everywhere else, simply test block->fd,
which is valid exactly when block uses -mem-path.
Signed-off-by: Markus Armbruster
---
exec.c | 37 ++---
include/exec/cpu-all.h | 2 --
2 files changed, 10 insertions(+), 29 deletions(-)
diff --git a/exec.c b/exec.c
index 56c31a9..4dbb0f1 100644
--- a/exec.c
+++ b/exec.c
@@ -1073,6 +1073,7 @@ ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size, void
*host,
size = TARGET_PAGE_ALIGN(size);
new_block = g_malloc0(sizeof(*new_block));
+new_block->fd = -1;
/* This assumes the iothread lock is taken here too. */
qemu_mutex_lock_ramlist();
@@ -1177,17 +1178,9 @@ void qemu_ram_free(ram_addr_t addr)
;
} else if (xen_enabled()) {
xen_invalidate_map_cache_entry(block->host);
-} else if (mem_path) {
-#if defined (__linux__) && !defined(TARGET_S390X)
-if (block->fd) {
-munmap(block->host, block->length);
-close(block->fd);
-} else {
-qemu_anon_ram_free(block->host, block->length);
-}
-#else
-abort();
-#endif
+} else if (block->fd >= 0) {
+munmap(block->host, block->length);
+close(block->fd);
} else {
qemu_anon_ram_free(block->host, block->length);
}
@@ -1218,25 +1211,15 @@ void qemu_ram_remap(ram_addr_t addr, ram_addr_t length)
} else {
flags = MAP_FIXED;
munmap(vaddr, length);
-if (mem_path) {
-#if defined(__linux__) && !defined(TARGET_S390X)
-if (block->fd) {
+if (block->fd >= 0) {
#ifdef MAP_POPULATE
-flags |= mem_prealloc ? MAP_POPULATE | MAP_SHARED :
-MAP_PRIVATE;
+flags |= mem_prealloc ? MAP_POPULATE | MAP_SHARED :
+MAP_PRIVATE;
#else
-flags |= MAP_PRIVATE;
-#endif
-area = mmap(vaddr, length, PROT_READ | PROT_WRITE,
-flags, block->fd, offset);
-} else {
-flags |= MAP_PRIVATE | MAP_ANONYMOUS;
-area = mmap(vaddr, length, PROT_READ | PROT_WRITE,
-flags, -1, 0);
-}
-#else
-abort();
+flags |= MAP_PRIVATE;
#endif
+area = mmap(vaddr, length, PROT_READ | PROT_WRITE,
+flags, block->fd, offset);
} else {
#if defined(TARGET_S390X) && defined(CONFIG_KVM)
flags |= MAP_SHARED | MAP_ANONYMOUS;
diff --git a/include/exec/cpu-all.h b/include/exec/cpu-all.h
index e9c3717..c369b25 100644
--- a/include/exec/cpu-all.h
+++ b/include/exec/cpu-all.h
@@ -476,9 +476,7 @@ typedef struct RAMBlock {
* Writes must take both locks.
*/
QTAILQ_ENTRY(RAMBlock) next;
-#if defined(__linux__) && !defined(TARGET_S390X)
int fd;
-#endif
} RAMBlock;
typedef struct RAMList {
--
1.7.11.7
Re: [Qemu-devel] [PATCH RFC 0/8] Guest memory allocation fixes & cleanup
Err, the RFC is accidental. Please review anyway. I'll respin for commit afterwards.
[Qemu-devel] [PATCH RFC 7/8] exec: Don't abort when we can't allocate guest memory
We abort() on memory allocation failure. abort() is appropriate for
programming errors. Maybe most memory allocation failures are
programming errors, maybe not. But guest memory allocation failure
isn't, and aborting when the user asks for more memory than we can
provide is not nice. exit(1) instead, and do it in just one place, so
the error message is consistent.
Signed-off-by: Markus Armbruster
---
exec.c | 15 ++-
target-s390x/kvm.c | 6 +-
util/oslib-posix.c | 4 +---
util/oslib-win32.c | 5 +
4 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/exec.c b/exec.c
index 9f0355b..7432465 100644
--- a/exec.c
+++ b/exec.c
@@ -851,6 +851,13 @@ void qemu_mutex_unlock_ramlist(void)
#ifdef __linux__
+static void no_guest_mem(RAMBlock *block)
+{
+fprintf(stderr, "Cannot set up guest memory '%s': %s\n",
+block->mr->name, strerror(errno));
+exit(1);
+}
+
#include
#define HUGETLBFS_MAGIC 0x958458f6
@@ -945,7 +952,7 @@ static void *file_ram_alloc(RAMBlock *block,
area = mmap(0, memory, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0);
#endif
if (area == MAP_FAILED) {
-perror("file_ram_alloc: can't mmap RAM pages");
+no_guest_mem(block);
close(fd);
return (NULL);
}
@@ -1104,6 +,9 @@ ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size, void
*host,
exit(1);
}
new_block->host = kvm_arch_ram_alloc(size);
+if (!new_block->host) {
+no_guest_mem(new_block);
+}
memory_try_enable_merging(new_block->host, size);
} else {
if (mem_path) {
@@ -,6 +1121,9 @@ ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size, void
*host,
}
if (!new_block->host) {
new_block->host = qemu_anon_ram_alloc(size);
+if (!new_block->host) {
+no_guest_mem(new_block);
+}
memory_try_enable_merging(new_block->host, size);
}
}
diff --git a/target-s390x/kvm.c b/target-s390x/kvm.c
index aa45e06..472a66f 100644
--- a/target-s390x/kvm.c
+++ b/target-s390x/kvm.c
@@ -336,11 +336,7 @@ static void *legacy_s390_mmap(void *vaddr, ram_addr_t size)
static void *legacy_s390_alloc(ram_addr_t size)
{
void *mem = legacy_s390_mmap((void *) 0x8ULL, size);
-if (mem == MAP_FAILED) {
-fprintf(stderr, "Allocating RAM failed\n");
-abort();
-}
-return mem;
+return mem == MAP_FAILED ? NULL : mem;
}
int kvm_arch_insert_sw_breakpoint(CPUState *cs, struct kvm_sw_breakpoint *bp)
diff --git a/util/oslib-posix.c b/util/oslib-posix.c
index 3dc8b1b..253bc3d 100644
--- a/util/oslib-posix.c
+++ b/util/oslib-posix.c
@@ -112,9 +112,7 @@ void *qemu_anon_ram_alloc(size_t size)
size_t offset = QEMU_ALIGN_UP((uintptr_t)ptr, align) - (uintptr_t)ptr;
if (ptr == MAP_FAILED) {
-fprintf(stderr, "Failed to allocate %zu B: %s\n",
-size, strerror(errno));
-abort();
+return NULL;
}
ptr += offset;
diff --git a/util/oslib-win32.c b/util/oslib-win32.c
index 961fbf5..983b7a2 100644
--- a/util/oslib-win32.c
+++ b/util/oslib-win32.c
@@ -65,10 +65,7 @@ void *qemu_anon_ram_alloc(size_t size)
/* FIXME: this is not exactly optimal solution since VirtualAlloc
has 64Kb granularity, but at least it guarantees us that the
memory is page aligned. */
-if (!size) {
-abort();
-}
-ptr = qemu_oom_check(VirtualAlloc(NULL, size, MEM_COMMIT, PAGE_READWRITE));
+ptr = VirtualAlloc(NULL, size, MEM_COMMIT, PAGE_READWRITE);
trace_qemu_anon_ram_alloc(size, ptr);
return ptr;
}
--
1.7.11.7
[Qemu-devel] [PATCH RFC 5/8] s390: Make qemu_ram_remap() consistent with allocation
Old S390 KVM wants guest RAM mapped in a peculiar way.
Commit fdec991 changed qemu_ram_alloc_from_ptr() to do this only when
necessary, but forgot to update qemu_ram_remap(). If
qemu_ram_alloc_from_ptr() maps RAM the normal way, but
qemu_ram_remap() remaps it the peculiar way, remapping changes
protection and flags, which it shouldn't.
Fortunately, this can't happen right now, as we never remap on S390.
Fix it anyway.
Thanks to Christian Borntraeger for help with assessing the bug's
(non-)impact.
Signed-off-by: Markus Armbruster
---
exec.c | 19 +++
include/sysemu/kvm.h | 1 +
kvm-all.c| 1 +
target-s390x/kvm.c | 15 ++-
4 files changed, 19 insertions(+), 17 deletions(-)
diff --git a/exec.c b/exec.c
index 7552e3c..8810d33 100644
--- a/exec.c
+++ b/exec.c
@@ -1209,27 +1209,22 @@ void qemu_ram_remap(ram_addr_t addr, ram_addr_t length)
} else if (xen_enabled()) {
abort();
} else {
-flags = MAP_FIXED;
munmap(vaddr, length);
if (block->fd >= 0) {
#ifdef MAP_POPULATE
-flags |= mem_prealloc ? MAP_POPULATE | MAP_SHARED :
+flags = mem_prealloc ? MAP_POPULATE | MAP_SHARED :
MAP_PRIVATE;
#else
-flags |= MAP_PRIVATE;
+flags = MAP_PRIVATE;
#endif
area = mmap(vaddr, length, PROT_READ | PROT_WRITE,
-flags, block->fd, offset);
+MAP_FIXED | flags, block->fd, offset);
+} else if (kvm_enabled() && kvm_arch_ram_remap) {
+area = kvm_arch_ram_remap(vaddr, length);
} else {
-#if defined(TARGET_S390X) && defined(CONFIG_KVM)
-flags |= MAP_SHARED | MAP_ANONYMOUS;
-area = mmap(vaddr, length, PROT_EXEC|PROT_READ|PROT_WRITE,
-flags, -1, 0);
-#else
-flags |= MAP_PRIVATE | MAP_ANONYMOUS;
area = mmap(vaddr, length, PROT_READ | PROT_WRITE,
-flags, -1, 0);
-#endif
+MAP_FIXED | MAP_PRIVATE | MAP_ANONYMOUS,
+-1, 0);
}
if (area != vaddr) {
fprintf(stderr, "Could not remap addr: "
diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
index dd79914..fdfa7ba 100644
--- a/include/sysemu/kvm.h
+++ b/include/sysemu/kvm.h
@@ -153,6 +153,7 @@ int kvm_cpu_exec(CPUArchState *env);
#if !defined(CONFIG_USER_ONLY)
extern void *(*kvm_arch_ram_alloc)(ram_addr_t size);
+extern void *(*kvm_arch_ram_remap)(void *vaddr, ram_addr_t size);
#endif
void kvm_setup_guest_memory(void *start, size_t size);
diff --git a/kvm-all.c b/kvm-all.c
index 5e0cc9b..daa4d40 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -120,6 +120,7 @@ static const KVMCapabilityInfo kvm_required_capabilites[] =
{
};
void *(*kvm_arch_ram_alloc)(ram_addr_t size);
+void *(*kvm_arch_ram_remap)(void *vaddr, ram_addr_t size);
static KVMSlot *kvm_alloc_slot(KVMState *s)
{
diff --git a/target-s390x/kvm.c b/target-s390x/kvm.c
index be802ab..aa45e06 100644
--- a/target-s390x/kvm.c
+++ b/target-s390x/kvm.c
@@ -93,6 +93,7 @@ const KVMCapabilityInfo kvm_arch_required_capabilities[] = {
static int cap_sync_regs;
static void *legacy_s390_alloc(ram_addr_t size);
+static void *legacy_s390_mmap(void *vaddr, ram_addr_t length);
int kvm_arch_init(KVMState *s)
{
@@ -100,6 +101,7 @@ int kvm_arch_init(KVMState *s)
if (!kvm_check_extension(s, KVM_CAP_S390_GMAP)
|| !kvm_check_extension(s, KVM_CAP_S390_COW)) {
kvm_arch_ram_alloc = legacy_s390_alloc;
+kvm_arch_ram_remap = legacy_s390_mmap;
}
return 0;
}
@@ -324,13 +326,16 @@ int kvm_s390_get_registers_partial(CPUState *cs)
* to grow. We also have to use MAP parameters that avoid
* read-only mapping of guest pages.
*/
-static void *legacy_s390_alloc(ram_addr_t size)
+
+static void *legacy_s390_mmap(void *vaddr, ram_addr_t size)
{
-void *mem;
+return mmap(vaddr, size, PROT_EXEC | PROT_READ | PROT_WRITE,
+MAP_FIXED | MAP_SHARED | MAP_ANONYMOUS, -1, 0);
+}
-mem = mmap((void *) 0x8ULL, size,
- PROT_EXEC|PROT_READ|PROT_WRITE,
- MAP_SHARED | MAP_ANONYMOUS | MAP_FIXED, -1, 0);
+static void *legacy_s390_alloc(ram_addr_t size)
+{
+void *mem = legacy_s390_mmap((void *) 0x8ULL, size);
if (mem == MAP_FAILED) {
fprintf(stderr, "Allocating RAM failed\n");
abort();
--
1.7.11.7
[Qemu-devel] [PATCH RFC 2/8] exec: Clean up fall back when -mem-path allocation fails
With -mem-path, qemu_ram_alloc_from_ptr() first tries to allocate
accordingly, but when it fails, it falls back to normal allocation.
The fall back allocation code used to be effectively identical to the
"-mem-path not given" code, until it started to diverge incommit
432d268. I believe the code still works, but clean it up anyway: drop
the special fall back allocation code, and fall back to the ordinary
"-mem-path not given" code instead.
Signed-off-by: Markus Armbruster
---
exec.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/exec.c b/exec.c
index b424e12..56c31a9 100644
--- a/exec.c
+++ b/exec.c
@@ -1091,15 +1091,12 @@ ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size,
void *host,
if (mem_path) {
#if defined (__linux__) && !defined(TARGET_S390X)
new_block->host = file_ram_alloc(new_block, size, mem_path);
-if (!new_block->host) {
-new_block->host = qemu_anon_ram_alloc(size);
-memory_try_enable_merging(new_block->host, size);
-}
#else
fprintf(stderr, "-mem-path option unsupported\n");
exit(1);
#endif
-} else {
+}
+if (!new_block->host) {
if (kvm_enabled()) {
/* some s390/kvm configurations have special constraints */
new_block->host = kvm_ram_alloc(size);
--
1.7.11.7
[Qemu-devel] [PATCH RFC 0/8] Guest memory allocation fixes & cleanup
All I wanted to do is exit(1) instead of abort() on guest memory allocation failure [07/08]. But that lead me into a minor #ifdef bog, and here's what I brought back. Enjoy! Markus Armbruster (8): exec: Fix Xen RAM allocation with unusual options exec: Clean up fall back when -mem-path allocation fails exec: Reduce ifdeffery around -mem-path s390: Simplify the RAM allocation hook s390: Make qemu_ram_remap() consistent with allocation exec: Clean up unnecessary S390 ifdeffery exec: Don't abort when we can't allocate guest memory pc_sysfw: Fix ISA BIOS init for ridiculously big flash exec.c | 117 - hw/block/pc_sysfw.c| 5 +-- include/exec/cpu-all.h | 2 - include/sysemu/kvm.h | 4 +- kvm-all.c | 16 ++- target-s390x/kvm.c | 34 +++--- util/oslib-posix.c | 4 +- util/oslib-win32.c | 5 +-- 8 files changed, 81 insertions(+), 106 deletions(-) -- 1.7.11.7
Re: [Qemu-devel] [libvirt] Upstream : virt-install and virt-manager fails to install the guest with the error "qemu: could not load PC BIOS 'bios.bin'"
On 06/12/2013 04:29 PM, chandrashekar shastri wrote: > > Hi All, > > Upstream : virt-install and virt-manager fails to install the guest with > the error "qemu: could not load PC BIOS 'bios.bin'" > You are missing bios package for that. This depends on the distro you're using, but probably seabios-bin (vgabios, etc., I don't know the names) could help. The problem is, however, not caused by you, qemu itself should have it as a dependency. > Kernel, Qemu, Libvirt, Virt-Manager is built from the source (git). > > kernel version : 3.9.0+ > qemu version : QEMU emulator version 1.5.0 > libvirt version : 1.0.5 > virt-install : 0.600.3 > >From what I know, this should've been fixed [1] in QEMU 1.4.0, but that might be distribution specific as well. I guess specific machine types might require specific BIOSes to be installed. Hope that helps, Martin [1] https://bugzilla.redhat.com/show_bug.cgi?id=901542 > > Guest installation fails for Standard PC machine type. > > virt-install --name vm_name --cdrom --disk --ram > 2000 --machine pc > > Starting install... > ERRORinternal error process exited while connecting to monitor: char > device redirected to /dev/pts/1 > qemu: could not load PC BIOS 'bios.bin' > > Domain installation does not appear to have been successful. > If it was, you can restart your domain by running: > virsh --connect qemu:///system start win7 > otherwise, please restart your installation. > > Where as the qemu installation succeeds with the same machine type > (standard pc) > > qemu-system-x86_64 -cdrom -hda -boot d -m 1000 > -machine pc > > Below is the list of supported machine type: > > qemu-system-x86_64 -M ? > Supported machines are: > none empty machine > pc Standard PC (i440FX + PIIX, 1996) (alias of > pc-i440fx-1.5) > pc-i440fx-1.5Standard PC (i440FX + PIIX, 1996) (default) > pc-i440fx-1.4Standard PC (i440FX + PIIX, 1996) > pc-1.3 Standard PC > pc-1.2 Standard PC > pc-1.1 Standard PC > pc-1.0 Standard PC > pc-0.15 Standard PC > pc-0.14 Standard PC > pc-0.13 Standard PC > pc-0.12 Standard PC > pc-0.11 Standard PC, qemu 0.11 > pc-0.10 Standard PC, qemu 0.10 > isapcISA-only PC > q35 Standard PC (Q35 + ICH9, 2009) (alias of pc-q35-1.5) > pc-q35-1.5 Standard PC (Q35 + ICH9, 2009) > pc-q35-1.4 Standard PC (Q35 + ICH9, 2009) > > Installation fails (virt-install) for all machine types expect > pc-i440fx-1.5 and pc-i440fx-1.4. > > Thanks, > Chandrashekar > > > -- > libvir-list mailing list > libvir-l...@redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Qemu-devel] [RESEND PATCH] virtio-scsi: forward scsibus for virtio-scsi-pci.
On Thu, Jun 13, 2013 at 04:46:09PM +1000, Alexey Kardashevskiy wrote:
> On 06/13/2013 04:28 PM, Frederic Konrad wrote:
> > On 12/06/2013 13:21, Alexey Kardashevskiy wrote:
> >> On 06/12/2013 07:16 PM, Michael S. Tsirkin wrote:
> >>> On Wed, Jun 12, 2013 at 07:04:48PM +1000, Alexey Kardashevskiy wrote:
> On 06/12/2013 07:03 PM, Michael S. Tsirkin wrote:
> > On Wed, Jun 12, 2013 at 08:15:17AM +0200, fred.kon...@greensocs.com
> > wrote:
> >> From: KONRAD Frederic
> >>
> >> This fix a bug with scsi hotplug on virtio-scsi-pci:
> >>
> >> As virtio-scsi-pci doesn't have any scsi bus, we need to forward
> >> scsi-hot-add
> >> to the virtio-scsi-device plugged on the virtio-bus.
> >>
> >> Cc: qemu-sta...@nongnu.org
> >> Reported-by: Alexey Kardashevskiy
> >> Reviewed-by: Andreas Färber
> >> Signed-off-by: KONRAD Frederic
> > Acked-by: Michael S. Tsirkin
> >
> > Note: we don't seem to have any decent way to
> > add disks to devices: no QMP interface,
> > pci address is required instead of using an id ...
> >
> > Anyone can be bothered to fix this?
>
> Actually PCI address is not always required, this field (we are talking
> about "drive_add"?) is ignored when "if=none".
>
> >>> Then documentation in hmp-commands.hx is wrong, isn't it?
> >>> Add that to the list.
> >>>
> >>> if=none can't be actually used to hot-add
> >>> a disk to a device, can it? It creates a disc and assumes you will
> >>> use it by a device created later.
> >>
> >> Yep. I run QEMU with -device "virtio-scsi-pci,id=device0" and then do in
> >> console:
> >> drive_add auto file=virtimg/fc18guest,if=none,id=bar1
> >> device_add scsi-disk,bus=device0.0,drive=bar1
> >>
> >> Pretty hot plug :)
> >
> > I thought you use drive_add 0 if=scsi?
>
>
> That's the other option, I posted a bug but I did not actually try the fix
> till now :)
>
> It works now if I run QEMU with "-device virtio-scsi-pci" and do this in
> qemu console:
> drive_add 0 file=virtimg/fc18guest
>
> No extra parameters or anything, cool, thanks, and :)
>
> Tested-by: Alexey Kardashevskiy
>
>
> The only problem with it that it still wants PCI SCSI adapter while
> spapr-vscsi is VIO device so if the guest kernel does not have virtio-scsi
> support, I have to do what I described in the quote but this is a different
> story.
Okay. How about:
- document that pci_addr is optional in hmp
- if no pci_addr assume if=none
- add drive_add to qmp without the pci_addr and if options
We are left with the bus=device0.0 syntax for device_add which is also
gross - user asked for device0, the .0 part is qemu internals exposed to
users.
How about teaching qdev that if there's a single bus under a device,
naming the device itself should be identical?
This will solve the problem neatly without virtio specific hacks,
won't it?
>
>
> >>
> >>
> >>>
> >> ---
> >> hw/pci/pci-hotplug.c | 19 +--
> >> 1 file changed, 17 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/hw/pci/pci-hotplug.c b/hw/pci/pci-hotplug.c
> >> index 12287d1..c708752 100644
> >> --- a/hw/pci/pci-hotplug.c
> >> +++ b/hw/pci/pci-hotplug.c
> >> @@ -30,6 +30,8 @@
> >> #include "monitor/monitor.h"
> >> #include "hw/scsi/scsi.h"
> >> #include "hw/virtio/virtio-blk.h"
> >> +#include "hw/virtio/virtio-scsi.h"
> >> +#include "hw/virtio/virtio-pci.h"
> >> #include "qemu/config-file.h"
> >> #include "sysemu/blockdev.h"
> >> #include "qapi/error.h"
> >> @@ -79,13 +81,26 @@ static int scsi_hot_add(Monitor *mon, DeviceState
> >> *adapter,
> >> {
> >> SCSIBus *scsibus;
> >> SCSIDevice *scsidev;
> >> +VirtIOPCIProxy *virtio_proxy;
> >> scsibus = (SCSIBus *)
> >> object_dynamic_cast(OBJECT(QLIST_FIRST(&adapter->child_bus)),
> >> TYPE_SCSI_BUS);
> >> if (!scsibus) {
> >> -error_report("Device is not a SCSI adapter");
> >> -return -1;
> >> +/*
> >> + * Check if the adapter is a virtio-scsi-pci, and forward
> >> scsi_hot_add
> >> + * to the virtio-scsi-device.
> >> + */
> >> +if (!object_dynamic_cast(OBJECT(adapter),
> >> TYPE_VIRTIO_SCSI_PCI)) {
> >> +error_report("Device is not a SCSI adapter");
> >> +return -1;
> >> +}
> >> +virtio_proxy = VIRTIO_PCI(adapter);
> >> +adapter = DEVICE(virtio_proxy->bus.vdev);
> >> +scsibus = (SCSIBus *)
> >> +
> >> object_dynamic_cast(OBJECT(QLIST_FIRST(&adapter->child_bus)),
> >> +TYPE_SCSI_BUS);
> >> +assert(scsibus);
> >> }
> >> /*
> >>
> >
>
>
> --
> Alexey
[Qemu-devel] [PATCH RFC 4/8] s390: Simplify the RAM allocation hook
Less code and ifdeffery.
Signed-off-by: Markus Armbruster
---
exec.c | 4 ++--
include/sysemu/kvm.h | 3 +--
kvm-all.c| 15 ++-
target-s390x/kvm.c | 17 ++---
4 files changed, 11 insertions(+), 28 deletions(-)
diff --git a/exec.c b/exec.c
index 4dbb0f1..7552e3c 100644
--- a/exec.c
+++ b/exec.c
@@ -1098,9 +1098,9 @@ ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size, void
*host,
#endif
}
if (!new_block->host) {
-if (kvm_enabled()) {
+if (kvm_enabled() && kvm_arch_ram_alloc) {
/* some s390/kvm configurations have special constraints */
-new_block->host = kvm_ram_alloc(size);
+new_block->host = kvm_arch_ram_alloc(size);
} else {
new_block->host = qemu_anon_ram_alloc(size);
}
diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
index 8b19322..dd79914 100644
--- a/include/sysemu/kvm.h
+++ b/include/sysemu/kvm.h
@@ -152,8 +152,7 @@ int kvm_init_vcpu(CPUState *cpu);
int kvm_cpu_exec(CPUArchState *env);
#if !defined(CONFIG_USER_ONLY)
-void *kvm_ram_alloc(ram_addr_t size);
-void *kvm_arch_ram_alloc(ram_addr_t size);
+extern void *(*kvm_arch_ram_alloc)(ram_addr_t size);
#endif
void kvm_setup_guest_memory(void *start, size_t size);
diff --git a/kvm-all.c b/kvm-all.c
index 405480e..5e0cc9b 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -119,6 +119,8 @@ static const KVMCapabilityInfo kvm_required_capabilites[] =
{
KVM_CAP_LAST_INFO
};
+void *(*kvm_arch_ram_alloc)(ram_addr_t size);
+
static KVMSlot *kvm_alloc_slot(KVMState *s)
{
int i;
@@ -1816,19 +1818,6 @@ int kvm_has_intx_set_mask(void)
return kvm_state->intx_set_mask;
}
-void *kvm_ram_alloc(ram_addr_t size)
-{
-#ifdef TARGET_S390X
-void *mem;
-
-mem = kvm_arch_ram_alloc(size);
-if (mem) {
-return mem;
-}
-#endif
-return qemu_anon_ram_alloc(size);
-}
-
void kvm_setup_guest_memory(void *start, size_t size)
{
#ifdef CONFIG_VALGRIND_H
diff --git a/target-s390x/kvm.c b/target-s390x/kvm.c
index 862fb12..be802ab 100644
--- a/target-s390x/kvm.c
+++ b/target-s390x/kvm.c
@@ -92,9 +92,15 @@ const KVMCapabilityInfo kvm_arch_required_capabilities[] = {
static int cap_sync_regs;
+static void *legacy_s390_alloc(ram_addr_t size);
+
int kvm_arch_init(KVMState *s)
{
cap_sync_regs = kvm_check_extension(s, KVM_CAP_SYNC_REGS);
+if (!kvm_check_extension(s, KVM_CAP_S390_GMAP)
+|| !kvm_check_extension(s, KVM_CAP_S390_COW)) {
+kvm_arch_ram_alloc = legacy_s390_alloc;
+}
return 0;
}
@@ -332,17 +338,6 @@ static void *legacy_s390_alloc(ram_addr_t size)
return mem;
}
-void *kvm_arch_ram_alloc(ram_addr_t size)
-{
-/* Can we use the standard allocation ? */
-if (kvm_check_extension(kvm_state, KVM_CAP_S390_GMAP) &&
-kvm_check_extension(kvm_state, KVM_CAP_S390_COW)) {
-return NULL;
-} else {
-return legacy_s390_alloc(size);
-}
-}
-
int kvm_arch_insert_sw_breakpoint(CPUState *cs, struct kvm_sw_breakpoint *bp)
{
S390CPU *cpu = S390_CPU(cs);
--
1.7.11.7
Re: [Qemu-devel] [RESEND PATCH] virtio-scsi: forward scsibus for virtio-scsi-pci.
On 13/06/2013 09:23, Michael S. Tsirkin wrote:
On Thu, Jun 13, 2013 at 04:46:09PM +1000, Alexey Kardashevskiy wrote:
On 06/13/2013 04:28 PM, Frederic Konrad wrote:
On 12/06/2013 13:21, Alexey Kardashevskiy wrote:
On 06/12/2013 07:16 PM, Michael S. Tsirkin wrote:
On Wed, Jun 12, 2013 at 07:04:48PM +1000, Alexey Kardashevskiy wrote:
On 06/12/2013 07:03 PM, Michael S. Tsirkin wrote:
On Wed, Jun 12, 2013 at 08:15:17AM +0200, fred.kon...@greensocs.com
wrote:
From: KONRAD Frederic
This fix a bug with scsi hotplug on virtio-scsi-pci:
As virtio-scsi-pci doesn't have any scsi bus, we need to forward
scsi-hot-add
to the virtio-scsi-device plugged on the virtio-bus.
Cc: qemu-sta...@nongnu.org
Reported-by: Alexey Kardashevskiy
Reviewed-by: Andreas Färber
Signed-off-by: KONRAD Frederic
Acked-by: Michael S. Tsirkin
Note: we don't seem to have any decent way to
add disks to devices: no QMP interface,
pci address is required instead of using an id ...
Anyone can be bothered to fix this?
Actually PCI address is not always required, this field (we are talking
about "drive_add"?) is ignored when "if=none".
Then documentation in hmp-commands.hx is wrong, isn't it?
Add that to the list.
if=none can't be actually used to hot-add
a disk to a device, can it? It creates a disc and assumes you will
use it by a device created later.
Yep. I run QEMU with -device "virtio-scsi-pci,id=device0" and then do in
console:
drive_add auto file=virtimg/fc18guest,if=none,id=bar1
device_add scsi-disk,bus=device0.0,drive=bar1
Pretty hot plug :)
I thought you use drive_add 0 if=scsi?
That's the other option, I posted a bug but I did not actually try the fix
till now :)
It works now if I run QEMU with "-device virtio-scsi-pci" and do this in
qemu console:
drive_add 0 file=virtimg/fc18guest
No extra parameters or anything, cool, thanks, and :)
Tested-by: Alexey Kardashevskiy
The only problem with it that it still wants PCI SCSI adapter while
spapr-vscsi is VIO device so if the guest kernel does not have virtio-scsi
support, I have to do what I described in the quote but this is a different
story.
Okay. How about:
- document that pci_addr is optional in hmp
- if no pci_addr assume if=none
- add drive_add to qmp without the pci_addr and if options
We are left with the bus=device0.0 syntax for device_add which is also
gross - user asked for device0, the .0 part is qemu internals exposed to
users.
How about teaching qdev that if there's a single bus under a device,
naming the device itself should be identical?
Yes why not seems a good idea, but you'll pass it through bus= option?
This will solve the problem neatly without virtio specific hacks,
won't it?
The issue here is command line back-compatibility for pci_addr, which
won't be solved with
the "single bus" idea?
---
hw/pci/pci-hotplug.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/hw/pci/pci-hotplug.c b/hw/pci/pci-hotplug.c
index 12287d1..c708752 100644
--- a/hw/pci/pci-hotplug.c
+++ b/hw/pci/pci-hotplug.c
@@ -30,6 +30,8 @@
#include "monitor/monitor.h"
#include "hw/scsi/scsi.h"
#include "hw/virtio/virtio-blk.h"
+#include "hw/virtio/virtio-scsi.h"
+#include "hw/virtio/virtio-pci.h"
#include "qemu/config-file.h"
#include "sysemu/blockdev.h"
#include "qapi/error.h"
@@ -79,13 +81,26 @@ static int scsi_hot_add(Monitor *mon, DeviceState
*adapter,
{
SCSIBus *scsibus;
SCSIDevice *scsidev;
+VirtIOPCIProxy *virtio_proxy;
scsibus = (SCSIBus *)
object_dynamic_cast(OBJECT(QLIST_FIRST(&adapter->child_bus)),
TYPE_SCSI_BUS);
if (!scsibus) {
-error_report("Device is not a SCSI adapter");
-return -1;
+/*
+ * Check if the adapter is a virtio-scsi-pci, and forward
scsi_hot_add
+ * to the virtio-scsi-device.
+ */
+if (!object_dynamic_cast(OBJECT(adapter),
TYPE_VIRTIO_SCSI_PCI)) {
+error_report("Device is not a SCSI adapter");
+return -1;
+}
+virtio_proxy = VIRTIO_PCI(adapter);
+adapter = DEVICE(virtio_proxy->bus.vdev);
+scsibus = (SCSIBus *)
+
object_dynamic_cast(OBJECT(QLIST_FIRST(&adapter->child_bus)),
+TYPE_SCSI_BUS);
+assert(scsibus);
}
/*
--
Alexey
[Qemu-devel] solaris x86 in qemu?
Hello. In order to verify some build issues on solaris, I tried to install sol10 x86 in a kvm vm. But unfortunately it does not work: after the grub prompt and choosing "Solaris 10 x86" boot entry, the kernel gets loaded (there's a row of dots displayed during that), next, the following message gets displayed: SunOS Release 5.10 Version Generic_147148-26 64-bit Copyright (c) 1983, 2013 Oracle and/or its affiliates. All rights reserved. and the guest stays there for a long time, spinning up 100% of its CPU, and nothing more happens. The same happens when run with or without kvm (ie, tcg and kvm behaves the same way). When run in kvm, kvm_stats shows just a few exits (about 600/sec) and nothing more than that. Any idea what to do with that? I think that supporting solaris as _guest_ OS is an important goal for qemu/kvm (as opposed to _host_). Thanks, /mjt
Re: [Qemu-devel] [RESEND PATCH] virtio-scsi: forward scsibus for virtio-scsi-pci.
On Thu, Jun 13, 2013 at 09:34:30AM +0200, Frederic Konrad wrote:
> On 13/06/2013 09:23, Michael S. Tsirkin wrote:
> >On Thu, Jun 13, 2013 at 04:46:09PM +1000, Alexey Kardashevskiy wrote:
> >>On 06/13/2013 04:28 PM, Frederic Konrad wrote:
> >>>On 12/06/2013 13:21, Alexey Kardashevskiy wrote:
> On 06/12/2013 07:16 PM, Michael S. Tsirkin wrote:
> >On Wed, Jun 12, 2013 at 07:04:48PM +1000, Alexey Kardashevskiy wrote:
> >>On 06/12/2013 07:03 PM, Michael S. Tsirkin wrote:
> >>>On Wed, Jun 12, 2013 at 08:15:17AM +0200, fred.kon...@greensocs.com
> >>>wrote:
> From: KONRAD Frederic
>
> This fix a bug with scsi hotplug on virtio-scsi-pci:
>
> As virtio-scsi-pci doesn't have any scsi bus, we need to forward
> scsi-hot-add
> to the virtio-scsi-device plugged on the virtio-bus.
>
> Cc: qemu-sta...@nongnu.org
> Reported-by: Alexey Kardashevskiy
> Reviewed-by: Andreas Färber
> Signed-off-by: KONRAD Frederic
> >>>Acked-by: Michael S. Tsirkin
> >>>
> >>>Note: we don't seem to have any decent way to
> >>>add disks to devices: no QMP interface,
> >>>pci address is required instead of using an id ...
> >>>
> >>>Anyone can be bothered to fix this?
> >>Actually PCI address is not always required, this field (we are talking
> >>about "drive_add"?) is ignored when "if=none".
> >>
> >Then documentation in hmp-commands.hx is wrong, isn't it?
> >Add that to the list.
> >
> >if=none can't be actually used to hot-add
> >a disk to a device, can it? It creates a disc and assumes you will
> >use it by a device created later.
> Yep. I run QEMU with -device "virtio-scsi-pci,id=device0" and then do in
> console:
> drive_add auto file=virtimg/fc18guest,if=none,id=bar1
> device_add scsi-disk,bus=device0.0,drive=bar1
>
> Pretty hot plug :)
> >>>I thought you use drive_add 0 if=scsi?
> >>
> >>That's the other option, I posted a bug but I did not actually try the fix
> >>till now :)
> >>
> >>It works now if I run QEMU with "-device virtio-scsi-pci" and do this in
> >>qemu console:
> >>drive_add 0 file=virtimg/fc18guest
> >>
> >>No extra parameters or anything, cool, thanks, and :)
> >>
> >>Tested-by: Alexey Kardashevskiy
> >>
> >>
> >>The only problem with it that it still wants PCI SCSI adapter while
> >>spapr-vscsi is VIO device so if the guest kernel does not have virtio-scsi
> >>support, I have to do what I described in the quote but this is a different
> >>story.
> >Okay. How about:
> >- document that pci_addr is optional in hmp
> >- if no pci_addr assume if=none
> >- add drive_add to qmp without the pci_addr and if options
> >
> >We are left with the bus=device0.0 syntax for device_add which is also
> >gross - user asked for device0, the .0 part is qemu internals exposed to
> >users.
> >How about teaching qdev that if there's a single bus under a device,
> >naming the device itself should be identical?
>
> Yes why not seems a good idea, but you'll pass it through bus= option?
> >This will solve the problem neatly without virtio specific hacks,
> >won't it?
>
> The issue here is command line back-compatibility for pci_addr,
> which won't be solved with
> the "single bus" idea?
Why not? This code:
scsibus = (SCSIBus *)
object_dynamic_cast(OBJECT(QLIST_FIRST(&adapter->child_bus)),
TYPE_SCSI_BUS);
should be replaced with code from qdev that we'll write
that goes down the chain as long as there's 1 device
on each bus, looking for a device of the appropriate type.
> >
> >>
>
> ---
> hw/pci/pci-hotplug.c | 19 +--
> 1 file changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/hw/pci/pci-hotplug.c b/hw/pci/pci-hotplug.c
> index 12287d1..c708752 100644
> --- a/hw/pci/pci-hotplug.c
> +++ b/hw/pci/pci-hotplug.c
> @@ -30,6 +30,8 @@
> #include "monitor/monitor.h"
> #include "hw/scsi/scsi.h"
> #include "hw/virtio/virtio-blk.h"
> +#include "hw/virtio/virtio-scsi.h"
> +#include "hw/virtio/virtio-pci.h"
> #include "qemu/config-file.h"
> #include "sysemu/blockdev.h"
> #include "qapi/error.h"
> @@ -79,13 +81,26 @@ static int scsi_hot_add(Monitor *mon, DeviceState
> *adapter,
> {
> SCSIBus *scsibus;
> SCSIDevice *scsidev;
> +VirtIOPCIProxy *virtio_proxy;
> scsibus = (SCSIBus *)
>
> object_dynamic_cast(OBJECT(QLIST_FIRST(&adapter->child_bus)),
> TYPE_SCSI_BUS);
> if (!scsibus) {
> -error_report("Device is not a SCSI adapter");
> -return -1;
> +/*
> + * Check if the adapter is a virtio-scsi-pci, and forw
Re: [Qemu-devel] [PATCH v5 03/11] block: add basic backup support to block driver
于 2013-6-13 14:33, Fam Zheng 写道:
On Thu, 06/13 14:07, Wenchao Xia wrote:
于 2013-6-13 14:03, Wenchao Xia 写道:
于 2013-6-7 15:18, Stefan Hajnoczi 写道:
On Thu, Jun 06, 2013 at 04:56:49PM +0800, Fam Zheng wrote:
On Thu, 06/06 10:05, Stefan Hajnoczi wrote:
On Thu, Jun 06, 2013 at 11:56:18AM +0800, Fam Zheng wrote:
On Thu, 05/30 14:34, Stefan Hajnoczi wrote:
+
+static int coroutine_fn backup_before_write_notify(
+NotifierWithReturn *notifier,
+void *opaque)
+{
+BdrvTrackedRequest *req = opaque;
+
+return backup_do_cow(req->bs, req->sector_num,
req->nb_sectors, NULL);
+}
I'm wondering if we can see the logic here with a backing hd
relationship? req->bs is a backing file of job->target, but guest is
going to write to it, so we need to COW down the data to job->target
before overwritting (i.e. cluster is not allocated in child).
I think if we do this in block layer, there's not much necessity for a
before-write notifier here (although it may be useful for other
cases):
in bdrv_write:
for child in req->bs->open_children
if not child->is_allocated(req->sectors)
do COW to child
The advantage of this is that we won't need to start block-backup
job in
sync mode "none" to do point-in-time snapshot (image fleecing), and we
get writable snapshot (possibility to open backing file writable and
write to it safely) as a by-product.
But we will need to keep track of parent<->child of block states,
and we
still need to take care of overlapping writing between block job and
guest request.
There's one catch here: bs->target may not support backing files, it
can
be a raw file, for example. We'll only use backing files for
point-in-time snapshots but other use cases might not. raw doesn't
really implement is_allocated(), so the whole concept would have to
change a little:
Another use case may be parent modification. Suppose we have
,--- child1.qcow2
parent.qcow2 <
`--- child2.qcow2
We can use parent.qcow2 as block device in QEMU without breaking
child1.qcow2 or child2.qcow2 by telling QEMU who its children are:
$QEMU -drive file=parent.qcow2,children=child1.qcow2:child2.qcow2
Then we open the three images and setup parent_bs->open_children, the
children are protected from being corrupted.
bs->open_children becomes independent of backing files - any
BlockDriverState can be added to this list. ->is_allocated() basically
becomes the bitmap that we keep in the block job.
Yes. But it is possible to keep a bitmap for raw (and those don't
implement is_allocated()) in block layer too, or in overlay: could
add-cow by Dongxu Wang help here?
Yes absolutely.
Stefan
One advantage of external backup, or backing up chain, is that it
holds 'Delta' data only and is small enough. If it is changed toward a
'full' data writable snapshot, it become bigger. With backup chain
qemu-img can restore/clone a writable and usable one, So I don't
think adding that in qemu emulator helps much, and it will make things
more complicit user won't care who is doing the job, qemu or
qemu-img.
I mean that "get writable snapshot (possibility to open backing file
writable and write to it safely) as a by-product." in this series, is
not very valuable.
I'm not selling writable snapshot, my point was just that semantic of
block-backup, getting a point-in-time snapshot, inherently works like a
backing chain but writting to parent (guest drive) will not break its
children (our thin PIT snapshot). If we see it this way, COW is not so
specific to a block job like block-backup, it can be generic in the
backing chain logic.
OK, similar thing happens in drive-mirror, if you treat it as
backing chain. To do it, following assumption need to be removed:
1 top *bs is the active one.
2 guest write request goes only to top *bs.
3 *bs->backing_hd do not care about *bs(also a hidden change: maybe
image should remember its child as well as parent.)
Actually it will change the chain relationship from one direction of
top-down into both direction. I think a separate series is needed to
do that.
Though, the value in a writable snapshot is that we can actually
_modify_ a backing image in place, rather than forking the chain to
I can't see a good user case requiring modifying backing image in
place, to me snapshot means a read only one with time stamp in the past.
Personally I think forbid modification of of snapshot is correct,
in construction there should be pre-defined concepts to avoid
chaos in architecture.
write to the new child. This is not supported with qemu or qemu-img now,
once you create a child with the image as backing file, you mustn't
modify it.
--
Best Regards
Wenchao Xia
Re: [Qemu-devel] [PATCH RFC 4/8] s390: Simplify the RAM allocation hook
Am 13.06.2013 09:02, schrieb Markus Armbruster: > Less code and ifdeffery. > > Signed-off-by: Markus Armbruster Reviewed-by: Andreas Färber Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH] curl: refuse to open URL from HTTP server without range support
On Thu, Jun 13, 2013 at 4:13 AM, Fam Zheng wrote:
> On Tue, 06/11 09:40, Stefan Hajnoczi wrote:
>> On Tue, Jun 11, 2013 at 11:15:15AM +0800, Fam Zheng wrote:
>> > On Mon, Jun 10, 2013 at 5:21 PM, Stefan Hajnoczi
>> > wrote:
>> > > On Sun, Jun 09, 2013 at 10:34:54AM +0800, Fam Zheng wrote:
>> > >> @@ -110,14 +111,14 @@ static int curl_sock_cb(CURL *curl, curl_socket_t
>> > >> fd, int action,
>> > >> return 0;
>> > >> }
>> > >>
>> > >> -static size_t curl_size_cb(void *ptr, size_t size, size_t nmemb, void
>> > >> *opaque)
>> > >> +static size_t curl_header_cb(void *ptr, size_t size, size_t nmemb,
>> > >> void *opaque)
>> > >> {
>> > >> -CURLState *s = ((CURLState*)opaque);
>> > >> +BDRVCURLState *s = opaque;
>> > >> size_t realsize = size * nmemb;
>> > >> -size_t fsize;
>> > >> +const char *accept_line = "Accept-Ranges: bytes";
>> > >>
>> > >> -if(sscanf(ptr, "Content-Length: %zd", &fsize) == 1) {
>> > >> -s->s->len = fsize;
>> > >> +if (strncmp((char *)ptr, accept_line, strlen(accept_line)) == 0) {
>> > >> +s->accept_range = true;
>> > >> }
>> > >
>> > > This still assumes ptr is NUL-terminated. You need to pass size * nmemb
>> > > instead of strlen(accept_line).
>> > >
>> > OK, the case is so corner, only when :
>> > - realsize < strlen(accept_line) and
>> > - ptr is the first part of accept_line, without NUL-termination
>> > strncpm will possibly access no more than (strlen(accept_line) -
>> > realsize) bytes after ptr buffer.
>> >
>> > I'll need to check if realsize >= strlen(accept_line), not passing
>> > realsize.
>>
>> You can just pass size * nmemb because strncmp() does check for NUL in
>> both strings. Therefore strlen(accept_line) is not needed - you know
>> accept_line is NUL-terminated.
>>
>
> No, e.g. size * nmemb is 5, and *ptr is "Conte", passing size * nmemb to
> strncmp gets zero. We need to:
> * Ensure size * nmemb is no less than needed
That's true, it would match "Accept-". The libcurl docs do say that
only complete headers are provided but the server could return junk so
we need to be careful.
Re: [Qemu-devel] [PATCH 05/11] snapshot: add paired functions for internal snapshot id and name
On Thu, Jun 13, 2013 at 01:33:29PM +0800, Wenchao Xia wrote:
> 于 2013-6-11 17:14, Stefan Hajnoczi 写道:
> >On Sat, Jun 08, 2013 at 02:58:01PM +0800, Wenchao Xia wrote:
> >>+
> >>+/* Following function generate id string, used by block driver, such as
> >>qcow2.
> >>+ Since no better place to go, place the funtion here for now. */
> >>+void snapshot_id_string_generate(int id, char *id_str, int id_str_size)
> >>+{
> >>+snprintf(id_str, id_str_size, "%d", id);
> >>+}
> >
> >Since the caller has to manage id, this function doesn't really abstract
> >anything. I would keep the snprintf() inline, there's only one caller.
> >
> Its purpose is move the id rules from one implemention(qcow2) into
> generic. If not, it would be a question why snapshot_name_wellformed()
> could make sure name not conflict with ID, then reader find the answer
> in qcow2...
> I think at least a document is needed about how should implemention
> under ./block generate snapshot ID.
I see your point. Maybe keep the function. I was not sure because the
caller still has the int id and has to increment it. Therefore it
doesn't fully handle id generation.
Stefan
Re: [Qemu-devel] [PATCH] vmdk: byteswap VMDK4Header.desc_offset field
On Thu, Jun 13, 2013 at 10:06:43AM +0800, Fam Zheng wrote:
> On Mon, 06/10 16:32, Stefan Hajnoczi wrote:
> > On Mon, Jun 10, 2013 at 04:04:55PM +0200, Kevin Wolf wrote:
> > > Am 10.06.2013 um 11:07 hat Stefan Hajnoczi geschrieben:
> > > > Remember to byteswap VMDK4Header.desc_offset on big-endian machines.
> > > >
> > > > Cc: qemu-sta...@nongnu.org
> > > > Signed-off-by: Stefan Hajnoczi
> > >
> > > Thanks, applied to the block layer.
> > >
> > > > @@ -507,8 +507,11 @@ static int vmdk_open_vmdk4(BlockDriverState *bs,
> > > > if (ret < 0) {
> > > > return ret;
> > > > }
> > > > -if (header.capacity == 0 && header.desc_offset) {
> > > > -return vmdk_open_desc_file(bs, flags, header.desc_offset << 9);
> > > > +if (header.capacity == 0) {
> > > > +int64_t desc_offset = le64_to_cpu(header.desc_offset);
> > > > +if (desc_offset) {
> > > > +return vmdk_open_desc_file(bs, flags, desc_offset << 9);
> > > > +}
> > > > }
> > >
> > > Splitting up the if condition wouldn't have been necessary, strictly
> > > speaking. But I don't mind too much here.
> >
> > True. The reason I did it is because accessing header.desc_offset
> > directly is a bad habit. Someone modifying the code might conclude it's
> > safe to access directly when it actually only works for the limited
> > cases of zero and non-zero.
> >
>
> Not byteswapping header.capacity here, any reason?
Byteswapping header.capacity too is fine by me. This patch is focussed
on just header.desc_offset.
Stefan
Re: [Qemu-devel] [PATCH RFC 7/8] exec: Don't abort when we can't allocate guest memory
Am 13.06.2013 09:02, schrieb Markus Armbruster: > We abort() on memory allocation failure. abort() is appropriate for > programming errors. Maybe most memory allocation failures are > programming errors, maybe not. But guest memory allocation failure > isn't, and aborting when the user asks for more memory than we can > provide is not nice. exit(1) instead, and do it in just one place, so > the error message is consistent. > > Signed-off-by: Markus Armbruster Acked-by: Andreas Färber Thanks for looking into this! Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH] raw-posix: Fix /dev/cdrom magic on OS X
On Wed, Jun 12, 2013 at 04:22:52PM +0200, Kevin Wolf wrote: > The raw-posix driver has code to provide a /dev/cdrom on OS X even > though it doesn't really exist. However, since commit c66a6157 the real > filename is dismissed after finding it, so opening /dev/cdrom fails. > Put the filename back into the options QDict to make this work again. > > Cc: qemu-sta...@nongnu.org > Signed-off-by: Kevin Wolf > --- > block/raw-posix.c | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Stefan Hajnoczi
Re: [Qemu-devel] [PATCH v2] vmdk: refuse to open higher version than supported
On Thu, Jun 13, 2013 at 11:21:29AM +0800, Fam Zheng wrote: > Refuse to open higher version for safety. > > Although we try to be compatible with published VMDK spec, VMware has > newer version from ESXi 5.1 exported OVF/OVA, which we have no knowledge > what's changed in it. And it is very likely to have more new versions in > the future, so it's not safe to open them blindly. > > Signed-off-by: Fam Zheng > > --- > > v2: Report error and return -ENOTSUP. > > --- > block/vmdk.c | 9 + > 1 file changed, 9 insertions(+) Reviewed-by: Stefan Hajnoczi
Re: [Qemu-devel] [RFC] sanitize memory on system reset
On Thu, Jun 13, 2013 at 08:09:09AM +0200, Peter Lieven wrote: > I was thinking if it would be a good idea to zeroize all memory resources on > system reset and > madvise dontneed them afterwards. This would avoid system reset attacks in > case the attacker > has only access to the console of a vServer but not on the physical host and > it would shrink > RSS size of the vServer siginificantly. I wonder if you'll hit weird OS installers or PXE clients that rely on stashing stuff in memory across reset. Stefan
Re: [Qemu-devel] virsh live migration w/o shared storage fails with error as vm is not running
On Thu, Jun 13, 2013 at 10:31:04AM +0530, chandrashekar shastri wrote: > We are testing the upstream KVM with : > > Kernel, Qemu, Libvirt, Virt-Manager is built from the source (git). > > kernel version : 3.9.0+ > qemu version : QEMU emulator version 1.5.0 > libvirt version : 1.0.5 > virt-install : 0.600.3 > > I have followed the below steps to test the "Live migration w/o > shared storage" feature : > > 1. Created the qemu-img create -f qcow2 vm.qcow2 12G on the > destination host which is same as the source. > 2. Started the guest on the source > 3. Started the vncdisplay to monitor the guest > 4. Initiated the migration "virsh migrate --live rhel64-64 > qemu+ssh://9.126.89.202/system --verbose --copy-storage-all" > 5. It started the copying the storage from souce to destination > (conitinously monitored it was growing) > 6. Guest on the destination was paused and was running on the source > 7. At some point the VM on the source shutdown and got an error on > the vnc display as " Viewport:write: Broken pipe (32)" and the > VM on the destination was undefined. > > Below is the libvirt debug log, please let me with your comments. > > Debug log: > -- What about /var/log/libvirt/qemu/rhel64-64.log? That is the QEMU command-line and stderr log. Also can you try without copy-storage-all just to see if migration completes successfully? The guest will act weird once it migrates since the disk is zeroed but it will isolate the failure to --copy-storage-all. Stefan
Re: [Qemu-devel] [RFC] sanitize memory on system reset
On 13.06.2013 10:40, Stefan Hajnoczi wrote: On Thu, Jun 13, 2013 at 08:09:09AM +0200, Peter Lieven wrote: I was thinking if it would be a good idea to zeroize all memory resources on system reset and madvise dontneed them afterwards. This would avoid system reset attacks in case the attacker has only access to the console of a vServer but not on the physical host and it would shrink RSS size of the vServer siginificantly. I wonder if you'll hit weird OS installers or PXE clients that rely on stashing stuff in memory across reset. Mhh, that indeed would be weird. What do you think of the idea in general? You concerns could be addresses by adding a switch for this which defaults to off. Peter
Re: [Qemu-devel] [PATCH v2] create qemu_openpty_raw() helper function and move it to a separate file
Am 05.06.2013 17:25, schrieb Michael Tokarev: > In two places qemu uses openpty() which is very system-dependent, > and in both places the pty is switched to raw mode as well. > Make a wrapper function which does both steps, and move all the > system-dependent complexity into a separate file, together > with static/local implementations of openpty() and cfmakeraw() > from qemu-char.c. > > It is in a separate file, not part of oslib-posix.c, because > openpty() often resides in -lutil which is not linked to > every program qemu builds. > > This change removes #including of , > and other rather specific system headers out of qemu-common.h, > which isn't a place for such specific headers really. > > Signed-off-by: Michael Tokarev > --- > Changes since v1: > > - added a forgotten #include for *BSD, > which was recently added into qemu-common.h by > Brad Smith, and which I intended to use in > qemu-openpty.c too, but somehow forgot. > > And one extra comment. I especially took existing > code and used it almost unmodified, to have one > code moving change, with all other possible > improvements/cleanups to follow later. > > include/qemu-common.h | 15 +- > qemu-char.c | 77 ++-- > ui/gtk.c | 12 ++--- > util/Makefile.objs|2 +- > util/qemu-openpty.c | 135 > + > 5 files changed, 146 insertions(+), 95 deletions(-) > create mode 100644 util/qemu-openpty.c Git complains about a trailing white line in the new file. And unfortunately it doesn't build as-is: CCutil/qemu-openpty.o /home/andreas/QEMU/qemu/util/qemu-openpty.c:54: warning: ‘struct winsize’ declared inside parameter list /home/andreas/QEMU/qemu/util/qemu-openpty.c:54: warning: its scope is only this definition or declaration, which is probably not what you want /home/andreas/QEMU/qemu/util/qemu-openpty.c:54: warning: ‘struct termios’ declared inside parameter list /home/andreas/QEMU/qemu/util/qemu-openpty.c: In function ‘openpty’: /home/andreas/QEMU/qemu/util/qemu-openpty.c:75: warning: implicit declaration of function ‘tcgetattr’ /home/andreas/QEMU/qemu/util/qemu-openpty.c:75: warning: nested extern declaration of ‘tcgetattr’ /home/andreas/QEMU/qemu/util/qemu-openpty.c:83: error: ‘TIOCSWINSZ’ undeclared (first use in this function) /home/andreas/QEMU/qemu/util/qemu-openpty.c:83: error: (Each undeclared identifier is reported only once /home/andreas/QEMU/qemu/util/qemu-openpty.c:83: error: for each function it appears in.) /home/andreas/QEMU/qemu/util/qemu-openpty.c: At top level: /home/andreas/QEMU/qemu/util/qemu-openpty.c:94: warning: ‘struct termios’ declared inside parameter list /home/andreas/QEMU/qemu/util/qemu-openpty.c: In function ‘cfmakeraw’: /home/andreas/QEMU/qemu/util/qemu-openpty.c:96: error: dereferencing pointer to incomplete type /home/andreas/QEMU/qemu/util/qemu-openpty.c:97: error: ‘IGNBRK’ undeclared (first use in this function) /home/andreas/QEMU/qemu/util/qemu-openpty.c:97: error: ‘BRKINT’ undeclared (first use in this function) /home/andreas/QEMU/qemu/util/qemu-openpty.c:97: error: ‘PARMRK’ undeclared (first use in this function) /home/andreas/QEMU/qemu/util/qemu-openpty.c:97: error: ‘ISTRIP’ undeclared (first use in this function) /home/andreas/QEMU/qemu/util/qemu-openpty.c:97: error: ‘INLCR’ undeclared (first use in this function) /home/andreas/QEMU/qemu/util/qemu-openpty.c:97: error: ‘IGNCR’ undeclared (first use in this function) /home/andreas/QEMU/qemu/util/qemu-openpty.c:97: error: ‘ICRNL’ undeclared (first use in this function) /home/andreas/QEMU/qemu/util/qemu-openpty.c:97: error: ‘IXON’ undeclared (first use in this function) /home/andreas/QEMU/qemu/util/qemu-openpty.c:98: error: dereferencing pointer to incomplete type /home/andreas/QEMU/qemu/util/qemu-openpty.c:98: error: ‘OPOST’ undeclared (first use in this function) /home/andreas/QEMU/qemu/util/qemu-openpty.c:99: error: dereferencing pointer to incomplete type /home/andreas/QEMU/qemu/util/qemu-openpty.c:99: error: ‘ECHO’ undeclared (first use in this function) /home/andreas/QEMU/qemu/util/qemu-openpty.c:99: error: ‘ECHONL’ undeclared (first use in this function) /home/andreas/QEMU/qemu/util/qemu-openpty.c:99: error: ‘ICANON’ undeclared (first use in this function) /home/andreas/QEMU/qemu/util/qemu-openpty.c:99: error: ‘ISIG’ undeclared (first use in this function) /home/andreas/QEMU/qemu/util/qemu-openpty.c:99: error: ‘IEXTEN’ undeclared (first use in this function) /home/andreas/QEMU/qemu/util/qemu-openpty.c:100: error: dereferencing pointer to incomplete type /home/andreas/QEMU/qemu/util/qemu-openpty.c:100: error: ‘CSIZE’ undeclared (first use in this function) /home/andreas/QEMU/qemu/util/qemu-openpty.c:100: error: ‘PARENB’ undeclared (first use in this function) /home/andreas/QEMU/qemu/util/qemu-openpty.c:101: error: dereferencing pointer to incomplete type /home/andreas/QEMU/qemu/util/qemu-openpty.c:101: error: ‘CS8’ undec
Re: [Qemu-devel] about atexit() (was: [PATCH 5/5] hostmem: init/finalize hostmem listener)
On Thu, Jun 13, 2013 at 12:38 PM, Amos Kong wrote:
> On Mon, Apr 01, 2013 at 04:20:34PM +0800, Liu Ping Fan wrote:
>> From: Liu Ping Fan
>>
>> Signed-off-by: Liu Ping Fan
>> ---
>> vl.c |2 ++
>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/vl.c b/vl.c
>> index 7643f16..46a25cf 100644
>> --- a/vl.c
>> +++ b/vl.c
>> @@ -4157,6 +4157,7 @@ int main(int argc, char **argv, char **envp)
>> }
>>
>> os_set_line_buffering();
>> +hostmem_init();
>>
>> qemu_init_cpu_loop();
>> qemu_mutex_lock_iothread();
>> @@ -4174,6 +4175,7 @@ int main(int argc, char **argv, char **envp)
>>
>> /* clean up network at qemu process termination */
>> atexit(&net_cleanup);
>> +atexit(&hostmem_finalize);
>
>
> The func registered by atexit() can only be called at normal termination.
> If qemu process is abort() or killed by 'kill -9', the func won't be
> called.
>
> A known issue: at the abnormal termination, downscript could not be
> executed to cleanup tap device. Can we suggest user to clean network
> manually in this condition?
>
SIG_KILL leaves no opportunity for us to do extra things, so I think
your suggestion is the only way out.
>
>>
>> if (net_init_clients() < 0) {
>> exit(1);
>> --
>
> --
> Amos.
Re: [Qemu-devel] [PATCH 0/8] [PATCH RFC v2] s390-qemu: cpu hotplug
On 07/06/13 19:27, Jason J. Herne wrote: > Latest code for cpu Hotplug designed to be controled via the QOM > infrastructure. > cpu on S390 are treated as devices via a new platform independent > infrastructure I designed to allow this "new way" to exist with the "old way" > of representing cpus. > > The Qemu command line now allows "-device s390-cpu" which will instantiate a > cpu device. This is additive to anything that might be specified on the -smp > parameter. > > Devices can be hot plugged via the monitor command "device_add s390-cpu". > Hotplugged cpus are created in the configured state and can be used by the > guest after the guest onlines the cpu by: > "echo 1 > /sys/bus/cpu/devices/cpuN/online" > > Hot unplugging is currently not implemented by this code. Adding Viktor, Andreas. Andreas, since we are the first ones going forward with cpu is a device (on a command level) we still have to provide the old cpu_add and query commands to make libvirt work regarding cpu hotplugging. Are you ok with having the x86 commands as wrappers around the new ones? Christian
Re: [Qemu-devel] [RFC] sanitize memory on system reset
On 13.06.2013 10:40, Stefan Hajnoczi wrote: On Thu, Jun 13, 2013 at 08:09:09AM +0200, Peter Lieven wrote: I was thinking if it would be a good idea to zeroize all memory resources on system reset and madvise dontneed them afterwards. This would avoid system reset attacks in case the attacker has only access to the console of a vServer but not on the physical host and it would shrink RSS size of the vServer siginificantly. I wonder if you'll hit weird OS installers or PXE clients that rely on stashing stuff in memory across reset. One point: Wouldn't a memory test which some systems do at startup break these as well? Peter
Re: [Qemu-devel] [PATCH v5 03/11] block: add basic backup support to block driver
On Thu, Jun 13, 2013 at 02:33:40PM +0800, Fam Zheng wrote:
> On Thu, 06/13 14:07, Wenchao Xia wrote:
> > 于 2013-6-13 14:03, Wenchao Xia 写道:
> > >于 2013-6-7 15:18, Stefan Hajnoczi 写道:
> > >>On Thu, Jun 06, 2013 at 04:56:49PM +0800, Fam Zheng wrote:
> > >>>On Thu, 06/06 10:05, Stefan Hajnoczi wrote:
> > On Thu, Jun 06, 2013 at 11:56:18AM +0800, Fam Zheng wrote:
> > >On Thu, 05/30 14:34, Stefan Hajnoczi wrote:
> > >>+
> > >>+static int coroutine_fn backup_before_write_notify(
> > >>+NotifierWithReturn *notifier,
> > >>+void *opaque)
> > >>+{
> > >>+BdrvTrackedRequest *req = opaque;
> > >>+
> > >>+return backup_do_cow(req->bs, req->sector_num,
> > >>req->nb_sectors, NULL);
> > >>+}
> > >
> > >I'm wondering if we can see the logic here with a backing hd
> > >relationship? req->bs is a backing file of job->target, but guest is
> > >going to write to it, so we need to COW down the data to job->target
> > >before overwritting (i.e. cluster is not allocated in child).
> > >
> > >I think if we do this in block layer, there's not much necessity for a
> > >before-write notifier here (although it may be useful for other
> > >cases):
> > >
> > > in bdrv_write:
> > > for child in req->bs->open_children
> > > if not child->is_allocated(req->sectors)
> > > do COW to child
> > >
> > >The advantage of this is that we won't need to start block-backup
> > >job in
> > >sync mode "none" to do point-in-time snapshot (image fleecing), and we
> > >get writable snapshot (possibility to open backing file writable and
> > >write to it safely) as a by-product.
> > >
> > >But we will need to keep track of parent<->child of block states,
> > >and we
> > >still need to take care of overlapping writing between block job and
> > >guest request.
> >
> > There's one catch here: bs->target may not support backing files, it
> > can
> > be a raw file, for example. We'll only use backing files for
> > point-in-time snapshots but other use cases might not. raw doesn't
> > really implement is_allocated(), so the whole concept would have to
> > change a little:
> > >>>
> > >>>Another use case may be parent modification. Suppose we have
> > >>>
> > >>> ,--- child1.qcow2
> > >>> parent.qcow2 <
> > >>> `--- child2.qcow2
> > >>>
> > >>>We can use parent.qcow2 as block device in QEMU without breaking
> > >>>child1.qcow2 or child2.qcow2 by telling QEMU who its children are:
> > >>>
> > >>> $QEMU -drive file=parent.qcow2,children=child1.qcow2:child2.qcow2
> > >>>
> > >>>Then we open the three images and setup parent_bs->open_children, the
> > >>>children are protected from being corrupted.
> > >>>
> >
> > bs->open_children becomes independent of backing files - any
> > BlockDriverState can be added to this list. ->is_allocated() basically
> > becomes the bitmap that we keep in the block job.
> > >>>
> > >>>Yes. But it is possible to keep a bitmap for raw (and those don't
> > >>>implement is_allocated()) in block layer too, or in overlay: could
> > >>>add-cow by Dongxu Wang help here?
> > >>
> > >>Yes absolutely.
> > >>
> > >>Stefan
> > >>
> > > One advantage of external backup, or backing up chain, is that it
> > >holds 'Delta' data only and is small enough. If it is changed toward a
> > >'full' data writable snapshot, it become bigger. With backup chain
> > >qemu-img can restore/clone a writable and usable one, So I don't
> > >think adding that in qemu emulator helps much, and it will make things
> > >more complicit user won't care who is doing the job, qemu or
> > >qemu-img.
> > >
> > I mean that "get writable snapshot (possibility to open backing file
> > writable and write to it safely) as a by-product." in this series, is
> > not very valuable.
> >
>
> I'm not selling writable snapshot, my point was just that semantic of
> block-backup, getting a point-in-time snapshot, inherently works like a
> backing chain but writting to parent (guest drive) will not break its
> children (our thin PIT snapshot). If we see it this way, COW is not so
> specific to a block job like block-backup, it can be generic in the
> backing chain logic.
>
> Though, the value in a writable snapshot is that we can actually
> _modify_ a backing image in place, rather than forking the chain to
> write to the new child. This is not supported with qemu or qemu-img now,
> once you create a child with the image as backing file, you mustn't
> modify it.
Supporting writable snapshots in this style is like traditional LVM
snapshots, it requires O(n) writes where n is the number of children.
So it does not scale (LVM recently added the thin provisioning target to
use a shared storage pool and solve this problem).
The second challenge with writable snapshots is that you can only use
th
Re: [Qemu-devel] [PATCH v2 03/17] memory: add ref/unref calls
Fails on qtest_init() in tests/libqtest.c, "Broken pipe". I cannot easily
see what is wrong here with this patch but it is 100% reproducible on x86_64
:(
On 06/13/2013 04:28 PM, Alexey Kardashevskiy wrote:
> Hi!
>
> I do not know how (yet) but this patch breaks qtest on x86 (I bisected it):
>
>
> make check-qtest V=1
> QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64
> MALLOC_PERTURB_=${MALLOC_PERTURB_:-$((RANDOM % 255 + 1))} gtester -k
> --verbose -m=quick tests/fdc-test tests/ide-test tests/hd-geo-test
> tests/rtc-test tests/i440fx-test tests/fw_cfg-test
> TEST: tests/fdc-test... (pid=13049)
> Broken pipe
> FAIL: tests/fdc-test
> TEST: tests/ide-test... (pid=13053)
> /x86_64/ide/identify:
> Broken pipe
> FAIL
> GTester: last random seed: R02S2f8a8fd53ff256765db44cefb0a920ce
> (pid=13057)
> /x86_64/ide/bmdma/setup:
> Broken pipe
> FAIL
> GTester: last random seed: R02S0cec5d222cfd196e6e839e06d7ddde89
> (pid=13061)
> /x86_64/ide/bmdma/simple_rw: FAIL
> GTester: last random seed: R02S46a30a1ccd33dc104919118330810a85
> (pid=13062)
> /x86_64/ide/bmdma/short_prdt:FAIL
> GTester: last random seed: R02S19fdcc95895b870371ed5ddcc8b77eda
> (pid=13063)
>
> [...]
>
>
> On 06/04/2013 10:13 PM, Paolo Bonzini wrote:
>> Add ref/unref calls at the following places:
>>
>> - places where memory regions are stashed by a listener and
>> used outside the BQL (including in Xen or KVM).
>>
>> - memory_region_find callsites
>>
>> - creation of aliases and containers (only the aliased/contained
>> region gets a reference to avoid loops)
>>
>> - around calls to del_subregion/add_subregion, where the region
>> could disappear after the first call
>>
>> Signed-off-by: Paolo Bonzini
>> ---
>> exec.c| 6 +-
>> hw/core/loader.c | 1 +
>> hw/display/exynos4210_fimd.c | 6 ++
>> hw/display/framebuffer.c | 12 +++-
>> hw/i386/kvmvapic.c| 1 +
>> hw/misc/vfio.c| 2 ++
>> hw/virtio/dataplane/hostmem.c | 7 +++
>> hw/virtio/vhost.c | 2 ++
>> hw/virtio/virtio-balloon.c| 1 +
>> hw/xen/xen_pt.c | 4
>> include/hw/virtio/dataplane/hostmem.h | 1 +
>> kvm-all.c | 2 ++
>> memory.c | 20
>> target-arm/kvm.c | 2 ++
>> target-sparc/mmu_helper.c | 1 +
>> xen-all.c | 2 ++
>> 16 files changed, 64 insertions(+), 6 deletions(-)
--
Alexey
[Qemu-devel] [PATCH v2 0/6] port network layer onto glib
Currently, I drop slirp and frontend related code (I guess I can reuse some code by mdroth's QContext later). And this series only resolve the net core re-entrant problem. v1->v2: introduce netqueue re-entrant detection and defer it to BH Liu Ping Fan (6): net: introduce lock to protect NetQueue net: introduce lock to protect NetClientState's peer's access net: make netclient re-entrant with refcnt net: force NetQue opaque to be NetClientState net: defer nested call to BH net: hub use lock to protect ports list hw/core/qdev-properties-system.c | 14 + include/net/net.h| 10 include/net/queue.h | 2 +- net/hub.c| 28 - net/net.c| 124 +-- net/queue.c | 57 -- net/slirp.c | 3 +- 7 files changed, 225 insertions(+), 13 deletions(-) -- 1.8.1.4
[Qemu-devel] [PATCH v2 1/6] net: introduce lock to protect NetQueue
From: Liu Ping Fan
NetQueue will be accessed by nc and its peers at the same time,
need lock to protect it.
Signed-off-by: Liu Ping Fan
---
include/net/net.h | 1 +
net/queue.c | 13 +
2 files changed, 14 insertions(+)
diff --git a/include/net/net.h b/include/net/net.h
index 43d85a1..2f72b26 100644
--- a/include/net/net.h
+++ b/include/net/net.h
@@ -5,6 +5,7 @@
#include "qemu-common.h"
#include "qapi/qmp/qdict.h"
#include "qemu/option.h"
+#include "qemu/thread.h"
#include "net/queue.h"
#include "migration/vmstate.h"
#include "qapi-types.h"
diff --git a/net/queue.c b/net/queue.c
index 859d02a..c6d4241 100644
--- a/net/queue.c
+++ b/net/queue.c
@@ -53,6 +53,7 @@ struct NetQueue {
uint32_t nq_maxlen;
uint32_t nq_count;
+QemuMutex lock;
QTAILQ_HEAD(packets, NetPacket) packets;
unsigned delivering : 1;
@@ -68,6 +69,7 @@ NetQueue *qemu_new_net_queue(void *opaque)
queue->nq_maxlen = 1;
queue->nq_count = 0;
+qemu_mutex_init(&queue->lock);
QTAILQ_INIT(&queue->packets);
queue->delivering = 0;
@@ -96,7 +98,9 @@ static void qemu_net_queue_append(NetQueue *queue,
{
NetPacket *packet;
+qemu_mutex_lock(&queue->lock);
if (queue->nq_count >= queue->nq_maxlen && !sent_cb) {
+qemu_mutex_unlock(&queue->lock);
return; /* drop if queue full and no callback */
}
packet = g_malloc(sizeof(NetPacket) + size);
@@ -108,6 +112,7 @@ static void qemu_net_queue_append(NetQueue *queue,
queue->nq_count++;
QTAILQ_INSERT_TAIL(&queue->packets, packet, entry);
+qemu_mutex_unlock(&queue->lock);
}
static void qemu_net_queue_append_iov(NetQueue *queue,
@@ -121,7 +126,9 @@ static void qemu_net_queue_append_iov(NetQueue *queue,
size_t max_len = 0;
int i;
+qemu_mutex_lock(&queue->lock);
if (queue->nq_count >= queue->nq_maxlen && !sent_cb) {
+qemu_mutex_unlock(&queue->lock);
return; /* drop if queue full and no callback */
}
for (i = 0; i < iovcnt; i++) {
@@ -143,6 +150,7 @@ static void qemu_net_queue_append_iov(NetQueue *queue,
queue->nq_count++;
QTAILQ_INSERT_TAIL(&queue->packets, packet, entry);
+qemu_mutex_unlock(&queue->lock);
}
static ssize_t qemu_net_queue_deliver(NetQueue *queue,
@@ -229,6 +237,7 @@ void qemu_net_queue_purge(NetQueue *queue, NetClientState
*from)
{
NetPacket *packet, *next;
+qemu_mutex_lock(&queue->lock);
QTAILQ_FOREACH_SAFE(packet, &queue->packets, entry, next) {
if (packet->sender == from) {
QTAILQ_REMOVE(&queue->packets, packet, entry);
@@ -236,10 +245,12 @@ void qemu_net_queue_purge(NetQueue *queue, NetClientState
*from)
g_free(packet);
}
}
+qemu_mutex_unlock(&queue->lock);
}
bool qemu_net_queue_flush(NetQueue *queue)
{
+qemu_mutex_lock(&queue->lock);
while (!QTAILQ_EMPTY(&queue->packets)) {
NetPacket *packet;
int ret;
@@ -256,6 +267,7 @@ bool qemu_net_queue_flush(NetQueue *queue)
if (ret == 0) {
queue->nq_count++;
QTAILQ_INSERT_HEAD(&queue->packets, packet, entry);
+qemu_mutex_unlock(&queue->lock);
return false;
}
@@ -265,5 +277,6 @@ bool qemu_net_queue_flush(NetQueue *queue)
g_free(packet);
}
+qemu_mutex_unlock(&queue->lock);
return true;
}
--
1.8.1.4
[Qemu-devel] [PATCH v2 5/6] net: defer nested call to BH
From: Liu Ping Fan
Nested call caused by ->receive() will raise issue like deadlock,
so postphone it to BH.
Signed-off-by: Liu Ping Fan
---
net/queue.c | 40 ++--
1 file changed, 38 insertions(+), 2 deletions(-)
diff --git a/net/queue.c b/net/queue.c
index 58222b0..9c343ab 100644
--- a/net/queue.c
+++ b/net/queue.c
@@ -24,6 +24,8 @@
#include "net/queue.h"
#include "qemu/queue.h"
#include "net/net.h"
+#include "block/aio.h"
+#include "qemu/main-loop.h"
/* The delivery handler may only return zero if it will call
* qemu_net_queue_flush() when it determines that it is once again able
@@ -183,6 +185,22 @@ static ssize_t qemu_net_queue_deliver_iov(NetQueue *queue,
return ret;
}
+typedef struct NetQueBH {
+QEMUBH *bh;
+NetClientState *nc;
+} NetQueBH;
+
+static void qemu_net_queue_send_bh(void *opaque)
+{
+NetQueBH *q_bh = opaque;
+NetQueue *queue = q_bh->nc->send_queue;
+
+qemu_net_queue_flush(queue);
+netclient_unref(q_bh->nc);
+qemu_bh_delete(q_bh->bh);
+g_slice_free(NetQueBH, q_bh);
+}
+
ssize_t qemu_net_queue_send(NetQueue *queue,
NetClientState *sender,
unsigned flags,
@@ -192,8 +210,17 @@ ssize_t qemu_net_queue_send(NetQueue *queue,
{
ssize_t ret;
-if (queue->delivering || !qemu_can_send_packet_nolock(sender)) {
+if (queue->delivering || !qemu_can_send_packet_nolock(sender)
+|| sender->send_queue->delivering) {
qemu_net_queue_append(queue, sender, flags, data, size, sent_cb);
+/* Nested call will be deferred to BH */
+if (sender->send_queue->delivering) {
+NetQueBH *que_bh = g_slice_new(NetQueBH);
+que_bh->bh = qemu_bh_new(qemu_net_queue_send_bh, que_bh);
+que_bh->nc = queue->opaque;
+netclient_ref(queue->opaque);
+qemu_bh_schedule(que_bh->bh);
+}
return 0;
}
@@ -217,8 +244,17 @@ ssize_t qemu_net_queue_send_iov(NetQueue *queue,
{
ssize_t ret;
-if (queue->delivering || !qemu_can_send_packet_nolock(sender)) {
+if (queue->delivering || !qemu_can_send_packet_nolock(sender)
+|| sender->send_queue->delivering) {
qemu_net_queue_append_iov(queue, sender, flags, iov, iovcnt, sent_cb);
+/* Nested call will be deferred to BH */
+if (sender->send_queue->delivering) {
+NetQueBH *que_bh = g_slice_new(NetQueBH);
+que_bh->bh = qemu_bh_new(qemu_net_queue_send_bh, que_bh);
+que_bh->nc = queue->opaque;
+netclient_ref(queue->opaque);
+qemu_bh_schedule(que_bh->bh);
+}
return 0;
}
--
1.8.1.4
[Qemu-devel] [PATCH v2 3/6] net: make netclient re-entrant with refcnt
From: Liu Ping Fan
With refcnt, NetClientState's user can run agaist deleter.
Signed-off-by: Liu Ping Fan
---
hw/core/qdev-properties-system.c | 14
include/net/net.h| 3 +++
net/hub.c| 3 +++
net/net.c| 47 +---
net/slirp.c | 3 ++-
5 files changed, 66 insertions(+), 4 deletions(-)
diff --git a/hw/core/qdev-properties-system.c b/hw/core/qdev-properties-system.c
index 0eada32..41cc7e6 100644
--- a/hw/core/qdev-properties-system.c
+++ b/hw/core/qdev-properties-system.c
@@ -302,6 +302,7 @@ static void set_vlan(Object *obj, Visitor *v, void *opaque,
return;
}
+/* inc ref, released when unset property */
hubport = net_hub_port_find(id);
if (!hubport) {
error_set(errp, QERR_INVALID_PARAMETER_VALUE,
@@ -311,11 +312,24 @@ static void set_vlan(Object *obj, Visitor *v, void
*opaque,
*ptr = hubport;
}
+static void release_vlan(Object *obj, const char *name, void *opaque)
+{
+DeviceState *dev = DEVICE(obj);
+Property *prop = opaque;
+NICPeers *peers_ptr = qdev_get_prop_ptr(dev, prop);
+NetClientState **ptr = &peers_ptr->ncs[0];
+
+if (*ptr) {
+netclient_unref(*ptr);
+}
+}
+
PropertyInfo qdev_prop_vlan = {
.name = "vlan",
.print = print_vlan,
.get = get_vlan,
.set = set_vlan,
+.release = release_vlan,
};
int qdev_prop_set_drive(DeviceState *dev, const char *name,
diff --git a/include/net/net.h b/include/net/net.h
index ea46f13..1a31d1b 100644
--- a/include/net/net.h
+++ b/include/net/net.h
@@ -64,6 +64,7 @@ typedef struct NetClientInfo {
} NetClientInfo;
struct NetClientState {
+int ref;
NetClientInfo *info;
int link_down;
QTAILQ_ENTRY(NetClientState) next;
@@ -92,6 +93,8 @@ typedef struct NICState {
NetClientState *qemu_find_netdev(const char *id);
int qemu_find_net_clients_except(const char *id, NetClientState **ncs,
NetClientOptionsKind type, int max);
+void netclient_ref(NetClientState *nc);
+void netclient_unref(NetClientState *nc);
NetClientState *qemu_new_net_client(NetClientInfo *info,
NetClientState *peer,
const char *model,
diff --git a/net/hub.c b/net/hub.c
index df32074..9c6c559 100644
--- a/net/hub.c
+++ b/net/hub.c
@@ -201,6 +201,7 @@ NetClientState *net_hub_find_client_by_name(int hub_id,
const char *name)
peer = port->nc.peer;
if (peer && strcmp(peer->name, name) == 0) {
+netclient_ref(peer);
return peer;
}
}
@@ -223,6 +224,7 @@ NetClientState *net_hub_port_find(int hub_id)
QLIST_FOREACH(port, &hub->ports, next) {
nc = port->nc.peer;
if (!nc) {
+netclient_ref(&port->nc);
return &(port->nc);
}
}
@@ -231,6 +233,7 @@ NetClientState *net_hub_port_find(int hub_id)
}
nc = net_hub_add_port(hub_id, NULL);
+netclient_ref(nc);
return nc;
}
diff --git a/net/net.c b/net/net.c
index 717db12..478a719 100644
--- a/net/net.c
+++ b/net/net.c
@@ -45,6 +45,7 @@
# define CONFIG_NET_BRIDGE
#endif
+static QemuMutex net_clients_lock;
static QTAILQ_HEAD(, NetClientState) net_clients;
int default_net = 1;
@@ -165,6 +166,7 @@ static char *assign_name(NetClientState *nc1, const char
*model)
char buf[256];
int id = 0;
+qemu_mutex_lock(&net_clients_lock);
QTAILQ_FOREACH(nc, &net_clients, next) {
if (nc == nc1) {
continue;
@@ -173,6 +175,7 @@ static char *assign_name(NetClientState *nc1, const char
*model)
id++;
}
}
+qemu_mutex_unlock(&net_clients_lock);
snprintf(buf, sizeof(buf), "%s.%d", model, id);
@@ -203,9 +206,13 @@ static void qemu_net_client_setup(NetClientState *nc,
assert(!peer->peer);
nc->peer = peer;
peer->peer = nc;
+netclient_ref(peer);
+netclient_ref(nc);
}
qemu_mutex_init(&nc->peer_lock);
+qemu_mutex_lock(&net_clients_lock);
QTAILQ_INSERT_TAIL(&net_clients, nc, next);
+qemu_mutex_unlock(&net_clients_lock);
nc->send_queue = qemu_new_net_queue(nc);
nc->destructor = destructor;
@@ -221,6 +228,7 @@ NetClientState *qemu_new_net_client(NetClientInfo *info,
assert(info->size >= sizeof(NetClientState));
nc = g_malloc0(info->size);
+netclient_ref(nc);
qemu_net_client_setup(nc, info, peer, model, name,
qemu_net_client_destructor);
@@ -281,7 +289,9 @@ void *qemu_get_nic_opaque(NetClientState *nc)
static void qemu_cleanup_net_client(NetClientState *nc)
{
+qemu_mutex_lock(&net_clients_lock);
QTAILQ_REMOVE(&net_clients, nc, next);
+qemu_mutex_unlock(&net_clients_lock)
[Qemu-devel] [PATCH v2 2/6] net: introduce lock to protect NetClientState's peer's access
From: Liu Ping Fan
Introduce nc->peer_lock to shield off the race of nc->peer's reader and
deleter. With it, after deleter finish, no new qemu_send_packet_xx()
will append packet to peer->send_queue, therefore no new reference from
packet->sender to nc will exist in nc->peer->send_queue.
Signed-off-by: Liu Ping Fan
---
include/net/net.h | 6 +
net/net.c | 79 ---
net/queue.c | 4 +--
3 files changed, 83 insertions(+), 6 deletions(-)
diff --git a/include/net/net.h b/include/net/net.h
index 2f72b26..ea46f13 100644
--- a/include/net/net.h
+++ b/include/net/net.h
@@ -67,6 +67,10 @@ struct NetClientState {
NetClientInfo *info;
int link_down;
QTAILQ_ENTRY(NetClientState) next;
+/* protect the race access of peer only between reader and writer.
+ * to resolve the writer's race condition, resort on biglock.
+ */
+QemuMutex peer_lock;
NetClientState *peer;
NetQueue *send_queue;
char *model;
@@ -79,6 +83,7 @@ struct NetClientState {
typedef struct NICState {
NetClientState *ncs;
+NetClientState **pending_peer;
NICConf *conf;
void *opaque;
bool peer_deleted;
@@ -106,6 +111,7 @@ NetClientState *qemu_find_vlan_client_by_name(Monitor *mon,
int vlan_id,
const char *client_str);
typedef void (*qemu_nic_foreach)(NICState *nic, void *opaque);
void qemu_foreach_nic(qemu_nic_foreach func, void *opaque);
+int qemu_can_send_packet_nolock(NetClientState *sender);
int qemu_can_send_packet(NetClientState *nc);
ssize_t qemu_sendv_packet(NetClientState *nc, const struct iovec *iov,
int iovcnt);
diff --git a/net/net.c b/net/net.c
index 43a74e4..717db12 100644
--- a/net/net.c
+++ b/net/net.c
@@ -204,6 +204,7 @@ static void qemu_net_client_setup(NetClientState *nc,
nc->peer = peer;
peer->peer = nc;
}
+qemu_mutex_init(&nc->peer_lock);
QTAILQ_INSERT_TAIL(&net_clients, nc, next);
nc->send_queue = qemu_new_net_queue(nc);
@@ -243,6 +244,7 @@ NICState *qemu_new_nic(NetClientInfo *info,
nic->ncs = (void *)nic + info->size;
nic->conf = conf;
nic->opaque = opaque;
+nic->pending_peer = g_malloc0(sizeof(NetClientState *) * queues);
for (i = 0; i < queues; i++) {
qemu_net_client_setup(&nic->ncs[i], info, peers[i], model, name,
@@ -301,6 +303,38 @@ static void qemu_free_net_client(NetClientState *nc)
}
}
+/* elimate the reference and sync with exit of rx/tx action.
+ * And flush out peer's queue.
+ */
+static void qemu_net_client_detach_flush(NetClientState *nc)
+{
+NetClientState *peer;
+
+/* reader of self's peer field , fixme? the deleters are not concurrent,
+ * so this pair lock can save.
+ */
+qemu_mutex_lock(&nc->peer_lock);
+peer = nc->peer;
+qemu_mutex_unlock(&nc->peer_lock);
+
+/* writer of peer's peer field*/
+if (peer) {
+/* exclude the race with tx to @nc */
+qemu_mutex_lock(&peer->peer_lock);
+peer->peer = NULL;
+qemu_mutex_unlock(&peer->peer_lock);
+}
+
+/* writer of self's peer field*/
+/* exclude the race with tx from @nc */
+qemu_mutex_lock(&nc->peer_lock);
+nc->peer = NULL;
+if (peer) {
+qemu_net_queue_purge(peer->send_queue, nc);
+}
+qemu_mutex_unlock(&nc->peer_lock);
+}
+
void qemu_del_net_client(NetClientState *nc)
{
NetClientState *ncs[MAX_QUEUE_NUM];
@@ -331,7 +365,9 @@ void qemu_del_net_client(NetClientState *nc)
}
for (i = 0; i < queues; i++) {
+qemu_net_client_detach_flush(ncs[i]);
qemu_cleanup_net_client(ncs[i]);
+nic->pending_peer[i] = ncs[i];
}
return;
@@ -340,6 +376,7 @@ void qemu_del_net_client(NetClientState *nc)
assert(nc->info->type != NET_CLIENT_OPTIONS_KIND_NIC);
for (i = 0; i < queues; i++) {
+qemu_net_client_detach_flush(ncs[i]);
qemu_cleanup_net_client(ncs[i]);
qemu_free_net_client(ncs[i]);
}
@@ -352,17 +389,19 @@ void qemu_del_nic(NICState *nic)
/* If this is a peer NIC and peer has already been deleted, free it now. */
if (nic->peer_deleted) {
for (i = 0; i < queues; i++) {
-qemu_free_net_client(qemu_get_subqueue(nic, i)->peer);
+qemu_free_net_client(nic->pending_peer[i]);
}
}
for (i = queues - 1; i >= 0; i--) {
NetClientState *nc = qemu_get_subqueue(nic, i);
+qemu_net_client_detach_flush(nc);
qemu_cleanup_net_client(nc);
qemu_free_net_client(nc);
}
+g_free(nic->pending_peer);
g_free(nic);
}
@@ -379,7 +418,7 @@ void qemu_foreach_nic(qemu_nic_foreach func, void *opaque)
}
}
-int qemu_can_send_packet(NetClientState *sender)
+int qemu_can_send_packet_nolock(NetClientState *sender)
{
if (!sender->peer) {
return 1;
@@
[Qemu-devel] [PATCH v2 4/6] net: force NetQue opaque to be NetClientState
From: Liu Ping Fan
qemu_net_client_setup() is the only user of qemu_new_net_queue(), which
will pass in NetClientState. By forcing it be a NetClientState, we
can ref/unref NetQueue's owner
Signed-off-by: Liu Ping Fan
---
include/net/queue.h | 2 +-
net/queue.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/net/queue.h b/include/net/queue.h
index fc02b33..ddb6d98 100644
--- a/include/net/queue.h
+++ b/include/net/queue.h
@@ -34,7 +34,7 @@ typedef void (NetPacketSent) (NetClientState *sender, ssize_t
ret);
#define QEMU_NET_PACKET_FLAG_NONE 0
#define QEMU_NET_PACKET_FLAG_RAW (1<<0)
-NetQueue *qemu_new_net_queue(void *opaque);
+NetQueue *qemu_new_net_queue(NetClientState *opaque);
void qemu_del_net_queue(NetQueue *queue);
diff --git a/net/queue.c b/net/queue.c
index 7d6c52e..58222b0 100644
--- a/net/queue.c
+++ b/net/queue.c
@@ -49,7 +49,7 @@ struct NetPacket {
};
struct NetQueue {
-void *opaque;
+NetClientState *opaque;
uint32_t nq_maxlen;
uint32_t nq_count;
@@ -59,7 +59,7 @@ struct NetQueue {
unsigned delivering : 1;
};
-NetQueue *qemu_new_net_queue(void *opaque)
+NetQueue *qemu_new_net_queue(NetClientState *opaque)
{
NetQueue *queue;
--
1.8.1.4
[Qemu-devel] [PATCH v2 6/6] net: hub use lock to protect ports list
From: Liu Ping Fan
Hub ports will run on multi-threads, so use lock to protect them.
Signed-off-by: Liu Ping Fan
---
net/hub.c | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/net/hub.c b/net/hub.c
index 9c6c559..2970f8e 100644
--- a/net/hub.c
+++ b/net/hub.c
@@ -37,6 +37,7 @@ struct NetHub {
int id;
QLIST_ENTRY(NetHub) next;
int num_ports;
+QemuMutex ports_lock;
QLIST_HEAD(, NetHubPort) ports;
};
@@ -47,6 +48,7 @@ static ssize_t net_hub_receive(NetHub *hub, NetHubPort
*source_port,
{
NetHubPort *port;
+qemu_mutex_lock(&hub->ports_lock);
QLIST_FOREACH(port, &hub->ports, next) {
if (port == source_port) {
continue;
@@ -54,6 +56,7 @@ static ssize_t net_hub_receive(NetHub *hub, NetHubPort
*source_port,
qemu_send_packet(&port->nc, buf, len);
}
+qemu_mutex_unlock(&hub->ports_lock);
return len;
}
@@ -63,6 +66,7 @@ static ssize_t net_hub_receive_iov(NetHub *hub, NetHubPort
*source_port,
NetHubPort *port;
ssize_t len = iov_size(iov, iovcnt);
+qemu_mutex_lock(&hub->ports_lock);
QLIST_FOREACH(port, &hub->ports, next) {
if (port == source_port) {
continue;
@@ -70,6 +74,7 @@ static ssize_t net_hub_receive_iov(NetHub *hub, NetHubPort
*source_port,
qemu_sendv_packet(&port->nc, iov, iovcnt);
}
+qemu_mutex_unlock(&hub->ports_lock);
return len;
}
@@ -80,6 +85,7 @@ static NetHub *net_hub_new(int id)
hub = g_malloc(sizeof(*hub));
hub->id = id;
hub->num_ports = 0;
+qemu_mutex_init(&hub->ports_lock);
QLIST_INIT(&hub->ports);
QLIST_INSERT_HEAD(&hubs, hub, next);
@@ -93,16 +99,19 @@ static int net_hub_port_can_receive(NetClientState *nc)
NetHubPort *src_port = DO_UPCAST(NetHubPort, nc, nc);
NetHub *hub = src_port->hub;
+qemu_mutex_lock(&hub->ports_lock);
QLIST_FOREACH(port, &hub->ports, next) {
if (port == src_port) {
continue;
}
if (qemu_can_send_packet(&port->nc)) {
+qemu_mutex_unlock(&hub->ports_lock);
return 1;
}
}
+qemu_mutex_unlock(&hub->ports_lock);
return 0;
}
@@ -155,8 +164,9 @@ static NetHubPort *net_hub_port_new(NetHub *hub, const char
*name)
port = DO_UPCAST(NetHubPort, nc, nc);
port->id = id;
port->hub = hub;
-
+qemu_mutex_lock(&hub->ports_lock);
QLIST_INSERT_HEAD(&hub->ports, port, next);
+qemu_mutex_unlock(&hub->ports_lock);
return port;
}
@@ -197,14 +207,17 @@ NetClientState *net_hub_find_client_by_name(int hub_id,
const char *name)
QLIST_FOREACH(hub, &hubs, next) {
if (hub->id == hub_id) {
+qemu_mutex_lock(&hub->ports_lock);
QLIST_FOREACH(port, &hub->ports, next) {
peer = port->nc.peer;
if (peer && strcmp(peer->name, name) == 0) {
netclient_ref(peer);
+qemu_mutex_unlock(&hub->ports_lock);
return peer;
}
}
+qemu_mutex_unlock(&hub->ports_lock);
}
}
return NULL;
@@ -221,13 +234,16 @@ NetClientState *net_hub_port_find(int hub_id)
QLIST_FOREACH(hub, &hubs, next) {
if (hub->id == hub_id) {
+qemu_mutex_lock(&hub->ports_lock);
QLIST_FOREACH(port, &hub->ports, next) {
nc = port->nc.peer;
if (!nc) {
netclient_ref(&port->nc);
+qemu_mutex_unlock(&hub->ports_lock);
return &(port->nc);
}
}
+qemu_mutex_unlock(&hub->ports_lock);
break;
}
}
@@ -247,12 +263,14 @@ void net_hub_info(Monitor *mon)
QLIST_FOREACH(hub, &hubs, next) {
monitor_printf(mon, "hub %d\n", hub->id);
+qemu_mutex_lock(&hub->ports_lock);
QLIST_FOREACH(port, &hub->ports, next) {
if (port->nc.peer) {
monitor_printf(mon, " \\ ");
print_net_client(mon, port->nc.peer);
}
}
+qemu_mutex_unlock(&hub->ports_lock);
}
}
@@ -309,6 +327,7 @@ void net_hub_check_clients(void)
QLIST_FOREACH(hub, &hubs, next) {
int has_nic = 0, has_host_dev = 0;
+qemu_mutex_lock(&hub->ports_lock);
QLIST_FOREACH(port, &hub->ports, next) {
peer = port->nc.peer;
if (!peer) {
@@ -331,6 +350,7 @@ void net_hub_check_clients(void)
break;
}
}
+qemu_mutex_unlock(&hub->ports_lock);
if (has_host_dev && !has_nic) {
fprintf(stderr, "Warning: vlan %d with no nics\n", hub->id);
}
@@ -346,12 +366,15 @@ bool net_hub_flush(NetClientState *nc)
{
NetHubPort *port;
NetHubPort *source_port = DO_UPCAST(NetHubPort, nc, nc);
+NetHub *hub = source_port->hub;
Re: [Qemu-devel] Patch Round-up for stable 1.5.1, freeze on 2013-06-19
On Wed, Jun 12, 2013 at 11:41 PM, Michael Roth wrote: > Please respond here or CC qemu-sta...@nongnu.org on any patches you > think should be included in the release. The cut-off date is > 2013-06-19 for new patches. commit 293c51a6ee369228633a8428ab689f14c045ff98 Author: Stefan Hajnoczi Date: Wed Jun 5 10:33:14 2013 +0200 blockdev: reset werror/rerror on drive_del
Re: [Qemu-devel] [RFC] sanitize memory on system reset
Hi, Am 13.06.2013 08:09, schrieb Peter Lieven: > I was thinking if it would be a good idea to zeroize all memory > resources on system reset and > madvise dontneed them afterwards. The current way of not zeroing memory has led to discovery of some firmware bugs that we wouldn't have found if QEMU defaulted to zeroing. > This would avoid system reset attacks > in case the attacker > has only access to the console of a vServer but not on the physical host > and it would shrink > RSS size of the vServer siginificantly. Apart from the guest issue Stefan brought up (so far by definition we do a hard reset, so guests cannot assume soft reset semantics, but we should keep our options open), would not zeroing while marking pages as unused be an option? E.g., -reset-memory=DEADBEEF or some other command-line-specifiable pattern, absence would mean current behavior. Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] virsh live migration with non-shared storage fails with error as vm is not running
On 06/12/2013 04:21 PM, chandrashekar shastri wrote: > Hi All, > > I have attached the dedug log of libvirt, please let me with your comments. Spamming 3 separate lists with nearly a megabyte of logs is considered poor netiquette. It causes lots of server time to multiply that out to all the recipients, and not every one is able to cheaply download that much material, especially if they are subscribed to multiple lists. Your post was moderated and dropped before it hit libvirt, but looks like it still got through to qemu-devel and virt-tools. Please be more careful in the future. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [RFC] sanitize memory on system reset
On 13.06.2013 11:22, Andreas Färber wrote: Hi, Am 13.06.2013 08:09, schrieb Peter Lieven: I was thinking if it would be a good idea to zeroize all memory resources on system reset and madvise dontneed them afterwards. The current way of not zeroing memory has led to discovery of some firmware bugs that we wouldn't have found if QEMU defaulted to zeroing. The memory is zero at the start due to the use of mmap. Maybe we need to add an option to add an initialization value anyway because I am unsure if PERTURB works with mmap?! This would avoid system reset attacks in case the attacker has only access to the console of a vServer but not on the physical host and it would shrink RSS size of the vServer siginificantly. Apart from the guest issue Stefan brought up (so far by definition we do a hard reset, so guests cannot assume soft reset semantics, but we should keep our options open), would not zeroing while marking pages as unused be an option? E.g., -reset-memory=DEADBEEF or some other command-line-specifiable pattern, absence would mean current behavior. This would overwrite all contents with 0xdeadbeaf avoiding information leak, but it would unnecessarily keep the memory alocated. So what about an option -mem-sanitize with an optional parameter to write a initialization value. option missing -> no change -mem-sanitize -> zeroize and madv_dontneed -mem-sanitze=deadbeaf -> fill memory with 0xdeadbeaf Where is the right postion to add this hook. qemu_system_reset() ? Peter Regards, Andreas -- Mit freundlichen Grüßen Peter Lieven ... KAMP Netzwerkdienste GmbH Vestische Str. 89-91 | 46117 Oberhausen Tel: +49 (0) 208.89 402-50 | Fax: +49 (0) 208.89 402-40 p...@kamp.de | http://www.kamp.de Geschäftsführer: Heiner Lante | Michael Lante Amtsgericht Duisburg | HRB Nr. 12154 USt-Id-Nr.: DE 120607556 ...
[Qemu-devel] [Bug 668799] Re: qemu-arm segfaults executing msgmerge (gettext)
** Changed in: qemu-linaro Status: Fix Committed => Fix Released ** Changed in: qemu Status: Fix Committed => Fix Released ** Changed in: qemu-linaro Milestone: None => 2013.06 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/668799 Title: qemu-arm segfaults executing msgmerge (gettext) Status in QEMU: Fix Released Status in Linaro QEMU: Fix Released Bug description: upstream qemu.git revision b45e9c05dbacba8e992f0bffeca04c6379c3ad45 Starting program: /usr/bin/qemu-arm msgmerge-static ar.po anjuta.pot [Thread debugging using libthread_db enabled] [New Thread 0x74bc3ff0 (LWP 26108)] [New Thread 0x74b8aff0 (LWP 26109)] [New Thread 0x74b51ff0 (LWP 26110)] [New Thread 0x74b18ff0 (LWP 26111)] [New Thread 0x74adfff0 (LWP 26112)] [New Thread 0x74aa6ff0 (LWP 26113)] [New Thread 0x74a6dff0 (LWP 26114)] [New Thread 0x74a34ff0 (LWP 26115)] [New Thread 0x749fbff0 (LWP 26116)] [New Thread 0x749c2ff0 (LWP 26117)] [New Thread 0x74989ff0 (LWP 26118)] [New Thread 0x74950ff0 (LWP 26119)] [New Thread 0x74917ff0 (LWP 26120)] [New Thread 0x748deff0 (LWP 26121)] [New Thread 0x748a5ff0 (LWP 26122)] [New Thread 0x7486cff0 (LWP 26123)] [New Thread 0x74833ff0 (LWP 26124)] [New Thread 0x747faff0 (LWP 26125)] [New Thread 0x747c1ff0 (LWP 26126)] [New Thread 0x74788ff0 (LWP 26127)] [New Thread 0x7474fff0 (LWP 26128)] [New Thread 0x74716ff0 (LWP 26129)] [New Thread 0x746ddff0 (LWP 26130)] . Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x74aa6ff0 (LWP 26113)] 0x600480d4 in tb_reset_jump_recursive2 (tb=0x74c63540, n=0) at /home/user/git/qemu/exec.c:1333 1333tb1 = tb1->jmp_next[n1]; (gdb) bt #0 0x600480d4 in tb_reset_jump_recursive2 (tb=0x74c63540, n=0) at /home/user/git/qemu/exec.c:1333 #1 0x600481c0 in tb_reset_jump_recursive (tb=0x74c63540) at /home/user/git/qemu/exec.c:1361 #2 0x60048160 in tb_reset_jump_recursive2 (tb=0x74c634d8, n=0) at /home/user/git/qemu/exec.c:1355 #3 0x600481c0 in tb_reset_jump_recursive (tb=0x74c634d8) at /home/user/git/qemu/exec.c:1361 #4 0x60048160 in tb_reset_jump_recursive2 (tb=0x74c63470, n=0) at /home/user/git/qemu/exec.c:1355 #5 0x600481c0 in tb_reset_jump_recursive (tb=0x74c63470) at /home/user/git/qemu/exec.c:1361 #6 0x60048160 in tb_reset_jump_recursive2 (tb=0x74c63408, n=1) at /home/user/git/qemu/exec.c:1355 #7 0x600481d1 in tb_reset_jump_recursive (tb=0x74c63408) at /home/user/git/qemu/exec.c:1362 #8 0x60048160 in tb_reset_jump_recursive2 (tb=0x74c633a0, n=0) at /home/user/git/qemu/exec.c:1355 #9 0x600481c0 in tb_reset_jump_recursive (tb=0x74c633a0) at /home/user/git/qemu/exec.c:1361 #10 0x60048160 in tb_reset_jump_recursive2 (tb=0x74c63338, n=0) at /home/user/git/qemu/exec.c:1355 #11 0x600481c0 in tb_reset_jump_recursive (tb=0x74c63338) at /home/user/git/qemu/exec.c:1361 #12 0x60048160 in tb_reset_jump_recursive2 (tb=0x74c632d0, n=0) at /home/user/git/qemu/exec.c:1355 ---Type to continue, or q to quit--- #13 0x600481c0 in tb_reset_jump_recursive (tb=0x74c632d0) at /home/user/git/qemu/exec.c:1361 #14 0x60048160 in tb_reset_jump_recursive2 (tb=0x74c63268, n=1) at /home/user/git/qemu/exec.c:1355 #15 0x600481d1 in tb_reset_jump_recursive (tb=0x74c63268) at /home/user/git/qemu/exec.c:1362 #16 0x60048160 in tb_reset_jump_recursive2 (tb=0x74c63200, n=0) at /home/user/git/qemu/exec.c:1355 #17 0x600481c0 in tb_reset_jump_recursive (tb=0x74c63200) at /home/user/git/qemu/exec.c:1361 #18 0x600487c5 in cpu_unlink_tb (env=0x62385400) at /home/user/git/qemu/exec.c:1617 #19 0x600488e8 in cpu_exit (env=0x62385400) at /home/user/git/qemu/exec.c:1662 #20 0x6798 in start_exclusive () at /home/user/git/qemu/linux-user/main.c:152 #21 0x6a4b in do_kernel_trap (env=0x62359940) at /home/user/git/qemu/linux-user/main.c:493 #22 0x600023f3 in cpu_loop (env=0x62359940) at /home/user/git/qemu/linux-user/main.c:797 #23 0x600123df in clone_func (arg=0x7ffd76e0) at /home/user/git/qemu/linux-user/syscall.c:3561 #24 0x600b382d in start_thread (arg=) at pthread_create.c:297 #25 0x600f1809 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #26 0x in ?? () (gdb) Its interesting to see this : #0 0x600480d4 in tb_reset_jump_recursive2 (tb=0x74c635
[Qemu-devel] [Bug 1190525] [NEW] fdisk still shows the "/dev/sdb" partitions even after the removal of scsi disk
Public bug reported: RHEL guest shows the partittions even after the removal of scsi disk: fdisk still shows the "/dev/sdb" partitions even after the removal of scsi disk. Guest details: --- Kernel : 2.6.32-358 Host Details : Upstream Kernel, Qemu, Libvirt and virt-manager - kernel version : 3.9.0+ qemu version : QEMU emulator version 1.5.0 libvirt version : 1.0.5 virt-install : 0.600.3 Steps to reproduce the issue: I. Add the SCSI disk through the virt-manager. 2. Create the partition using fdisk (eg: /dev/sbb) 3. Create a filesystem and format using mkfs.ext3 or mkfs.ext4 4. Remove the scsi disk through the virt-manager. 5. Again run the fdisk /dev/sdb, the guests still shows the partition even after the removal of the disk. This issue is not seen with virt-io disk. This issue is also reproducible without even creating the partitions. Expected Result: The output of fdisk /dev/sd* should not show the enties after the removal of scsi disks ** Affects: qemu Importance: Undecided Status: New ** Attachment added: "var log messages" https://bugs.launchpad.net/bugs/1190525/+attachment/3702180/+files/messages -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1190525 Title: fdisk still shows the "/dev/sdb" partitions even after the removal of scsi disk Status in QEMU: New Bug description: RHEL guest shows the partittions even after the removal of scsi disk: fdisk still shows the "/dev/sdb" partitions even after the removal of scsi disk. Guest details: --- Kernel : 2.6.32-358 Host Details : Upstream Kernel, Qemu, Libvirt and virt-manager - kernel version : 3.9.0+ qemu version : QEMU emulator version 1.5.0 libvirt version : 1.0.5 virt-install : 0.600.3 Steps to reproduce the issue: I. Add the SCSI disk through the virt-manager. 2. Create the partition using fdisk (eg: /dev/sbb) 3. Create a filesystem and format using mkfs.ext3 or mkfs.ext4 4. Remove the scsi disk through the virt-manager. 5. Again run the fdisk /dev/sdb, the guests still shows the partition even after the removal of the disk. This issue is not seen with virt-io disk. This issue is also reproducible without even creating the partitions. Expected Result: The output of fdisk /dev/sd* should not show the enties after the removal of scsi disks To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1190525/+subscriptions
[Qemu-devel] [PATCH] Remove hardcoded xen-platform device initialization
The xen-platform device should be initialized by the Xen toolstack by
passing the appropriate -device argument on the command line.
Signed-off-by: Paul Durrant
---
hw/i386/pc_piix.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index d618570..e25012d 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -174,9 +174,6 @@ static void pc_init1(MemoryRegion *system_memory,
pc_register_ferr_irq(gsi[13]);
pc_vga_init(isa_bus, pci_enabled ? pci_bus : NULL);
-if (xen_enabled()) {
-pci_create_simple(pci_bus, -1, "xen-platform");
-}
/* init basic PC hardware */
pc_basic_device_init(isa_bus, gsi, &rtc_state, &floppy, xen_enabled());
--
1.7.10.4
Re: [Qemu-devel] [PATCH v2 1/2] ps2: add support of auto-repeat
On Fri, May 31, 2013 at 08:31:17PM +0800, Amos Kong wrote:
> On Thu, May 30, 2013 at 11:48:46AM -0500, Anthony Liguori wrote:
> > Amos Kong writes:
> >
> > > Guest driver sets repeat rate and delay time by KBD_CMD_SET_RATE,
> > > but ps2 backend doesn't process it and no auto-repeat implementation.
> > > This patch adds support of auto-repeat feature. The repeated events
> > > from host are ignored and re-implements ps2's auto-repeat.
> > >
> > > Guest ps2 driver sets autorepeat to fastest possible in reset,
> > > period: 250ms, delay: 33ms
> > >
> > > Tested by 'sendkey' monitor command.
> > > Tested by Linux & Windows guests with SDL, VNC, SPICE, GTK+
> > >
> > > referenced: http://www.computer-engineering.org/ps2keyboard/
> > >
> > > Signed-off-by: Amos Kong
> > > ---
> > > hw/input/ps2.c | 41 +
> > > 1 file changed, 41 insertions(+)
> > >
> > > diff --git a/hw/input/ps2.c b/hw/input/ps2.c
> > > index 3412079..8adbb4a 100644
> > > --- a/hw/input/ps2.c
> > > +++ b/hw/input/ps2.c
> > > @@ -94,6 +94,10 @@ typedef struct {
> > > int translate;
> > > int scancode_set; /* 1=XT, 2=AT, 3=PS/2 */
> > > int ledstate;
> > > +int repeat_period; /* typematic period, ms */
> > > +int repeat_delay; /* typematic delay, ms */
> > > +int repeat_key; /* keycode to repeat */
> > > +QEMUTimer *repeat_timer;
> >
> > This state needs to be migrated, no? I suspect it can/should be done
> > via a subsection too.
>
> It sounds only reasonable for 'sendkey' command. We want to repeat one
> key for 100 times, the key should be continaully repeated in the dest
> vm until it reaches to 100 times.
>
> For implement this, we should also migrate key_timer in ui/input.c,
> then it will send a release event to ps2 queue when the key_timer
> is expired. The bottom patch migrates repeat_timer & repeat_key,
> where should we save key_timer for migration?
>
>
>
> For the VNC/SPICE/SDL/GTK+ windows, qemu gets repeated press events
> from host. After vm migrates to dest host, if we don't touch the
> keyboard, there will be no repeat / release event comes from host,
>
> 1) continue to repeat? but qemu no long gets press event from host
> 2) stop to repeat? but qemu has not got the release event, auto-repeat
> should continue in real keyboard in this condition.
>
> I prefect 2), because we need to emulate a release event in the
> prepare stage of migrate.
>
> For implement 2), we should not load/restart the repeat_timer if
> the migrated key_timer is already expired.
>
> ---
>
> Or just migrate the repeat_rate/repeat_period. We don't have
> real request of auto-repeat in libvirt.
>
> This might be the best solution as Paolo said ;)
> http://lists.nongnu.org/archive/html/qemu-devel/2013-05/msg02207.html
ping Anthony, Paolo
I don't think we need to migrate the repeat timer/state.
only need to migrate related setup (rate/delay) as in last patch.
If you agree with this, I can merge those to patches together for
avoiding to break the bisect.
Amos.
> diff --git a/hw/input/ps2.c b/hw/input/ps2.c
> index cdb18e6..fdb9912 100644
> --- a/hw/input/ps2.c
> +++ b/hw/input/ps2.c
> @@ -615,7 +615,17 @@ static bool ps2_keyboard_repeatstate_needed(void
> *opaque)
> {
> PS2KbdState *s = opaque;
>
> -return s->repeat_period || s->repeat_delay;
> +return s->repeat_period || s->repeat_delay || s->repeat_key ||
> s->repeat_timer;
> +}
> +
> +static int ps2_kbd_repeatstate_load(QEMUFile *f, void *opaque, int
> version_id)
> +{
> +PS2KbdState *s = opaque;
> +qemu_get_timer(f, s->repeat_timer);
> +qemu_mod_timer(s->repeat_timer, qemu_get_clock_ns(vm_clock) +
> + muldiv64(get_ticks_per_sec(), s->repeat_period,
> 1000));
> +
> +return 0;
> }
>
> static bool ps2_keyboard_ledstate_needed(void *opaque)
> @@ -638,9 +648,12 @@ static const VMStateDescription
> vmstate_ps2_keyboard_repeatstate = {
> .version_id = 3,
> .minimum_version_id = 2,
> .minimum_version_id_old = 2,
> +.load_state_old = ps2_kbd_repeatstate_load,
> .fields = (VMStateField[]) {
> VMSTATE_INT32(repeat_period, PS2KbdState),
> VMSTATE_INT32(repeat_delay, PS2KbdState),
> +VMSTATE_INT32(repeat_key, PS2KbdState),
> +VMSTATE_TIMER(repeat_timer, PS2KbdState),
> VMSTATE_END_OF_LIST()
> }
> };
>
Re: [Qemu-devel] [PATCH] console: extend screendump monitor cmd
On Wed, Jun 12, 2013 at 09:23:37AM -0400, Luiz Capitulino wrote:
> On Wed, 12 Jun 2013 15:21:20 +0200
> Gerd Hoffmann wrote:
>
> > Hi,
> >
> > >> -{ 'command': 'screendump', 'data': {'filename': 'str'} }
> > >> +{ 'command': 'screendump', 'data': {'filename': 'str',
> > >> +'*device' : 'str'} }
> > >
> > > We can't add new optional parameters to QMP commands because it's
> > > currently impossible for mngt apps to discover them.
> > >
> > > We have two options: 1. add this as a new command or 2. wait for
> > > full schema introspection (which we might get for 1.6).
> >
> > "might get" sounds like it isn't a save bet, so I guess I better should
> > go for option (1) ...
>
> Amos, do you think we'll get it for 1.6?
Yes, we can.
2013-07-29 Hard feature freeze
2013-08-01 Tag v1.6.0-rc1
--
Amos.
Re: [Qemu-devel] [PATCH v2 1/2] ps2: add support of auto-repeat
Am 31.05.2013 14:31, schrieb Amos Kong:
> diff --git a/hw/input/ps2.c b/hw/input/ps2.c
> index cdb18e6..fdb9912 100644
> --- a/hw/input/ps2.c
> +++ b/hw/input/ps2.c
> @@ -615,7 +615,17 @@ static bool ps2_keyboard_repeatstate_needed(void
> *opaque)
> {
> PS2KbdState *s = opaque;
>
> -return s->repeat_period || s->repeat_delay;
> +return s->repeat_period || s->repeat_delay || s->repeat_key ||
> s->repeat_timer;
> +}
> +
> +static int ps2_kbd_repeatstate_load(QEMUFile *f, void *opaque, int
> version_id)
> +{
> +PS2KbdState *s = opaque;
> +qemu_get_timer(f, s->repeat_timer);
> +qemu_mod_timer(s->repeat_timer, qemu_get_clock_ns(vm_clock) +
> + muldiv64(get_ticks_per_sec(), s->repeat_period,
> 1000));
> +
> +return 0;
> }
>
> static bool ps2_keyboard_ledstate_needed(void *opaque)
> @@ -638,9 +648,12 @@ static const VMStateDescription
> vmstate_ps2_keyboard_repeatstate = {
> .version_id = 3,
> .minimum_version_id = 2,
> .minimum_version_id_old = 2,
> +.load_state_old = ps2_kbd_repeatstate_load,
> .fields = (VMStateField[]) {
> VMSTATE_INT32(repeat_period, PS2KbdState),
> VMSTATE_INT32(repeat_delay, PS2KbdState),
> +VMSTATE_INT32(repeat_key, PS2KbdState),
> +VMSTATE_TIMER(repeat_timer, PS2KbdState),
You can't just add fields here, they'd need to be specific to a new
version 4. Requested was to make it a subsection instead.
Andreas
> VMSTATE_END_OF_LIST()
> }
> };
>
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[Qemu-devel] fdisk still shows the "/dev/sdb" partitions even after the removal of scsi disk
Hi, I have filed a bug "fdisk still shows the "/dev/sdb" partitions even after the removal of scsi disk" for the upstream kernel. Bug link: https://bugs.launchpad.net/qemu/+bug/1190525 RHEL guest shows the partittions even after the removal of scsi disk: fdisk still shows the "/dev/sdb" partitions even after the removal of scsi disk. Guest details: --- Kernel : 2.6.32-358 Host Details : Upstream Kernel, Qemu, Libvirt and virt-manager - kernel version : 3.9.0+ qemu version : QEMU emulator version 1.5.0 libvirt version : 1.0.5 virt-install : 0.600.3 Steps to reproduce the issue: I. Add the SCSI disk through the virt-manager. 2. Create the partition using fdisk (eg: /dev/sbb) 3. Create a filesystem and format using mkfs.ext3 or mkfs.ext4 4. Remove the scsi disk through the virt-manager. 5. Again run the fdisk /dev/sdb, the guests still shows the partition even after the removal of the disk. This issue is not seen with virt-io disk. This issue is also reproducible without even creating the partitions. Expected Result: The output of fdisk /dev/sd* should not show the enties after the removal of scsi disks Thanks, Chandrashekar
Re: [Qemu-devel] [PATCH] raw-posix: Fix /dev/cdrom magic on OS X
Am 12.06.2013 16:22, schrieb Kevin Wolf: > The raw-posix driver has code to provide a /dev/cdrom on OS X even > though it doesn't really exist. However, since commit c66a6157 the real > filename is dismissed after finding it, so opening /dev/cdrom fails. > Put the filename back into the options QDict to make this work again. > > Cc: qemu-sta...@nongnu.org > Signed-off-by: Kevin Wolf > --- > block/raw-posix.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/block/raw-posix.c b/block/raw-posix.c > index c0ccf27..90ce9f8 100644 > --- a/block/raw-posix.c > +++ b/block/raw-posix.c > @@ -1350,6 +1350,7 @@ static int hdev_open(BlockDriverState *bs, QDict > *options, int flags) > qemu_close(fd); > } > filename = bsdPath; > +qdict_put(options, "filename", qstring_from_str(filename)); > } > > if ( mediaIterator ) On Mac OS X v10.5.8 ppc64 I get: qemu-system-x86_64: -cdrom /dev/cdrom: could not open disk image /dev/cdrom: No such file or directory On ppc I get a crash even without options, seems unrelated though. Andreas
[Qemu-devel] [PATCH] fix some printf errors when debug is enabled
Signed-off-by: Hu Tao
---
cputlb.c| 4 ++--
hw/acpi/piix4.c | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/cputlb.c b/cputlb.c
index 8c8..1230e9e 100644
--- a/cputlb.c
+++ b/cputlb.c
@@ -262,8 +262,8 @@ void tlb_set_page(CPUArchState *env, target_ulong vaddr,
#if defined(DEBUG_TLB)
printf("tlb_set_page: vaddr=" TARGET_FMT_lx " paddr=0x" TARGET_FMT_plx
- " prot=%x idx=%d pd=0x%08lx\n",
- vaddr, paddr, prot, mmu_idx, pd);
+ " prot=%x idx=%d\n",
+ vaddr, paddr, prot, mmu_idx);
#endif
address = vaddr;
diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
index e6525ac..eafa76f 100644
--- a/hw/acpi/piix4.c
+++ b/hw/acpi/piix4.c
@@ -518,7 +518,7 @@ static uint64_t gpe_readb(void *opaque, hwaddr addr,
unsigned width)
PIIX4PMState *s = opaque;
uint32_t val = acpi_gpe_ioport_readb(&s->ar, addr);
-PIIX4_DPRINTF("gpe read %x == %x\n", addr, val);
+PIIX4_DPRINTF("gpe read %lx == %x\n", addr, val);
return val;
}
@@ -530,7 +530,7 @@ static void gpe_writeb(void *opaque, hwaddr addr, uint64_t
val,
acpi_gpe_ioport_writeb(&s->ar, addr, val);
pm_update_sci(s);
-PIIX4_DPRINTF("gpe write %x <== %d\n", addr, val);
+PIIX4_DPRINTF("gpe write %lx <== %lu\n", addr, val);
}
static const MemoryRegionOps piix4_gpe_ops = {
@@ -579,7 +579,7 @@ static void pci_write(void *opaque, hwaddr addr, uint64_t
data,
switch (addr) {
case PCI_EJ_BASE - PCI_HOTPLUG_ADDR:
acpi_piix_eject_slot(opaque, (uint32_t)data);
-PIIX4_DPRINTF("pciej write %" HWADDR_PRIx " <== % " PRIu64 "\n",
+PIIX4_DPRINTF("pciej write %" HWADDR_PRIx " <== %" PRIu64 "\n",
addr, data);
break;
default:
--
1.8.2.3
[Qemu-devel] [PATCH] remove call to type_initialize in object_new_with_type
Since it's called in object_initialize_with_type later.
Signed-off-by: Hu Tao
---
qom/object.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/qom/object.c b/qom/object.c
index 803b94b..38dc45e 100644
--- a/qom/object.c
+++ b/qom/object.c
@@ -406,9 +406,6 @@ Object *object_new_with_type(Type type)
{
Object *obj;
-g_assert(type != NULL);
-type_initialize(type);
-
obj = g_malloc(type->instance_size);
object_initialize_with_type(obj, type);
obj->free = g_free;
--
1.8.2.3
[Qemu-devel] [PATCH] fix typo: apci -> acpi
Signed-off-by: Hu Tao
---
hw/acpi/ich9.c | 4 ++--
hw/acpi/piix4.c | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c
index 4a17f32..100b01f 100644
--- a/hw/acpi/ich9.c
+++ b/hw/acpi/ich9.c
@@ -215,11 +215,11 @@ void ich9_pm_init(PCIDevice *lpc_pci, ICH9LPCPMRegs *pm,
acpi_pm1_cnt_init(&pm->acpi_regs, &pm->io, 2);
acpi_gpe_init(&pm->acpi_regs, ICH9_PMIO_GPE0_LEN);
-memory_region_init_io(&pm->io_gpe, &ich9_gpe_ops, pm, "apci-gpe0",
+memory_region_init_io(&pm->io_gpe, &ich9_gpe_ops, pm, "acpi-gpe0",
ICH9_PMIO_GPE0_LEN);
memory_region_add_subregion(&pm->io, ICH9_PMIO_GPE0_STS, &pm->io_gpe);
-memory_region_init_io(&pm->io_smi, &ich9_smi_ops, pm, "apci-smi",
+memory_region_init_io(&pm->io_smi, &ich9_smi_ops, pm, "acpi-smi",
8);
memory_region_add_subregion(&pm->io, ICH9_PMIO_SMI_EN, &pm->io_smi);
diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
index eafa76f..ad4a364 100644
--- a/hw/acpi/piix4.c
+++ b/hw/acpi/piix4.c
@@ -670,18 +670,18 @@ static int piix4_device_hotplug(DeviceState *qdev,
PCIDevice *dev,
static void piix4_acpi_system_hot_add_init(MemoryRegion *parent,
PCIBus *bus, PIIX4PMState *s)
{
-memory_region_init_io(&s->io_gpe, &piix4_gpe_ops, s, "apci-gpe0",
+memory_region_init_io(&s->io_gpe, &piix4_gpe_ops, s, "acpi-gpe0",
GPE_LEN);
memory_region_add_subregion(parent, GPE_BASE, &s->io_gpe);
-memory_region_init_io(&s->io_pci, &piix4_pci_ops, s, "apci-pci-hotplug",
+memory_region_init_io(&s->io_pci, &piix4_pci_ops, s, "acpi-pci-hotplug",
PCI_HOTPLUG_SIZE);
memory_region_add_subregion(parent, PCI_HOTPLUG_ADDR,
&s->io_pci);
pci_bus_hotplug(bus, piix4_device_hotplug, &s->dev.qdev);
qemu_for_each_cpu(piix4_init_cpu_status, &s->gpe_cpu);
-memory_region_init_io(&s->io_cpu, &cpu_hotplug_ops, s, "apci-cpu-hotplug",
+memory_region_init_io(&s->io_cpu, &cpu_hotplug_ops, s, "acpi-cpu-hotplug",
PIIX4_PROC_LEN);
memory_region_add_subregion(parent, PIIX4_PROC_BASE, &s->io_cpu);
s->cpu_added_notifier.notify = piix4_cpu_added_req;
--
1.8.2.3
Re: [Qemu-devel] [RFC] sanitize memory on system reset
Peter Lieven writes: > On 13.06.2013 10:40, Stefan Hajnoczi wrote: >> On Thu, Jun 13, 2013 at 08:09:09AM +0200, Peter Lieven wrote: >>> I was thinking if it would be a good idea to zeroize all memory >>> resources on system reset and >>> madvise dontneed them afterwards. This would avoid system reset >>> attacks in case the attacker >>> has only access to the console of a vServer but not on the physical >>> host and it would shrink >>> RSS size of the vServer siginificantly. >> I wonder if you'll hit weird OS installers or PXE clients that rely on >> stashing stuff in memory across reset. > One point: > Wouldn't a memory test which some systems do at startup break these as well? Systems that distinguish between warm and cold boot (such as PCs) generally run POST only on cold boot. I'm not saying triggering warm reboot and expecting memory contents to survive is a good idea, but it has been done.
Re: [Qemu-devel] [PATCH v2] kvm/openpic: in-kernel mpic support
Am 12.06.2013 22:32, schrieb Scott Wood:
> Enables support for the in-kernel MPIC that thas been merged into the
> KVM next branch. This includes irqfd/KVM_IRQ_LINE support from Alex
> Graf (along with some other improvements).
>
> Note from Alex regarding kvm_irqchip_create():
>
> On x86, one would call kvm_irqchip_create() to initialize an
> in-kernel interrupt controller. That function then goes ahead and
> initializes global capability variables as well as the default irq
> routing table.
>
> On ppc, we can't call kvm_irqchip_create() because we can have
> different types of interrupt controllers. So we want to do all the
> things that function would do for us in the in-kernel device init
> handler.
>
> Signed-off-by: Scott Wood
> ---
> v2: fix "llx" -> PRI_x64, and remove some broken leftover code
> involving reg_base.
> ---
> default-configs/ppc-softmmu.mak |1 +
> default-configs/ppc64-softmmu.mak |1 +
> hw/intc/Makefile.objs |1 +
> hw/intc/openpic_kvm.c | 250
> +
> hw/ppc/e500.c | 79 +++-
> include/hw/ppc/openpic.h |2 +-
> 6 files changed, 328 insertions(+), 6 deletions(-)
> create mode 100644 hw/intc/openpic_kvm.c
>
> diff --git a/default-configs/ppc-softmmu.mak b/default-configs/ppc-softmmu.mak
> index cc3587f..63255dc 100644
> --- a/default-configs/ppc-softmmu.mak
> +++ b/default-configs/ppc-softmmu.mak
> @@ -43,5 +43,6 @@ CONFIG_XILINX=y
> CONFIG_XILINX_ETHLITE=y
> CONFIG_OPENPIC=y
> CONFIG_E500=$(CONFIG_FDT)
> +CONFIG_OPENPIC_KVM=$(and $(CONFIG_E500),$(CONFIG_KVM))
> # For PReP
> CONFIG_MC146818RTC=y
> diff --git a/default-configs/ppc64-softmmu.mak
> b/default-configs/ppc64-softmmu.mak
> index 884ea8a..e3c0c68 100644
> --- a/default-configs/ppc64-softmmu.mak
> +++ b/default-configs/ppc64-softmmu.mak
> @@ -44,6 +44,7 @@ CONFIG_XILINX_ETHLITE=y
> CONFIG_OPENPIC=y
> CONFIG_PSERIES=$(CONFIG_FDT)
> CONFIG_E500=$(CONFIG_FDT)
> +CONFIG_OPENPIC_KVM=$(and $(CONFIG_E500),$(CONFIG_KVM))
> # For pSeries
> CONFIG_PCI_HOTPLUG=y
> # For PReP
> diff --git a/hw/intc/Makefile.objs b/hw/intc/Makefile.objs
> index 718d97a..837ef19 100644
> --- a/hw/intc/Makefile.objs
> +++ b/hw/intc/Makefile.objs
> @@ -20,4 +20,5 @@ obj-$(CONFIG_GRLIB) += grlib_irqmp.o
> obj-$(CONFIG_IOAPIC) += ioapic.o
> obj-$(CONFIG_OMAP) += omap_intc.o
> obj-$(CONFIG_OPENPIC) += openpic.o
> +obj-$(CONFIG_OPENPIC_KVM) += openpic_kvm.o
> obj-$(CONFIG_SH4) += sh_intc.o
> diff --git a/hw/intc/openpic_kvm.c b/hw/intc/openpic_kvm.c
> new file mode 100644
> index 000..809b34b
> --- /dev/null
> +++ b/hw/intc/openpic_kvm.c
> @@ -0,0 +1,250 @@
> +/*
> + * KVM in-kernel OpenPIC
> + *
> + * Copyright 2013 Freescale Semiconductor, Inc.
> + *
> + * 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
> +#include "exec/address-spaces.h"
> +#include "hw/hw.h"
> +#include "hw/ppc/openpic.h"
> +#include "hw/pci/msi.h"
> +#include "hw/sysbus.h"
> +#include "sysemu/kvm.h"
> +#include "qemu/log.h"
> +
> +typedef struct KVMOpenPICState {
> +SysBusDevice busdev;
SysBusDevice parent_obj; please!
http://wiki.qemu.org/QOMConventions
> +MemoryRegion mem;
> +MemoryListener mem_listener;
> +uint32_t fd;
> +uint32_t model;
> +} KVMOpenPICState;
> +
> +static void kvm_openpic_set_irq(void *opaque, int n_IRQ, int level)
> +{
> +kvm_set_irq(kvm_state, n_IRQ, level);
> +}
> +
> +static void kvm_openpic_reset(DeviceState *d)
> +{
> +qemu_log_mask(LOG_UNIMP, "%s: unimplemented\n", __func__);
> +}
> +
> +static void kvm_openpic_write(void *opaque, hwaddr addr, uint64_t val,
> + unsigned size)
> +{
> +KVMOpenPICState *opp = opaque;
> +struct kvm_device_attr attr;
> +uint32_t val32 = val;
> +int ret;
> +
> +attr.group = KVM_DEV_MPIC_GRP_REGISTER;
> +att
Re: [Qemu-devel] [PATCH] fix typo: apci -> acpi
Am 13.06.2013 12:51, schrieb Hu Tao: > Signed-off-by: Hu Tao > --- > hw/acpi/ich9.c | 4 ++-- > hw/acpi/piix4.c | 6 +++--- > 2 files changed, 5 insertions(+), 5 deletions(-) Reviewed-by: Andreas Färber Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH] fix some printf errors when debug is enabled
Am 13.06.2013 12:51, schrieb Hu Tao:
> Signed-off-by: Hu Tao
> ---
> cputlb.c| 4 ++--
> hw/acpi/piix4.c | 6 +++---
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/cputlb.c b/cputlb.c
> index 8c8..1230e9e 100644
> --- a/cputlb.c
> +++ b/cputlb.c
> @@ -262,8 +262,8 @@ void tlb_set_page(CPUArchState *env, target_ulong vaddr,
>
> #if defined(DEBUG_TLB)
> printf("tlb_set_page: vaddr=" TARGET_FMT_lx " paddr=0x" TARGET_FMT_plx
> - " prot=%x idx=%d pd=0x%08lx\n",
> - vaddr, paddr, prot, mmu_idx, pd);
> + " prot=%x idx=%d\n",
> + vaddr, paddr, prot, mmu_idx);
> #endif
>
> address = vaddr;
> diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
> index e6525ac..eafa76f 100644
> --- a/hw/acpi/piix4.c
> +++ b/hw/acpi/piix4.c
> @@ -518,7 +518,7 @@ static uint64_t gpe_readb(void *opaque, hwaddr addr,
> unsigned width)
> PIIX4PMState *s = opaque;
> uint32_t val = acpi_gpe_ioport_readb(&s->ar, addr);
>
> -PIIX4_DPRINTF("gpe read %x == %x\n", addr, val);
> +PIIX4_DPRINTF("gpe read %lx == %x\n", addr, val);
You need HWADDR_PRIx as seen below, because it might be %llx on some
platforms. While touching it, changing %x to PRIx32 would be even better.
> return val;
> }
>
> @@ -530,7 +530,7 @@ static void gpe_writeb(void *opaque, hwaddr addr,
> uint64_t val,
> acpi_gpe_ioport_writeb(&s->ar, addr, val);
> pm_update_sci(s);
>
> -PIIX4_DPRINTF("gpe write %x <== %d\n", addr, val);
> +PIIX4_DPRINTF("gpe write %lx <== %lu\n", addr, val);
HWADDR_PRIx, PRIx64
Regards,
Andreas
> }
>
> static const MemoryRegionOps piix4_gpe_ops = {
> @@ -579,7 +579,7 @@ static void pci_write(void *opaque, hwaddr addr, uint64_t
> data,
> switch (addr) {
> case PCI_EJ_BASE - PCI_HOTPLUG_ADDR:
> acpi_piix_eject_slot(opaque, (uint32_t)data);
> -PIIX4_DPRINTF("pciej write %" HWADDR_PRIx " <== % " PRIu64 "\n",
> +PIIX4_DPRINTF("pciej write %" HWADDR_PRIx " <== %" PRIu64 "\n",
>addr, data);
> break;
> default:
>
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH] fix some printf errors when debug is enabled
Am 13.06.2013 13:10, schrieb Andreas Färber:
> Am 13.06.2013 12:51, schrieb Hu Tao:
>> Signed-off-by: Hu Tao
>> ---
>> cputlb.c| 4 ++--
>> hw/acpi/piix4.c | 6 +++---
>> 2 files changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/cputlb.c b/cputlb.c
>> index 8c8..1230e9e 100644
>> --- a/cputlb.c
>> +++ b/cputlb.c
>> @@ -262,8 +262,8 @@ void tlb_set_page(CPUArchState *env, target_ulong vaddr,
>>
>> #if defined(DEBUG_TLB)
>> printf("tlb_set_page: vaddr=" TARGET_FMT_lx " paddr=0x" TARGET_FMT_plx
>> - " prot=%x idx=%d pd=0x%08lx\n",
>> - vaddr, paddr, prot, mmu_idx, pd);
>> + " prot=%x idx=%d\n",
>> + vaddr, paddr, prot, mmu_idx);
>> #endif
>>
>> address = vaddr;
>> diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
>> index e6525ac..eafa76f 100644
>> --- a/hw/acpi/piix4.c
>> +++ b/hw/acpi/piix4.c
>> @@ -518,7 +518,7 @@ static uint64_t gpe_readb(void *opaque, hwaddr addr,
>> unsigned width)
>> PIIX4PMState *s = opaque;
>> uint32_t val = acpi_gpe_ioport_readb(&s->ar, addr);
>>
>> -PIIX4_DPRINTF("gpe read %x == %x\n", addr, val);
>> +PIIX4_DPRINTF("gpe read %lx == %x\n", addr, val);
>
> You need HWADDR_PRIx as seen below, because it might be %llx on some
> platforms. While touching it, changing %x to PRIx32 would be even better.
>
>> return val;
>> }
>>
>> @@ -530,7 +530,7 @@ static void gpe_writeb(void *opaque, hwaddr addr,
>> uint64_t val,
>> acpi_gpe_ioport_writeb(&s->ar, addr, val);
>> pm_update_sci(s);
>>
>> -PIIX4_DPRINTF("gpe write %x <== %d\n", addr, val);
>> +PIIX4_DPRINTF("gpe write %lx <== %lu\n", addr, val);
>
> HWADDR_PRIx, PRIx64
err... PRIu64 obviously.
>
> Regards,
> Andreas
>
>> }
>>
>> static const MemoryRegionOps piix4_gpe_ops = {
>> @@ -579,7 +579,7 @@ static void pci_write(void *opaque, hwaddr addr,
>> uint64_t data,
>> switch (addr) {
>> case PCI_EJ_BASE - PCI_HOTPLUG_ADDR:
>> acpi_piix_eject_slot(opaque, (uint32_t)data);
>> -PIIX4_DPRINTF("pciej write %" HWADDR_PRIx " <== % " PRIu64 "\n",
>> +PIIX4_DPRINTF("pciej write %" HWADDR_PRIx " <== %" PRIu64 "\n",
>>addr, data);
>> break;
>> default:
>>
>
>
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[Qemu-devel] [PATCH] virtio-ccw: reset bugfix
Hi, here's another virtio-ccw bugfix which makes rebooting work better here. Christian Borntraeger (1): s390/virtio-ccw: Fix virtio reset hw/s390x/virtio-ccw.c |2 ++ 1 file changed, 2 insertions(+) -- 1.7.9.5
[Qemu-devel] [PATCH] s390/virtio-ccw: Fix virtio reset
From: Christian Borntraeger On virtio reset we must reset the indicator to avoid stale interrupts, e.g. after a reset. Signed-off-by: Christian Borntraeger Cc: qemu-sta...@nongnu.org Signed-off-by: Cornelia Huck --- hw/s390x/virtio-ccw.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c index 44f5772..4a45dc5 100644 --- a/hw/s390x/virtio-ccw.c +++ b/hw/s390x/virtio-ccw.c @@ -803,6 +803,8 @@ static void virtio_ccw_reset(DeviceState *d) virtio_reset(dev->vdev); css_reset_sch(dev->sch); +dev->indicators = 0; +dev->indicators2 = 0; } / Virtio-ccw Bus Device Descriptions ***/ -- 1.7.9.5
[Qemu-devel] [PATCH 1/5] Revert "block: Disable driver-specific options for 1.5"
This reverts commit 8ec7d390b0d50b5e5b4b1d8dba7ba40d64a70875.
Signed-off-by: Kevin Wolf
---
blockdev.c | 118 ++-
tests/qemu-iotests/group | 2 +-
2 files changed, 5 insertions(+), 115 deletions(-)
diff --git a/blockdev.c b/blockdev.c
index 9937311..4cb592f 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -1734,120 +1734,10 @@ QemuOptsList qemu_drive_opts = {
.name = "drive",
.head = QTAILQ_HEAD_INITIALIZER(qemu_drive_opts.head),
.desc = {
-{
-.name = "bus",
-.type = QEMU_OPT_NUMBER,
-.help = "bus number",
-},{
-.name = "unit",
-.type = QEMU_OPT_NUMBER,
-.help = "unit number (i.e. lun for scsi)",
-},{
-.name = "if",
-.type = QEMU_OPT_STRING,
-.help = "interface (ide, scsi, sd, mtd, floppy, pflash, virtio)",
-},{
-.name = "index",
-.type = QEMU_OPT_NUMBER,
-.help = "index number",
-},{
-.name = "cyls",
-.type = QEMU_OPT_NUMBER,
-.help = "number of cylinders (ide disk geometry)",
-},{
-.name = "heads",
-.type = QEMU_OPT_NUMBER,
-.help = "number of heads (ide disk geometry)",
-},{
-.name = "secs",
-.type = QEMU_OPT_NUMBER,
-.help = "number of sectors (ide disk geometry)",
-},{
-.name = "trans",
-.type = QEMU_OPT_STRING,
-.help = "chs translation (auto, lba. none)",
-},{
-.name = "media",
-.type = QEMU_OPT_STRING,
-.help = "media type (disk, cdrom)",
-},{
-.name = "snapshot",
-.type = QEMU_OPT_BOOL,
-.help = "enable/disable snapshot mode",
-},{
-.name = "file",
-.type = QEMU_OPT_STRING,
-.help = "disk image",
-},{
-.name = "discard",
-.type = QEMU_OPT_STRING,
-.help = "discard operation (ignore/off, unmap/on)",
-},{
-.name = "cache",
-.type = QEMU_OPT_STRING,
-.help = "host cache usage (none, writeback, writethrough, "
-"directsync, unsafe)",
-},{
-.name = "aio",
-.type = QEMU_OPT_STRING,
-.help = "host AIO implementation (threads, native)",
-},{
-.name = "format",
-.type = QEMU_OPT_STRING,
-.help = "disk format (raw, qcow2, ...)",
-},{
-.name = "serial",
-.type = QEMU_OPT_STRING,
-.help = "disk serial number",
-},{
-.name = "rerror",
-.type = QEMU_OPT_STRING,
-.help = "read error action",
-},{
-.name = "werror",
-.type = QEMU_OPT_STRING,
-.help = "write error action",
-},{
-.name = "addr",
-.type = QEMU_OPT_STRING,
-.help = "pci address (virtio only)",
-},{
-.name = "readonly",
-.type = QEMU_OPT_BOOL,
-.help = "open drive file as read-only",
-},{
-.name = "iops",
-.type = QEMU_OPT_NUMBER,
-.help = "limit total I/O operations per second",
-},{
-.name = "iops_rd",
-.type = QEMU_OPT_NUMBER,
-.help = "limit read operations per second",
-},{
-.name = "iops_wr",
-.type = QEMU_OPT_NUMBER,
-.help = "limit write operations per second",
-},{
-.name = "bps",
-.type = QEMU_OPT_NUMBER,
-.help = "limit total bytes per second",
-},{
-.name = "bps_rd",
-.type = QEMU_OPT_NUMBER,
-.help = "limit read bytes per second",
-},{
-.name = "bps_wr",
-.type = QEMU_OPT_NUMBER,
-.help = "limit write bytes per second",
-},{
-.name = "copy-on-read",
-.type = QEMU_OPT_BOOL,
-.help = "copy read data from backing file into image file",
-},{
-.name = "boot",
-.type = QEMU_OPT_BOOL,
-.help = "(deprecated, ignored)",
-},
+/*
+ * no elements => accept any params
+ * validation will happen later
+ */
{ /* end of list */ }
},
};
diff --git a/tests/qemu-iotests/group b/tests/qemu-iotests/group
index 387b050..f487a8f 100644
--- a/tests/qemu-iotests/group
+++ b/tests/qemu-iotests/group
@@ -57,7 +57,7 @@
048 img auto quick
049 rw auto
050 rw auto backing quick
-#051 rw auto
+051 rw auto
052 rw auto backing
053 rw auto
054 rw auto
--
1.8.1.4
[Qemu-devel] [PATCH 0/5] qcow2: Discard freed clusters
This series adds options to make qcow2 discard freed clusters, in several categories. By default, only freed clusters related to snapshots (i.e. mainly snapshot deletion) are discarded. Kevin Wolf (5): Revert "block: Disable driver-specific options for 1.5" qcow2: Add refcount update reason to all callers qcow2: Options to enable discard for freed clusters qcow2: Batch discards block: Always enable discard on the protocol level block.c | 2 +- block/qcow2-cluster.c| 38 + block/qcow2-refcount.c | 139 --- block/qcow2-snapshot.c | 6 +- block/qcow2.c| 30 +- block/qcow2.h| 32 ++- blockdev.c | 118 ++-- tests/qemu-iotests/group | 2 +- 8 files changed, 214 insertions(+), 153 deletions(-) -- 1.8.1.4
[Qemu-devel] [PATCH 3/5] qcow2: Options to enable discard for freed clusters
Deleted snapshots are discarded in the image file by default, discard
requests take their default from the -drive discard=... option and other
places that free clusters must always be enabled explicitly.
Signed-off-by: Kevin Wolf
---
block/qcow2-refcount.c | 5 +
block/qcow2.c | 26 ++
block/qcow2.h | 5 +
3 files changed, 36 insertions(+)
diff --git a/block/qcow2-refcount.c b/block/qcow2-refcount.c
index 6d35e49..7488988 100644
--- a/block/qcow2-refcount.c
+++ b/block/qcow2-refcount.c
@@ -488,6 +488,11 @@ static int QEMU_WARN_UNUSED_RESULT
update_refcount(BlockDriverState *bs,
s->free_cluster_index = cluster_index;
}
refcount_block[block_index] = cpu_to_be16(refcount);
+if (refcount == 0 && s->discard_passthrough[type]) {
+/* Try discarding, ignore errors */
+/* FIXME Doing this cluster by cluster will be painfully slow */
+bdrv_discard(bs->file, cluster_offset, 1);
+}
}
ret = 0;
diff --git a/block/qcow2.c b/block/qcow2.c
index e28ea47..62e6753 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -295,6 +295,22 @@ static QemuOptsList qcow2_runtime_opts = {
.type = QEMU_OPT_BOOL,
.help = "Postpone refcount updates",
},
+{
+.name = QCOW2_OPT_DISCARD_REQUEST,
+.type = QEMU_OPT_BOOL,
+.help = "Pass guest discard requests to the layer below",
+},
+{
+.name = QCOW2_OPT_DISCARD_SNAPSHOT,
+.type = QEMU_OPT_BOOL,
+.help = "Generate discard requests when snapshot related space "
+"is freed",
+},
+{
+.name = QCOW2_OPT_DISCARD_OTHER,
+.type = QEMU_OPT_BOOL,
+.help = "Generate discard requests when other clusters are freed",
+},
{ /* end of list */ }
},
};
@@ -532,6 +548,16 @@ static int qcow2_open(BlockDriverState *bs, QDict
*options, int flags)
s->use_lazy_refcounts = qemu_opt_get_bool(opts, QCOW2_OPT_LAZY_REFCOUNTS,
(s->compatible_features & QCOW2_COMPAT_LAZY_REFCOUNTS));
+s->discard_passthrough[QCOW2_DISCARD_NEVER] = false,
+s->discard_passthrough[QCOW2_DISCARD_ALWAYS] = true,
+s->discard_passthrough[QCOW2_DISCARD_REQUEST] =
+qemu_opt_get_bool(opts, QCOW2_OPT_DISCARD_REQUEST,
+ flags & BDRV_O_UNMAP),
+s->discard_passthrough[QCOW2_DISCARD_SNAPSHOT] =
+qemu_opt_get_bool(opts, QCOW2_OPT_DISCARD_SNAPSHOT, true),
+s->discard_passthrough[QCOW2_DISCARD_OTHER] =
+qemu_opt_get_bool(opts, QCOW2_OPT_DISCARD_OTHER, false),
+
qemu_opts_del(opts);
if (s->use_lazy_refcounts && s->qcow_version < 3) {
diff --git a/block/qcow2.h b/block/qcow2.h
index 64a6479..6f91b9a 100644
--- a/block/qcow2.h
+++ b/block/qcow2.h
@@ -60,6 +60,9 @@
#define QCOW2_OPT_LAZY_REFCOUNTS "lazy_refcounts"
+#define QCOW2_OPT_DISCARD_REQUEST "pass_discard_request"
+#define QCOW2_OPT_DISCARD_SNAPSHOT "pass_discard_snapshot"
+#define QCOW2_OPT_DISCARD_OTHER "pass_discard_other"
typedef struct QCowHeader {
uint32_t magic;
@@ -187,6 +190,8 @@ typedef struct BDRVQcowState {
int qcow_version;
bool use_lazy_refcounts;
+bool discard_passthrough[QCOW2_DISCARD_MAX];
+
uint64_t incompatible_features;
uint64_t compatible_features;
uint64_t autoclear_features;
--
1.8.1.4
[Qemu-devel] [PATCH 5/5] block: Always enable discard on the protocol level
Turning on discard options in qcow2 doesn't help a lot when the discard
requests that it issues are thrown away by the raw-posix layer. This
patch always enables discard functionality on the protocol level so that
it's the image format's responsibility to send (or not) discard
requests. Requests sent by the guest will be allowed or ignored by the
top level BlockDriverState, which depends on the discard=... option like
before.
In particular, this means that even without specifying options, the
qcow2 default of discarding deleted snapshots actually takes effect now,
both for qemu and qemu-img.
Signed-off-by: Kevin Wolf
---
block.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block.c b/block.c
index 79ad33d..0a7cf2f 100644
--- a/block.c
+++ b/block.c
@@ -1045,7 +1045,7 @@ int bdrv_open(BlockDriverState *bs, const char *filename,
QDict *options,
extract_subqdict(options, &file_options, "file.");
ret = bdrv_file_open(&file, filename, file_options,
- bdrv_open_flags(bs, flags));
+ bdrv_open_flags(bs, flags | BDRV_O_UNMAP));
if (ret < 0) {
goto fail;
}
--
1.8.1.4
[Qemu-devel] [PATCH 4/5] qcow2: Batch discards
This optimises the discard operation for freed clusters by batching
discard requests (both snapshot deletion and bdrv_discard end up
updating the refcounts cluster by cluster).
Note that we don't discard asynchronously, but keep s->lock held. This
is to avoid that a freed cluster is reallocated and written to while the
discard is still in flight.
Signed-off-by: Kevin Wolf
---
block/qcow2-cluster.c | 22 ++---
block/qcow2-refcount.c | 85 --
block/qcow2.c | 1 +
block/qcow2.h | 11 +++
4 files changed, 112 insertions(+), 7 deletions(-)
diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
index 26de1c1..e86bddc 100644
--- a/block/qcow2-cluster.c
+++ b/block/qcow2-cluster.c
@@ -1374,18 +1374,25 @@ int qcow2_discard_clusters(BlockDriverState *bs,
uint64_t offset,
nb_clusters = size_to_clusters(s, end_offset - offset);
+s->cache_discards = true;
+
/* Each L2 table is handled by its own loop iteration */
while (nb_clusters > 0) {
ret = discard_single_l2(bs, offset, nb_clusters);
if (ret < 0) {
-return ret;
+goto fail;
}
nb_clusters -= ret;
offset += (ret * s->cluster_size);
}
-return 0;
+ret = 0;
+fail:
+s->cache_discards = false;
+qcow2_process_discards(bs, ret);
+
+return ret;
}
/*
@@ -1447,15 +1454,22 @@ int qcow2_zero_clusters(BlockDriverState *bs, uint64_t
offset, int nb_sectors)
/* Each L2 table is handled by its own loop iteration */
nb_clusters = size_to_clusters(s, nb_sectors << BDRV_SECTOR_BITS);
+s->cache_discards = true;
+
while (nb_clusters > 0) {
ret = zero_single_l2(bs, offset, nb_clusters);
if (ret < 0) {
-return ret;
+goto fail;
}
nb_clusters -= ret;
offset += (ret * s->cluster_size);
}
-return 0;
+ret = 0;
+fail:
+s->cache_discards = false;
+qcow2_process_discards(bs, ret);
+
+return ret;
}
diff --git a/block/qcow2-refcount.c b/block/qcow2-refcount.c
index 7488988..b5a4fb3 100644
--- a/block/qcow2-refcount.c
+++ b/block/qcow2-refcount.c
@@ -420,6 +420,77 @@ fail_block:
return ret;
}
+void qcow2_process_discards(BlockDriverState *bs, int ret)
+{
+BDRVQcowState *s = bs->opaque;
+Qcow2DiscardRegion *d, *next;
+
+QTAILQ_FOREACH_SAFE(d, &s->discards, next, next) {
+QTAILQ_REMOVE(&s->discards, d, next);
+
+/* Discard is optional, ignore the return value */
+if (ret >= 0) {
+fprintf(stderr, "discard: %lx + %lx\n",
+ d->offset >> BDRV_SECTOR_BITS,
+ d->bytes >> BDRV_SECTOR_BITS);
+bdrv_discard(bs->file,
+ d->offset >> BDRV_SECTOR_BITS,
+ d->bytes >> BDRV_SECTOR_BITS);
+}
+
+g_free(d);
+}
+}
+
+static void update_refcount_discard(BlockDriverState *bs,
+uint64_t offset, uint64_t length)
+{
+BDRVQcowState *s = bs->opaque;
+Qcow2DiscardRegion *d, *p, *next;
+
+QTAILQ_FOREACH(d, &s->discards, next) {
+uint64_t new_start = MIN(offset, d->offset);
+uint64_t new_end = MAX(offset + length, d->offset + d->bytes);
+
+if (new_end - new_start <= length + d->bytes) {
+/* There can't be any overlap, areas ending up here have no
+ * references any more and therefore shouldn't get freed another
+ * time. */
+assert(d->bytes + length == new_end - new_start);
+d->offset = new_start;
+d->bytes = new_end - new_start;
+goto found;
+}
+}
+
+d = g_malloc(sizeof(*d));
+*d = (Qcow2DiscardRegion) {
+.bs = bs,
+.offset = offset,
+.bytes = length,
+};
+QTAILQ_INSERT_TAIL(&s->discards, d, next);
+
+found:
+/* Merge discard requests if they are adjacent now */
+QTAILQ_FOREACH_SAFE(p, &s->discards, next, next) {
+if (p == d
+|| p->offset > d->offset + d->bytes
+|| d->offset > p->offset + p->bytes)
+{
+continue;
+}
+
+/* Still no overlap possible */
+assert(p->offset == d->offset + d->bytes
+|| d->offset == p->offset + p->bytes);
+
+QTAILQ_REMOVE(&s->discards, p, next);
+d->offset = MIN(d->offset, p->offset);
+d->bytes += p->bytes;
+}
+}
+
/* XXX: cache several refcount block clusters ? */
static int QEMU_WARN_UNUSED_RESULT update_refcount(BlockDriverState *bs,
int64_t offset, int64_t length, int addend, enum qcow2_discard_type type)
@@ -488,15 +559,18 @@ static int QEMU_WARN_UNUSED_RESULT
update_refcount(BlockDriverState *bs,
s->free_cluster_index = cluster_index;
}
refcount_block[block_index] = cpu_to_be16(refcount);
+
if (refcount == 0 && s->
[Qemu-devel] [PATCH 2/5] qcow2: Add refcount update reason to all callers
This adds a refcount update reason to all callers of update_refcounts(),
so that a follow-up patch can use this information to decide whether
clusters that reach a refcount of 0 should be discarded in the image
file.
Signed-off-by: Kevin Wolf
---
block/qcow2-cluster.c | 16 +--
block/qcow2-refcount.c | 55 +++---
block/qcow2-snapshot.c | 6 --
block/qcow2.c | 3 ++-
block/qcow2.h | 16 ---
5 files changed, 63 insertions(+), 33 deletions(-)
diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
index 76f30e5..26de1c1 100644
--- a/block/qcow2-cluster.c
+++ b/block/qcow2-cluster.c
@@ -98,14 +98,16 @@ int qcow2_grow_l1_table(BlockDriverState *bs, uint64_t
min_size,
goto fail;
}
g_free(s->l1_table);
-qcow2_free_clusters(bs, s->l1_table_offset, s->l1_size * sizeof(uint64_t));
+qcow2_free_clusters(bs, s->l1_table_offset, s->l1_size * sizeof(uint64_t),
+QCOW2_DISCARD_OTHER);
s->l1_table_offset = new_l1_table_offset;
s->l1_table = new_l1_table;
s->l1_size = new_l1_size;
return 0;
fail:
g_free(new_l1_table);
-qcow2_free_clusters(bs, new_l1_table_offset, new_l1_size2);
+qcow2_free_clusters(bs, new_l1_table_offset, new_l1_size2,
+QCOW2_DISCARD_OTHER);
return ret;
}
@@ -548,7 +550,8 @@ static int get_cluster_table(BlockDriverState *bs, uint64_t
offset,
/* Then decrease the refcount of the old table */
if (l2_offset) {
-qcow2_free_clusters(bs, l2_offset, s->l2_size * sizeof(uint64_t));
+qcow2_free_clusters(bs, l2_offset, s->l2_size * sizeof(uint64_t),
+QCOW2_DISCARD_OTHER);
}
}
@@ -718,7 +721,8 @@ int qcow2_alloc_cluster_link_l2(BlockDriverState *bs,
QCowL2Meta *m)
*/
if (j != 0) {
for (i = 0; i < j; i++) {
-qcow2_free_any_clusters(bs, be64_to_cpu(old_cluster[i]), 1);
+qcow2_free_any_clusters(bs, be64_to_cpu(old_cluster[i]), 1,
+QCOW2_DISCARD_OTHER);
}
}
@@ -1339,7 +1343,7 @@ static int discard_single_l2(BlockDriverState *bs,
uint64_t offset,
l2_table[l2_index + i] = cpu_to_be64(0);
/* Then decrease the refcount */
-qcow2_free_any_clusters(bs, old_offset, 1);
+qcow2_free_any_clusters(bs, old_offset, 1, QCOW2_DISCARD_REQUEST);
}
ret = qcow2_cache_put(bs, s->l2_table_cache, (void**) &l2_table);
@@ -1415,7 +1419,7 @@ static int zero_single_l2(BlockDriverState *bs, uint64_t
offset,
qcow2_cache_entry_mark_dirty(s->l2_table_cache, l2_table);
if (old_offset & QCOW_OFLAG_COMPRESSED) {
l2_table[l2_index + i] = cpu_to_be64(QCOW_OFLAG_ZERO);
-qcow2_free_any_clusters(bs, old_offset, 1);
+qcow2_free_any_clusters(bs, old_offset, 1, QCOW2_DISCARD_REQUEST);
} else {
l2_table[l2_index + i] |= cpu_to_be64(QCOW_OFLAG_ZERO);
}
diff --git a/block/qcow2-refcount.c b/block/qcow2-refcount.c
index b32738f..6d35e49 100644
--- a/block/qcow2-refcount.c
+++ b/block/qcow2-refcount.c
@@ -29,7 +29,7 @@
static int64_t alloc_clusters_noref(BlockDriverState *bs, int64_t size);
static int QEMU_WARN_UNUSED_RESULT update_refcount(BlockDriverState *bs,
int64_t offset, int64_t length,
-int addend);
+int addend, enum qcow2_discard_type type);
/*/
@@ -235,7 +235,8 @@ static int alloc_refcount_block(BlockDriverState *bs,
} else {
/* Described somewhere else. This can recurse at most twice before we
* arrive at a block that describes itself. */
-ret = update_refcount(bs, new_block, s->cluster_size, 1);
+ret = update_refcount(bs, new_block, s->cluster_size, 1,
+ QCOW2_DISCARD_NEVER);
if (ret < 0) {
goto fail_block;
}
@@ -399,7 +400,8 @@ static int alloc_refcount_block(BlockDriverState *bs,
/* Free old table. Remember, we must not change free_cluster_index */
uint64_t old_free_cluster_index = s->free_cluster_index;
-qcow2_free_clusters(bs, old_table_offset, old_table_size *
sizeof(uint64_t));
+qcow2_free_clusters(bs, old_table_offset, old_table_size *
sizeof(uint64_t),
+QCOW2_DISCARD_OTHER);
s->free_cluster_index = old_free_cluster_index;
ret = load_refcount_block(bs, new_block, (void**) refcount_block);
@@ -420,7 +422,7 @@ fail_block:
/* XXX: cache several refcount block clusters ? */
static int QEMU_WARN_UNUSED_RESULT update_refcount(BlockDriverState *bs,
-int64_t offset, int64_t length, int addend)
+int64_t offset, int64_t length, int addend, enum qcow2_discard_type type)
{
BDRVQcowState *s = bs->opaque;
Re: [Qemu-devel] [PATCH RFC 1/8] exec: Fix Xen RAM allocation with unusual options
On Thu, 13 Jun 2013, Markus Armbruster wrote:
> Issues:
>
> * We try to obey -mem-path even though it can't work with Xen.
>
> * To implement -machine mem-merge, we call
> memory_try_enable_merging(new_block->host, size). But with Xen,
> new_block->host remains null. Oops.
>
> Fix by separating Xen allocation from normal allocation.
>
> Signed-off-by: Markus Armbruster
Acked-by: Stefano Stabellini
> exec.c | 20
> 1 file changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/exec.c b/exec.c
> index 5b8b40d..b424e12 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -1081,6 +1081,12 @@ ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size,
> void *host,
> if (host) {
> new_block->host = host;
> new_block->flags |= RAM_PREALLOC_MASK;
> +} else if (xen_enabled()) {
> +if (mem_path) {
> +fprintf(stderr, "-mem-path not supported with Xen\n");
> +exit(1);
> +}
> +xen_ram_alloc(new_block->offset, size, mr);
> } else {
> if (mem_path) {
> #if defined (__linux__) && !defined(TARGET_S390X)
> @@ -1094,9 +1100,7 @@ ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size,
> void *host,
> exit(1);
> #endif
> } else {
> -if (xen_enabled()) {
> -xen_ram_alloc(new_block->offset, size, mr);
> -} else if (kvm_enabled()) {
> +if (kvm_enabled()) {
> /* some s390/kvm configurations have special constraints */
> new_block->host = kvm_ram_alloc(size);
> } else {
> @@ -1174,6 +1178,8 @@ void qemu_ram_free(ram_addr_t addr)
> ram_list.version++;
> if (block->flags & RAM_PREALLOC_MASK) {
> ;
> +} else if (xen_enabled()) {
> +xen_invalidate_map_cache_entry(block->host);
> } else if (mem_path) {
> #if defined (__linux__) && !defined(TARGET_S390X)
> if (block->fd) {
> @@ -1186,11 +1192,7 @@ void qemu_ram_free(ram_addr_t addr)
> abort();
> #endif
> } else {
> -if (xen_enabled()) {
> -xen_invalidate_map_cache_entry(block->host);
> -} else {
> -qemu_anon_ram_free(block->host, block->length);
> -}
> +qemu_anon_ram_free(block->host, block->length);
> }
> g_free(block);
> break;
> @@ -1214,6 +1216,8 @@ void qemu_ram_remap(ram_addr_t addr, ram_addr_t length)
> vaddr = block->host + offset;
> if (block->flags & RAM_PREALLOC_MASK) {
> ;
> +} else if (xen_enabled()) {
> +abort();
> } else {
> flags = MAP_FIXED;
> munmap(vaddr, length);
> --
> 1.7.11.7
>
Re: [Qemu-devel] [RFC] sanitize memory on system reset
Markus Armbruster writes: > Peter Lieven writes: > >> On 13.06.2013 10:40, Stefan Hajnoczi wrote: >>> On Thu, Jun 13, 2013 at 08:09:09AM +0200, Peter Lieven wrote: I was thinking if it would be a good idea to zeroize all memory resources on system reset and madvise dontneed them afterwards. This would avoid system reset attacks in case the attacker has only access to the console of a vServer but not on the physical host and it would shrink RSS size of the vServer siginificantly. >>> I wonder if you'll hit weird OS installers or PXE clients that rely on >>> stashing stuff in memory across reset. >> One point: >> Wouldn't a memory test which some systems do at startup break these as well? > > Systems that distinguish between warm and cold boot (such as PCs) > generally run POST only on cold boot. > > I'm not saying triggering warm reboot and expecting memory contents to > survive is a good idea, but it has been done. Doesn't kexec do a warm reboot stashing the new kernel somewhere in memory? Regards, Anthony Liguori
Re: [Qemu-devel] Patch Round-up for stable 1.5.1, freeze on 2013-06-19
Il 12/06/2013 17:41, Michael Roth ha scritto: > Hi everyone, > > The following new patches are queued for QEMU stable v1.5.1: > > https://github.com/mdroth/qemu/commits/stable-1.5-staging > > The release is planned for 2013-06-26: > > http://wiki.qemu.org/Planning/1.5 > > Please respond here or CC qemu-sta...@nongnu.org on any patches you > think should be included in the release. The cut-off date is > 2013-06-19 for new patches. I'm going to send pull requests for SCSI and NBD on Monday, both of them will include 1.5.1 patches. Thanks! Paolo > Testing/feedback is greatly appreciated. > > Thanks! > > > Amos Kong (1): > qdev: fix get_fw_dev_path to support to add nothing to fw_dev_path > > Andreas Färber (1): > ide: Set BSY bit during FLUSH > > Aneesh Kumar K.V (2): > hw/9pfs: Fix segfault with 9p2000.u > hw/9pfs: use O_NOFOLLOW for mapped readlink operation > > Brad Smith (2): > Remove OSS support for OpenBSD > ui/gtk.c: Fix *BSD build of Gtk+ UI > > Cornelia Huck (2): > s390x/css: Fix concurrent sense. > virtio-ccw: Fix unsetting of indicators. > > Ed Maste (1): > host-libusb: Correct test for USB packet state > > Gerd Hoffmann (3): > chardev: fix "info chardev" output > Revert "roms: switch oldnoconfig to olddefconfig" > update seabios to release 1.7.2.2 > > Luiz Capitulino (1): > target-i386: fix abort on bad PML4E/PDPTE/PDE/PTE addresses > > Michael Marineau (1): > Fix usage of USB_DEV_FLAG_IS_HOST flag. > > Michael Roth (1): > qemu-char: don't issue CHR_EVENT_OPEN in a BH > > Michael S. Tsirkin (1): > q35: set fw_name > > Paolo Bonzini (1): > do not check pointers after dereferencing them > > Peter Crosthwaite (1): > qom/object: Don't poll cast cache for NULL objects > > Richard Henderson (1): > target-i386: Fix aflag logic for CODE64 and the 0x67 prefix > > Stefan Hajnoczi (2): > rtl8139: flush queued packets when RxBufPtr is written > vmxnet3: fix NICState cleanup > > Stefano Stabellini (4): > xen: simplify xen_enabled > main_loop: do not set nonblocking if xen_enabled() > xen_machine_pv: do not create a dummy CPU in machine->init > xen: start PCI hole at 0xe000 (same as pc_init1 and > qemu-xen-traditional) > > Wendy Liang (1): > xilinx_axidma: Do not set DMA .notify to NULL after notify > > audio/ossaudio.c |4 > backends/baum.c |2 -- > backends/msmouse.c|1 + > configure |5 ++--- > hw/9pfs/virtio-9p-local.c |2 +- > hw/9pfs/virtio-9p.c |2 +- > hw/core/qdev.c| 10 - > hw/dma/xilinx_axidma.c|3 ++- > hw/i386/pc_piix.c |6 +++--- > hw/i386/xen_machine_pv.c | 16 --- > hw/ide/core.c |1 + > hw/net/rtl8139.c |3 +++ > hw/net/vmxnet3.c |2 +- > hw/pci-host/q35.c |1 + > hw/s390x/css.c|2 +- > hw/s390x/virtio-ccw.c |8 > hw/usb/core.c |2 +- > hw/usb/host-libusb.c |2 +- > hw/virtio/virtio-bus.c|6 ++ > include/hw/i386/pc.h |3 +++ > include/hw/xen/xen.h |4 > include/qemu-common.h |1 + > include/sysemu/char.h |2 +- > monitor.c |2 +- > pc-bios/bios.bin | Bin 131072 -> 131072 bytes > qemu-char.c | 41 > ++--- > qom/object.c |4 ++-- > roms/configure-seabios.sh |2 +- > roms/seabios |2 +- > savevm.c |8 > spice-qemu-char.c |1 + > target-i386/arch_memory_mapping.c | 10 + > target-i386/translate.c | 30 +-- > ui/console.c |4 > ui/gtk.c |2 ++ > vl.c |2 +- > xen-all.c | 12 +-- > 37 files changed, 107 insertions(+), 101 deletions(-) > > >
Re: [Qemu-devel] [RFC] sanitize memory on system reset
Il 13/06/2013 07:56, Anthony Liguori ha scritto: > Markus Armbruster writes: > >> Peter Lieven writes: >> >>> On 13.06.2013 10:40, Stefan Hajnoczi wrote: On Thu, Jun 13, 2013 at 08:09:09AM +0200, Peter Lieven wrote: > I was thinking if it would be a good idea to zeroize all memory > resources on system reset and > madvise dontneed them afterwards. This would avoid system reset > attacks in case the attacker > has only access to the console of a vServer but not on the physical > host and it would shrink > RSS size of the vServer siginificantly. I wonder if you'll hit weird OS installers or PXE clients that rely on stashing stuff in memory across reset. >>> One point: >>> Wouldn't a memory test which some systems do at startup break these as well? >> >> Systems that distinguish between warm and cold boot (such as PCs) >> generally run POST only on cold boot. >> >> I'm not saying triggering warm reboot and expecting memory contents to >> survive is a good idea, but it has been done. > > Doesn't kexec do a warm reboot stashing the new kernel somewhere in > memory? No, it undoes most of the hardware setup and jumps to the new kernel. It never goes through the BIOS. Paolo
Re: [Qemu-devel] [PATCH v2 1/2] ps2: add support of auto-repeat
Il 13/06/2013 06:19, Andreas Färber ha scritto:
> Am 31.05.2013 14:31, schrieb Amos Kong:
>> diff --git a/hw/input/ps2.c b/hw/input/ps2.c
>> index cdb18e6..fdb9912 100644
>> --- a/hw/input/ps2.c
>> +++ b/hw/input/ps2.c
>> @@ -615,7 +615,17 @@ static bool ps2_keyboard_repeatstate_needed(void
>> *opaque)
>> {
>> PS2KbdState *s = opaque;
>>
>> -return s->repeat_period || s->repeat_delay;
>> +return s->repeat_period || s->repeat_delay || s->repeat_key ||
>> s->repeat_timer;
>> +}
>> +
>> +static int ps2_kbd_repeatstate_load(QEMUFile *f, void *opaque, int
>> version_id)
>> +{
>> +PS2KbdState *s = opaque;
>> +qemu_get_timer(f, s->repeat_timer);
>> +qemu_mod_timer(s->repeat_timer, qemu_get_clock_ns(vm_clock) +
>> + muldiv64(get_ticks_per_sec(), s->repeat_period,
>> 1000));
>> +
>> +return 0;
>> }
>>
>> static bool ps2_keyboard_ledstate_needed(void *opaque)
>> @@ -638,9 +648,12 @@ static const VMStateDescription
>> vmstate_ps2_keyboard_repeatstate = {
>> .version_id = 3,
>> .minimum_version_id = 2,
>> .minimum_version_id_old = 2,
>> +.load_state_old = ps2_kbd_repeatstate_load,
>> .fields = (VMStateField[]) {
>> VMSTATE_INT32(repeat_period, PS2KbdState),
>> VMSTATE_INT32(repeat_delay, PS2KbdState),
>> +VMSTATE_INT32(repeat_key, PS2KbdState),
>> +VMSTATE_TIMER(repeat_timer, PS2KbdState),
>
> You can't just add fields here, they'd need to be specific to a new
> version 4. Requested was to make it a subsection instead.
This is already a subsection, and this patch is just a proposal to be
squashed in this series (which adds the subsection). But I think Amos
is right and only the period/delay need to be migrated. Otherwise,
you'll get an endless stream of repeats on the destination.
Paolo
Re: [Qemu-devel] Patch Round-up for stable 1.5.1, freeze on 2013-06-19
Am 13.06.2013 14:27, schrieb Paolo Bonzini: > Il 12/06/2013 17:41, Michael Roth ha scritto: >> Hi everyone, >> >> The following new patches are queued for QEMU stable v1.5.1: >> >> https://github.com/mdroth/qemu/commits/stable-1.5-staging >> >> The release is planned for 2013-06-26: >> >> http://wiki.qemu.org/Planning/1.5 >> >> Please respond here or CC qemu-sta...@nongnu.org on any patches you >> think should be included in the release. The cut-off date is >> 2013-06-19 for new patches. > > I'm going to send pull requests for SCSI and NBD on Monday, both of them > will include 1.5.1 patches. Thanks! Ditto for my in-flight qom-cpu pull. BTW v1.4.2 was still missing in qemu.git yesterday, is there a pull pending already? Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] Patch Round-up for stable 1.5.1, freeze on 2013-06-19
On 12/06/2013 23:41, Michael Roth wrote: Hi everyone, The following new patches are queued for QEMU stable v1.5.1: https://github.com/mdroth/qemu/commits/stable-1.5-staging The release is planned for 2013-06-26: http://wiki.qemu.org/Planning/1.5 Please respond here or CC qemu-sta...@nongnu.org on any patches you think should be included in the release. The cut-off date is 2013-06-19 for new patches. Hi, I think "virtio-scsi: forward scsibus for virtio-scsi-pci." should be included. I CC'ed qemu-sta...@nongnu.org but I don't see it on the stable list. Did I make a mistake somewhere? Thanks, Fred Testing/feedback is greatly appreciated. Thanks! Amos Kong (1): qdev: fix get_fw_dev_path to support to add nothing to fw_dev_path Andreas Färber (1): ide: Set BSY bit during FLUSH Aneesh Kumar K.V (2): hw/9pfs: Fix segfault with 9p2000.u hw/9pfs: use O_NOFOLLOW for mapped readlink operation Brad Smith (2): Remove OSS support for OpenBSD ui/gtk.c: Fix *BSD build of Gtk+ UI Cornelia Huck (2): s390x/css: Fix concurrent sense. virtio-ccw: Fix unsetting of indicators. Ed Maste (1): host-libusb: Correct test for USB packet state Gerd Hoffmann (3): chardev: fix "info chardev" output Revert "roms: switch oldnoconfig to olddefconfig" update seabios to release 1.7.2.2 Luiz Capitulino (1): target-i386: fix abort on bad PML4E/PDPTE/PDE/PTE addresses Michael Marineau (1): Fix usage of USB_DEV_FLAG_IS_HOST flag. Michael Roth (1): qemu-char: don't issue CHR_EVENT_OPEN in a BH Michael S. Tsirkin (1): q35: set fw_name Paolo Bonzini (1): do not check pointers after dereferencing them Peter Crosthwaite (1): qom/object: Don't poll cast cache for NULL objects Richard Henderson (1): target-i386: Fix aflag logic for CODE64 and the 0x67 prefix Stefan Hajnoczi (2): rtl8139: flush queued packets when RxBufPtr is written vmxnet3: fix NICState cleanup Stefano Stabellini (4): xen: simplify xen_enabled main_loop: do not set nonblocking if xen_enabled() xen_machine_pv: do not create a dummy CPU in machine->init xen: start PCI hole at 0xe000 (same as pc_init1 and qemu-xen-traditional) Wendy Liang (1): xilinx_axidma: Do not set DMA .notify to NULL after notify audio/ossaudio.c |4 backends/baum.c |2 -- backends/msmouse.c|1 + configure |5 ++--- hw/9pfs/virtio-9p-local.c |2 +- hw/9pfs/virtio-9p.c |2 +- hw/core/qdev.c| 10 - hw/dma/xilinx_axidma.c|3 ++- hw/i386/pc_piix.c |6 +++--- hw/i386/xen_machine_pv.c | 16 --- hw/ide/core.c |1 + hw/net/rtl8139.c |3 +++ hw/net/vmxnet3.c |2 +- hw/pci-host/q35.c |1 + hw/s390x/css.c|2 +- hw/s390x/virtio-ccw.c |8 hw/usb/core.c |2 +- hw/usb/host-libusb.c |2 +- hw/virtio/virtio-bus.c|6 ++ include/hw/i386/pc.h |3 +++ include/hw/xen/xen.h |4 include/qemu-common.h |1 + include/sysemu/char.h |2 +- monitor.c |2 +- pc-bios/bios.bin | Bin 131072 -> 131072 bytes qemu-char.c | 41 ++--- qom/object.c |4 ++-- roms/configure-seabios.sh |2 +- roms/seabios |2 +- savevm.c |8 spice-qemu-char.c |1 + target-i386/arch_memory_mapping.c | 10 + target-i386/translate.c | 30 +-- ui/console.c |4 ui/gtk.c |2 ++ vl.c |2 +- xen-all.c | 12 +-- 37 files changed, 107 insertions(+), 101 deletions(-)
Re: [Qemu-devel] Patch Round-up for stable 1.5.1, freeze on 2013-06-19
On 12/06/2013 23:41, Michael Roth wrote: Hi everyone, The following new patches are queued for QEMU stable v1.5.1: https://github.com/mdroth/qemu/commits/stable-1.5-staging The release is planned for 2013-06-26: http://wiki.qemu.org/Planning/1.5 Please respond here or CC qemu-sta...@nongnu.org on any patches you think should be included in the release. The cut-off date is 2013-06-19 for new patches. Testing/feedback is greatly appreciated. And it seems you forget "virtio-rng: Fix crash with non-default backend". You said you'll pick it up for 1.5.1 ;) Fred Thanks! Amos Kong (1): qdev: fix get_fw_dev_path to support to add nothing to fw_dev_path Andreas Färber (1): ide: Set BSY bit during FLUSH Aneesh Kumar K.V (2): hw/9pfs: Fix segfault with 9p2000.u hw/9pfs: use O_NOFOLLOW for mapped readlink operation Brad Smith (2): Remove OSS support for OpenBSD ui/gtk.c: Fix *BSD build of Gtk+ UI Cornelia Huck (2): s390x/css: Fix concurrent sense. virtio-ccw: Fix unsetting of indicators. Ed Maste (1): host-libusb: Correct test for USB packet state Gerd Hoffmann (3): chardev: fix "info chardev" output Revert "roms: switch oldnoconfig to olddefconfig" update seabios to release 1.7.2.2 Luiz Capitulino (1): target-i386: fix abort on bad PML4E/PDPTE/PDE/PTE addresses Michael Marineau (1): Fix usage of USB_DEV_FLAG_IS_HOST flag. Michael Roth (1): qemu-char: don't issue CHR_EVENT_OPEN in a BH Michael S. Tsirkin (1): q35: set fw_name Paolo Bonzini (1): do not check pointers after dereferencing them Peter Crosthwaite (1): qom/object: Don't poll cast cache for NULL objects Richard Henderson (1): target-i386: Fix aflag logic for CODE64 and the 0x67 prefix Stefan Hajnoczi (2): rtl8139: flush queued packets when RxBufPtr is written vmxnet3: fix NICState cleanup Stefano Stabellini (4): xen: simplify xen_enabled main_loop: do not set nonblocking if xen_enabled() xen_machine_pv: do not create a dummy CPU in machine->init xen: start PCI hole at 0xe000 (same as pc_init1 and qemu-xen-traditional) Wendy Liang (1): xilinx_axidma: Do not set DMA .notify to NULL after notify audio/ossaudio.c |4 backends/baum.c |2 -- backends/msmouse.c|1 + configure |5 ++--- hw/9pfs/virtio-9p-local.c |2 +- hw/9pfs/virtio-9p.c |2 +- hw/core/qdev.c| 10 - hw/dma/xilinx_axidma.c|3 ++- hw/i386/pc_piix.c |6 +++--- hw/i386/xen_machine_pv.c | 16 --- hw/ide/core.c |1 + hw/net/rtl8139.c |3 +++ hw/net/vmxnet3.c |2 +- hw/pci-host/q35.c |1 + hw/s390x/css.c|2 +- hw/s390x/virtio-ccw.c |8 hw/usb/core.c |2 +- hw/usb/host-libusb.c |2 +- hw/virtio/virtio-bus.c|6 ++ include/hw/i386/pc.h |3 +++ include/hw/xen/xen.h |4 include/qemu-common.h |1 + include/sysemu/char.h |2 +- monitor.c |2 +- pc-bios/bios.bin | Bin 131072 -> 131072 bytes qemu-char.c | 41 ++--- qom/object.c |4 ++-- roms/configure-seabios.sh |2 +- roms/seabios |2 +- savevm.c |8 spice-qemu-char.c |1 + target-i386/arch_memory_mapping.c | 10 + target-i386/translate.c | 30 +-- ui/console.c |4 ui/gtk.c |2 ++ vl.c |2 +- xen-all.c | 12 +-- 37 files changed, 107 insertions(+), 101 deletions(-)
Re: [Qemu-devel] fdisk still shows the "/dev/sdb" partitions even after the removal of scsi disk
On 06/13/13 12:19, chandrashekar shastri wrote: > Hi, > > I have filed a bug "fdisk still shows the "/dev/sdb" partitions even > after the removal of scsi disk" for the upstream kernel. > > Bug link: > https://bugs.launchpad.net/qemu/+bug/1190525 > > RHEL guest shows the partittions even after the removal of scsi disk: > fdisk still shows the "/dev/sdb" partitions even after the removal of > scsi disk. > > Guest details: > --- > Kernel : 2.6.32-358 > > Host Details : > > Upstream Kernel, Qemu, Libvirt and virt-manager > - > > kernel version : 3.9.0+ > qemu version : QEMU emulator version 1.5.0 > libvirt version : 1.0.5 > virt-install : 0.600.3 > > Steps to reproduce the issue: > > I. Add the SCSI disk through the virt-manager. > 2. Create the partition using fdisk (eg: /dev/sbb) > 3. Create a filesystem and format using mkfs.ext3 or mkfs.ext4 > 4. Remove the scsi disk through the virt-manager. > 5. Again run the fdisk /dev/sdb, the guests still shows the partition > even after the removal of the disk. > > This issue is not seen with virt-io disk. > > This issue is also reproducible without even creating the partitions. > > Expected Result: > > The output of fdisk /dev/sd* should not show the enties after the > removal of scsi disks What happens if you run "scsi-rescan --remove" or "scsi-rescan --forcerescan" in the guest? (Paolo had recommended this to me for an independent problem / case.) Laszlo
Re: [Qemu-devel] [PATCH 2/2] Add monitor command mem-nodes
On Thu, Jun 13, 2013 at 09:40:14AM +0800, Wanlong Gao wrote: > On 06/11/2013 09:40 PM, Eduardo Habkost wrote: > > On Tue, Jun 11, 2013 at 03:22:13PM +0800, Wanlong Gao wrote: > >> On 06/05/2013 09:46 PM, Eduardo Habkost wrote: > >>> On Wed, Jun 05, 2013 at 11:58:25AM +0800, Wanlong Gao wrote: > Add monitor command mem-nodes to show the huge mapped > memory nodes locations. > > >>> > >>> This is for machine consumption, so we need a QMP command. > >>> > (qemu) info mem-nodes > /proc/14132/fd/13: 2ac0-2aaaeac0: node0 > /proc/14132/fd/13: 2aaaeac0-2aab2ac0: node1 > /proc/14132/fd/14: 2aab2ac0-2aab2b00: node0 > /proc/14132/fd/14: 2aab2b00-2aab2b40: node1 > >>> > >>> Are node0/node1 _host_ nodes? > >>> > >>> How do I know what's the _guest_ address/node corresponding to each > >>> file/range above? > >>> > >>> What I am really looking for is: > >>> > >>> * The correspondence between guest (virtual) NUMA nodes and guest > >>>physical address ranges (it could be provided by the QMP version of > >>>"info numa") > >> > >> AFAIK, the guest NUMA nodes and guest physical address ranges are set > >> by seabios, we can't get this information from QEMU, > > > > QEMU _has_ to know about it, otherwise we would never be able to know > > which virtual addresses inside the QEMU process (or offsets inside the > > backing files) belong to which virtual NUMA node. > > Nope, if I'm right, actually it's linear except that there are holes in > the physical address spaces. So we can know which node the guest virtual > address is included just by each numa node size. You are just describing a way to accomplish the item I asked about above: finding out the correspondence between guest physical addresses and NUMA nodes. :) (But I would prefer to have something more explicit in the QMP interface instead of something implicit that assumes a predefined binding) > It's enough for us if we > can provide a QMP interface from QEMU to let external tools like libvirt > set the host memory binding polices according to the QMP interface, and > we can also provide the QEMU command line option to be able to set host > bindings through command line options before we start QEMU process. And how would you identify memory regions through this memory binding QMP interface, if not by guest physical addresses? > > > > > (After all, the NUMA wiring is a hardware feature, not something that > > the BIOS can decide) > > But this is ACPI table which wrote by seabios now. AFAIK, there is no > unified idea about moving this part to QEMU with the QEMU interfaces > for seabios removed or just stay it there. It doesn't matter who writes the ACPI table. QEMU must always know on which virtual NUMA node each memory region is located. > > > >> and I think this > >> information is useless for pinning memory range to host. > > > > Well, we have to somehow identify each region of guest memory when > > deciding how to pin it. How would you identify it without using guest > > physical addresses? Guest physical addresses are more meaningful than > > the QEMU virtual addresses your patch exposes (that are meaningless > > outside QEMU). > > As I mentioned above, we can know this just by the guest node memory size, > and can set the host bindings by treating this sizes as offsets. > And I think we only need to set the host memory binding polices to each > guest numa nodes. It's unnecessary to set polices to each region as you > said. I believe an interface based on guest physical memory addresses is more flexible (and even simpler!) than one that only allows binding of whole virtual NUMA nodes. (And I still don't understand why you are exposing QEMU virtual memory addresses in the new command, if they are useless). > > > > > >>> * The correspondence between guest physical address ranges and ranges > >>>inside the mapped files (so external tools could set the policy on > >>>those files instead of requiring QEMU to set it directly) > >>> > >>> I understand that your use case may require additional information and > >>> additional interfaces. But if we provide the information above we will > >>> allow external components set the policy on the hugetlbfs files before > >>> we add new interfaces required for your use case. > >> > >> But the file backed memory is not good for the host which has many > >> virtual machines, in this situation, we can't handle anon THP yet. > > > > I don't understand what you mean, here. What prevents someone from using > > file-backed memory with multiple virtual machines? > > While if we use hugetlbfs backed memory, we should know how many virtual > machines, > how much memory each vm will use, then reserve these pages for them. And even > should reserve more pages for external tools(numactl) to set memory polices. > Even the memory reservation also has it's own memory policies. It's very hard > to cont
[Qemu-devel] [PATCH] target-arm: Make LPAE feature imply V7MP
The v7 ARM ARM specifies that the Large Physical Address
Extension requires implementation of the Multiprocessing
Extensions, so make our LPAE feature imply V7MP rather
than specifying both in the A15 CPU initfn.
Signed-off-by: Peter Maydell
---
Doesn't make much difference now, but will save a line when
adding future CPU definitions.
target-arm/cpu.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target-arm/cpu.c b/target-arm/cpu.c
index 496a59f..54b4bb2 100644
--- a/target-arm/cpu.c
+++ b/target-arm/cpu.c
@@ -198,6 +198,7 @@ static void arm_cpu_realizefn(DeviceState *dev, Error
**errp)
set_feature(env, ARM_FEATURE_VFP);
}
if (arm_feature(env, ARM_FEATURE_LPAE)) {
+set_feature(env, ARM_FEATURE_V7MP);
set_feature(env, ARM_FEATURE_PXN);
}
@@ -571,7 +572,6 @@ static void cortex_a15_initfn(Object *obj)
set_feature(&cpu->env, ARM_FEATURE_NEON);
set_feature(&cpu->env, ARM_FEATURE_THUMB2EE);
set_feature(&cpu->env, ARM_FEATURE_ARM_DIV);
-set_feature(&cpu->env, ARM_FEATURE_V7MP);
set_feature(&cpu->env, ARM_FEATURE_GENERIC_TIMER);
set_feature(&cpu->env, ARM_FEATURE_DUMMY_C15_REGS);
set_feature(&cpu->env, ARM_FEATURE_LPAE);
--
1.7.9.5
Re: [Qemu-devel] [PATCH 1/3] target-arm: add feature flag for ARMv8
On 7 June 2013 13:06, Mans Rullgard wrote:
> Signed-off-by: Mans Rullgard
> ---
> target-arm/cpu.c | 5 -
> target-arm/cpu.h | 1 +
> target-arm/translate.c | 1 +
> 3 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/target-arm/cpu.c b/target-arm/cpu.c
> index 496a59f..f5a1314 100644
> --- a/target-arm/cpu.c
> +++ b/target-arm/cpu.c
> @@ -162,6 +162,9 @@ static void arm_cpu_realizefn(DeviceState *dev, Error
> **errp)
> CPUARMState *env = &cpu->env;
>
> /* Some features automatically imply others: */
> +if (arm_feature(env, ARM_FEATURE_V8)) {
> +set_feature(env, ARM_FEATURE_V7);
> +}
This should also imply ARM_FEATURE_ARM_DIV and ARM_FEATURE_LPAE.
thanks
-- PMM
[Qemu-devel] [PATCH] exec: move io_mem_read/write to memory.h
implementation is in memory.c, move function to match. This allows use from places that don't pull in exec-all.h Signed-off-by: Michael S. Tsirkin --- include/exec/exec-all.h | 5 - include/exec/memory.h | 5 + 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/include/exec/exec-all.h b/include/exec/exec-all.h index 6362074..28cb37d 100644 --- a/include/exec/exec-all.h +++ b/include/exec/exec-all.h @@ -367,11 +367,6 @@ bool is_tcg_gen_code(uintptr_t pc_ptr); #if !defined(CONFIG_USER_ONLY) struct MemoryRegion *iotlb_to_region(hwaddr index); -uint64_t io_mem_read(struct MemoryRegion *mr, hwaddr addr, - unsigned size); -void io_mem_write(struct MemoryRegion *mr, hwaddr addr, - uint64_t value, unsigned size); - void tlb_fill(CPUArchState *env1, target_ulong addr, int is_write, int mmu_idx, uintptr_t retaddr); diff --git a/include/exec/memory.h b/include/exec/memory.h index 9e88320..edeb1f2 100644 --- a/include/exec/memory.h +++ b/include/exec/memory.h @@ -888,6 +888,11 @@ void address_space_unmap(AddressSpace *as, void *buffer, hwaddr len, int is_write, hwaddr access_len); +uint64_t io_mem_read(struct MemoryRegion *mr, hwaddr addr, + unsigned size); +void io_mem_write(struct MemoryRegion *mr, hwaddr addr, + uint64_t value, unsigned size); + #endif #endif -- MST
Re: [Qemu-devel] [PATCH 3/3] target-arm: explicitly decode SEVL instruction
On 7 June 2013 13:06, Mans Rullgard wrote: > The ARMv8 SEVL instruction is in the architectural hint space already > emulated as nop. This makes the decoding of SEVL explicit for clarity. > > Signed-off-by: Mans Rullgard Reviewed-by: Peter Maydell -- PMM
Re: [Qemu-devel] [PATCH] target-arm: Make LPAE feature imply V7MP
Am 13.06.2013 14:51, schrieb Peter Maydell: > The v7 ARM ARM specifies that the Large Physical Address > Extension requires implementation of the Multiprocessing > Extensions, so make our LPAE feature imply V7MP rather > than specifying both in the A15 CPU initfn. > > Signed-off-by: Peter Maydell > --- > Doesn't make much difference now, but will save a line when > adding future CPU definitions. Looks sensible, Reviewed-by: Andreas Färber Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH v2 1/2] ps2: add support of auto-repeat
Paolo Bonzini writes:
> Il 13/06/2013 06:19, Andreas Färber ha scritto:
>> Am 31.05.2013 14:31, schrieb Amos Kong:
>>> diff --git a/hw/input/ps2.c b/hw/input/ps2.c
>>> index cdb18e6..fdb9912 100644
>>> --- a/hw/input/ps2.c
>>> +++ b/hw/input/ps2.c
>>> @@ -615,7 +615,17 @@ static bool ps2_keyboard_repeatstate_needed(void
>>> *opaque)
>>> {
>>> PS2KbdState *s = opaque;
>>>
>>> -return s->repeat_period || s->repeat_delay;
>>> +return s->repeat_period || s->repeat_delay || s->repeat_key ||
>>> s->repeat_timer;
>>> +}
>>> +
>>> +static int ps2_kbd_repeatstate_load(QEMUFile *f, void *opaque, int
>>> version_id)
>>> +{
>>> +PS2KbdState *s = opaque;
>>> +qemu_get_timer(f, s->repeat_timer);
>>> +qemu_mod_timer(s->repeat_timer, qemu_get_clock_ns(vm_clock) +
>>> + muldiv64(get_ticks_per_sec(), s->repeat_period,
>>> 1000));
>>> +
>>> +return 0;
>>> }
>>>
>>> static bool ps2_keyboard_ledstate_needed(void *opaque)
>>> @@ -638,9 +648,12 @@ static const VMStateDescription
>>> vmstate_ps2_keyboard_repeatstate = {
>>> .version_id = 3,
>>> .minimum_version_id = 2,
>>> .minimum_version_id_old = 2,
>>> +.load_state_old = ps2_kbd_repeatstate_load,
>>> .fields = (VMStateField[]) {
>>> VMSTATE_INT32(repeat_period, PS2KbdState),
>>> VMSTATE_INT32(repeat_delay, PS2KbdState),
>>> +VMSTATE_INT32(repeat_key, PS2KbdState),
>>> +VMSTATE_TIMER(repeat_timer, PS2KbdState),
>>
>> You can't just add fields here, they'd need to be specific to a new
>> version 4. Requested was to make it a subsection instead.
>
> This is already a subsection, and this patch is just a proposal to be
> squashed in this series (which adds the subsection). But I think Amos
> is right and only the period/delay need to be migrated. Otherwise,
> you'll get an endless stream of repeats on the destination.
Not with seamless migration and spice.
Even with a non-seamless VNC reconnect, if it happens behind the scenes
the release would still be sent.
Regards,
Anthony Liguori
>
> Paolo
Re: [Qemu-devel] [PATCH 3/3] target-arm: explicitly decode SEVL instruction
Am 07.06.2013 14:06, schrieb Mans Rullgard: > The ARMv8 SEVL instruction is in the architectural hint space already > emulated as nop. This makes the decoding of SEVL explicit for clarity. > > Signed-off-by: Mans Rullgard > --- > target-arm/translate.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/target-arm/translate.c b/target-arm/translate.c > index f529257..cfd148e 100644 > --- a/target-arm/translate.c > +++ b/target-arm/translate.c > @@ -3501,6 +3501,7 @@ static void gen_nop_hint(DisasContext *s, int val) > break; > case 2: /* wfe */ > case 4: /* sev */ > +case 5: /* sevl */ > /* TODO: Implement SEV and WFE. May help SMP performance. */ > default: /* nop */ > break; So does SEVL need to be implemented? Then the TODO should be updated. Otherwise moving it a line down may be clearer. Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] Patch Round-up for stable 1.5.1, freeze on 2013-06-19
Am 13.06.2013 14:44, schrieb Frederic Konrad: > On 12/06/2013 23:41, Michael Roth wrote: >> Hi everyone, >> >> The following new patches are queued for QEMU stable v1.5.1: >> >> https://github.com/mdroth/qemu/commits/stable-1.5-staging >> >> The release is planned for 2013-06-26: >> >> http://wiki.qemu.org/Planning/1.5 >> >> Please respond here or CC qemu-sta...@nongnu.org on any patches you >> think should be included in the release. The cut-off date is >> 2013-06-19 for new patches. >> >> Testing/feedback is greatly appreciated. > > And it seems you forget "virtio-rng: Fix crash with non-default backend". > You said you'll pick it up for 1.5.1 ;) It's not yet committed to master, so cannot be cherry-picked into the queue yet. Waiting for it myself. ;) Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[Qemu-devel] [PATCH v2] target-arm: add feature flag for ARMv8
Signed-off-by: Mans Rullgard
---
Make V8 imply ARM_DIV and LPAE.
---
target-arm/cpu.c | 7 ++-
target-arm/cpu.h | 1 +
target-arm/translate.c | 1 +
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/target-arm/cpu.c b/target-arm/cpu.c
index 496a59f..b75f396 100644
--- a/target-arm/cpu.c
+++ b/target-arm/cpu.c
@@ -162,6 +162,11 @@ static void arm_cpu_realizefn(DeviceState *dev, Error
**errp)
CPUARMState *env = &cpu->env;
/* Some features automatically imply others: */
+if (arm_feature(env, ARM_FEATURE_V8)) {
+set_feature(env, ARM_FEATURE_V7);
+set_feature(env, ARM_FEATURE_ARM_DIV);
+set_feature(env, ARM_FEATURE_LPAE);
+}
if (arm_feature(env, ARM_FEATURE_V7)) {
set_feature(env, ARM_FEATURE_VAPA);
set_feature(env, ARM_FEATURE_THUMB2);
@@ -748,7 +753,7 @@ static void pxa270c5_initfn(Object *obj)
static void arm_any_initfn(Object *obj)
{
ARMCPU *cpu = ARM_CPU(obj);
-set_feature(&cpu->env, ARM_FEATURE_V7);
+set_feature(&cpu->env, ARM_FEATURE_V8);
set_feature(&cpu->env, ARM_FEATURE_VFP4);
set_feature(&cpu->env, ARM_FEATURE_VFP_FP16);
set_feature(&cpu->env, ARM_FEATURE_NEON);
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index 5438444..b3be588 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -392,6 +392,7 @@ enum arm_features {
ARM_FEATURE_MPIDR, /* has cp15 MPIDR */
ARM_FEATURE_PXN, /* has Privileged Execute Never bit */
ARM_FEATURE_LPAE, /* has Large Physical Address Extension */
+ARM_FEATURE_V8,
};
static inline int arm_feature(CPUARMState *env, int feature)
diff --git a/target-arm/translate.c b/target-arm/translate.c
index b3f26d6..96ac5bc 100644
--- a/target-arm/translate.c
+++ b/target-arm/translate.c
@@ -42,6 +42,7 @@
#define ENABLE_ARCH_6K arm_feature(env, ARM_FEATURE_V6K)
#define ENABLE_ARCH_6T2 arm_feature(env, ARM_FEATURE_THUMB2)
#define ENABLE_ARCH_7 arm_feature(env, ARM_FEATURE_V7)
+#define ENABLE_ARCH_8 arm_feature(env, ARM_FEATURE_V8)
#define ARCH(x) do { if (!ENABLE_ARCH_##x) goto illegal_op; } while(0)
--
1.8.2.1
Re: [Qemu-devel] Patch Round-up for stable 1.5.1, freeze on 2013-06-19
On 13/06/2013 15:21, Andreas Färber wrote: Am 13.06.2013 14:44, schrieb Frederic Konrad: On 12/06/2013 23:41, Michael Roth wrote: Hi everyone, The following new patches are queued for QEMU stable v1.5.1: https://github.com/mdroth/qemu/commits/stable-1.5-staging The release is planned for 2013-06-26: http://wiki.qemu.org/Planning/1.5 Please respond here or CC qemu-sta...@nongnu.org on any patches you think should be included in the release. The cut-off date is 2013-06-19 for new patches. Testing/feedback is greatly appreciated. And it seems you forget "virtio-rng: Fix crash with non-default backend". You said you'll pick it up for 1.5.1 ;) It's not yet committed to master, so cannot be cherry-picked into the queue yet. Waiting for it myself. ;) Andreas Oh ok, so it need to be in master for being merged in stable? I didn't know that ;) Fred
Re: [Qemu-devel] [PATCH 3/3] target-arm: explicitly decode SEVL instruction
Andreas Färber writes: > Am 07.06.2013 14:06, schrieb Mans Rullgard: >> The ARMv8 SEVL instruction is in the architectural hint space already >> emulated as nop. This makes the decoding of SEVL explicit for clarity. >> >> Signed-off-by: Mans Rullgard >> --- >> target-arm/translate.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/target-arm/translate.c b/target-arm/translate.c >> index f529257..cfd148e 100644 >> --- a/target-arm/translate.c >> +++ b/target-arm/translate.c >> @@ -3501,6 +3501,7 @@ static void gen_nop_hint(DisasContext *s, int val) >> break; >> case 2: /* wfe */ >> case 4: /* sev */ >> +case 5: /* sevl */ >> /* TODO: Implement SEV and WFE. May help SMP performance. */ >> default: /* nop */ >> break; > > So does SEVL need to be implemented? Then the TODO should be updated. > Otherwise moving it a line down may be clearer. It needs to be implemented when/if SEV and WFE are. -- Måns Rullgård m...@mansr.com
Re: [Qemu-devel] [Xen-devel] [BUG 1747]Guest could't find bootable device with memory more than 3600M
On Wed, 12 Jun 2013, George Dunlap wrote: > On 12/06/13 08:25, Jan Beulich wrote: > > > > > On 11.06.13 at 19:26, Stefano Stabellini > > > > > wrote: > > > I went through the code that maps the PCI MMIO regions in hvmloader > > > (tools/firmware/hvmloader/pci.c:pci_setup) and it looks like it already > > > maps the PCI region to high memory if the PCI bar is 64-bit and the MMIO > > > region is larger than 512MB. > > > > > > Maybe we could just relax this condition and map the device memory to > > > high memory no matter the size of the MMIO region if the PCI bar is > > > 64-bit? > > I can only recommend not to: For one, guests not using PAE or > > PSE-36 can't map such space at all (and older OSes may not > > properly deal with 64-bit BARs at all). And then one would generally > > expect this allocation to be done top down (to minimize risk of > > running into RAM), and doing so is going to present further risks of > > incompatibilities with guest OSes (Linux for example learned only in > > 2.6.36 that PFNs in ioremap() can exceed 32 bits, but even in > > 3.10-rc5 ioremap_pte_range(), while using "u64 pfn", passes the > > PFN to pfn_pte(), the respective parameter of which is > > "unsigned long"). > > > > I think this ought to be done in an iterative process - if all MMIO > > regions together don't fit below 4G, the biggest one should be > > moved up beyond 4G first, followed by the next to biggest one > > etc. > > First of all, the proposal to move the PCI BAR up to the 64-bit range is a > temporary work-around. It should only be done if a device doesn't fit in the > current MMIO range. > > We have three options here: > 1. Don't do anything > 2. Have hvmloader move PCI devices up to the 64-bit MMIO hole if they don't > fit > 3. Convince qemu to allow MMIO regions to mask memory (or what it thinks is > memory). > 4. Add a mechanism to tell qemu that memory is being relocated. > > Number 4 is definitely the right answer long-term, but we just don't have time > to do that before the 4.3 release. We're not sure yet if #3 is possible; even > if it is, it may have unpredictable knock-on effects. > > Doing #2, it is true that many guests will be unable to access the device > because of 32-bit limitations. However, in #1, *no* guests will be able to > access the device. At least in #2, *many* guests will be able to do so. In > any case, apparently #2 is what KVM does, so having the limitation on guests > is not without precedent. It's also likely to be a somewhat tested > configuration (unlike #3, for example). I would avoid #3, because I don't think is a good idea to rely on that behaviour. I would also avoid #4, because having seen QEMU's code, it's wouldn't be easy and certainly not doable in time for 4.3. So we are left to play with the PCI MMIO region size and location in hvmloader. I agree with Jan that we shouldn't relocate unconditionally all the devices to the region above 4G. I meant to say that we should relocate only the ones that don't fit. And we shouldn't try to dynamically increase the PCI hole below 4G because clearly that doesn't work. However we could still increase the size of the PCI hole below 4G by default from start at 0xf000 to starting at 0xe000. Why do we know that is safe? Because in the current configuration hvmloader *already* increases the PCI hole size by decreasing the start address every time a device doesn't fit. So it's already common for hvmloader to set pci_mem_start to 0xe000, you just need to assign a device with a PCI hole size big enough. My proposed solution is: - set 0xe000 as the default PCI hole start for everybody, including qemu-xen-traditional - move above 4G everything that doesn't fit and support 64-bit bars - print an error if the device doesn't fit and doesn't support 64-bit bars
Re: [Qemu-devel] Patch Round-up for stable 1.5.1, freeze on 2013-06-19
On Thu, Jun 13, 2013 at 02:36:20PM +0200, Andreas Färber wrote: > Am 13.06.2013 14:27, schrieb Paolo Bonzini: > > Il 12/06/2013 17:41, Michael Roth ha scritto: > >> Hi everyone, > >> > >> The following new patches are queued for QEMU stable v1.5.1: > >> > >> https://github.com/mdroth/qemu/commits/stable-1.5-staging > >> > >> The release is planned for 2013-06-26: > >> > >> http://wiki.qemu.org/Planning/1.5 > >> > >> Please respond here or CC qemu-sta...@nongnu.org on any patches you > >> think should be included in the release. The cut-off date is > >> 2013-06-19 for new patches. > > > > I'm going to send pull requests for SCSI and NBD on Monday, both of them > > will include 1.5.1 patches. Thanks! > > Ditto for my in-flight qom-cpu pull. > > BTW v1.4.2 was still missing in qemu.git yesterday, is there a pull > pending already? Hmm, yah, it's pushed/tagging in the 1.4 repo: http://git.qemu.org/?p=qemu-stable-1.4.git;a=commit;h=89400a80f5827ae3696e3da73df0996154965a0a Anthony, do you still need to pull 1.4.2 into qemu.git? > > Andreas > > -- > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg >
Re: [Qemu-devel] [Qemu-ppc] [PATCH] target-ppc: Change default machine for 64-bit
On 17.05.2013, at 09:42, Andreas Färber wrote: > Am 17.05.2013 06:25, schrieb David Gibson: >> Currently, for qemu-system-ppc64, the default machine type is 'mac99'. >> Since the mac99 machine is not being actively maintained, and shows quite >> a few signs of bitrot, > > Please be more specific than making such general claims in a commit > message! As the default machine it certainly compiles, so where are you > seeing bitrot? The DEC bridge cleanup that I once started kind of > depends on the PCI cleanup you recently looked into. The mac99 machine for 64bit is actually worse than anything bitrot could give you. It emulates a machine that in its form never possibly could have existed in real hardware, which makes it very fragile and dependent on the guest's mercy to handle this gracefully. Given the current state and amount of development on the pseries target, I think it makes sense to declare that as the default for qemu-system-ppc64. I would still love to see -M mac99 emulate a proper U2 or U1 based system for 32bit. And I would also love to see a real U4 based emulation model come up for qemu-system-ppc64. But I doubt I'll have time to work on either :). Alex
Re: [Qemu-devel] [Xen-devel] [BUG 1747]Guest could't find bootable device with memory more than 3600M
On 13/06/13 14:44, Stefano Stabellini wrote: On Wed, 12 Jun 2013, George Dunlap wrote: On 12/06/13 08:25, Jan Beulich wrote: On 11.06.13 at 19:26, Stefano Stabellini wrote: I went through the code that maps the PCI MMIO regions in hvmloader (tools/firmware/hvmloader/pci.c:pci_setup) and it looks like it already maps the PCI region to high memory if the PCI bar is 64-bit and the MMIO region is larger than 512MB. Maybe we could just relax this condition and map the device memory to high memory no matter the size of the MMIO region if the PCI bar is 64-bit? I can only recommend not to: For one, guests not using PAE or PSE-36 can't map such space at all (and older OSes may not properly deal with 64-bit BARs at all). And then one would generally expect this allocation to be done top down (to minimize risk of running into RAM), and doing so is going to present further risks of incompatibilities with guest OSes (Linux for example learned only in 2.6.36 that PFNs in ioremap() can exceed 32 bits, but even in 3.10-rc5 ioremap_pte_range(), while using "u64 pfn", passes the PFN to pfn_pte(), the respective parameter of which is "unsigned long"). I think this ought to be done in an iterative process - if all MMIO regions together don't fit below 4G, the biggest one should be moved up beyond 4G first, followed by the next to biggest one etc. First of all, the proposal to move the PCI BAR up to the 64-bit range is a temporary work-around. It should only be done if a device doesn't fit in the current MMIO range. We have three options here: 1. Don't do anything 2. Have hvmloader move PCI devices up to the 64-bit MMIO hole if they don't fit 3. Convince qemu to allow MMIO regions to mask memory (or what it thinks is memory). 4. Add a mechanism to tell qemu that memory is being relocated. Number 4 is definitely the right answer long-term, but we just don't have time to do that before the 4.3 release. We're not sure yet if #3 is possible; even if it is, it may have unpredictable knock-on effects. Doing #2, it is true that many guests will be unable to access the device because of 32-bit limitations. However, in #1, *no* guests will be able to access the device. At least in #2, *many* guests will be able to do so. In any case, apparently #2 is what KVM does, so having the limitation on guests is not without precedent. It's also likely to be a somewhat tested configuration (unlike #3, for example). I would avoid #3, because I don't think is a good idea to rely on that behaviour. I would also avoid #4, because having seen QEMU's code, it's wouldn't be easy and certainly not doable in time for 4.3. So we are left to play with the PCI MMIO region size and location in hvmloader. I agree with Jan that we shouldn't relocate unconditionally all the devices to the region above 4G. I meant to say that we should relocate only the ones that don't fit. And we shouldn't try to dynamically increase the PCI hole below 4G because clearly that doesn't work. However we could still increase the size of the PCI hole below 4G by default from start at 0xf000 to starting at 0xe000. Why do we know that is safe? Because in the current configuration hvmloader *already* increases the PCI hole size by decreasing the start address every time a device doesn't fit. So it's already common for hvmloader to set pci_mem_start to 0xe000, you just need to assign a device with a PCI hole size big enough. My proposed solution is: - set 0xe000 as the default PCI hole start for everybody, including qemu-xen-traditional - move above 4G everything that doesn't fit and support 64-bit bars - print an error if the device doesn't fit and doesn't support 64-bit bars Also, as I understand it, at the moment: 1. Some operating systems (32-bit XP) won't be able to use relocated devices 2. Some devices (without 64-bit BARs) can't be relocated 3. qemu-traditional is fine with a resized <4GiB MMIO hole. So if we have #1 or #2, at the moment an option for a work-around is to use qemu-traditional. However, if we add your "print an error if the device doesn't fit", then this option will go away -- this will be a regression in functionality from 4.2. I thought that what we had proposed was to have an option in xenstore, that libxl would set, which would instruct hvmloader whether to expand the MMIO hole and whether to relocate devices above 64-bit? -George
Re: [Qemu-devel] [PATCH 2/3] target-arm: implement LDA/STL instructions
On 7 June 2013 13:06, Mans Rullgard wrote:
> This adds support for the ARMv8 load acquire/store release instructions.
> Since qemu does nothing special for memory barriers, these can be
> emulated like their non-acquire/release counterparts.
A brief comment to this effect in the appropriate parts of the
code as well as the commit message would be good.
>
> Signed-off-by: Mans Rullgard
> ---
> target-arm/translate.c | 91
> ++
> 1 file changed, 85 insertions(+), 6 deletions(-)
>
> diff --git a/target-arm/translate.c b/target-arm/translate.c
> index 96ac5bc..f529257 100644
> --- a/target-arm/translate.c
> +++ b/target-arm/translate.c
> @@ -7274,14 +7274,54 @@ static void disas_arm_insn(CPUARMState * env,
> DisasContext *s)
> rd = (insn >> 12) & 0xf;
> if (insn & (1 << 23)) {
> /* load/store exclusive */
> +int excl = (insn >> 9) & 1;
> op1 = (insn >> 21) & 0x3;
> -if (op1)
> +if (!excl)
> +ARCH(8);
> +else if (op1)
> ARCH(6K);
> else
> ARCH(6);
This if statement needs braces on all its arms. (QEMU coding
style mandates braces, though some existing code is not in
line with this; our general policy is that where patches touch
such existing code they update it accordingly.)
You can use scripts/checkpatch.pl to check for this.
This is also continuing to underdecode this space: some
of the new exclusive insns are ARCH(8) only but will be
allowed on ARCH(6) or 6K by this check. I know we've historically
underdecoded, but if we're touching this bit of the decoder
I'd prefer it if we tightened it up in the process.
> addr = tcg_temp_local_new_i32();
> load_reg_var(s, addr, rn);
> -if (insn & (1 << 20)) {
> +if (!excl) {
> +if (op1 == 1)
> +goto illegal_op;
This check needs to happen earlier to avoid leaking a tcg temp.
> +tmp = tcg_temp_new_i32();
> +if (insn & (1 << 20)) {
> +switch (op1) {
> +case 0: /* lda */
> +tcg_gen_qemu_ld32u(tmp, addr,
> IS_USER(s));
> +break;
> +case 2: /* ldab */
> +tcg_gen_qemu_ld8u(tmp, addr, IS_USER(s));
> +break;
> +case 3: /* ldah */
> +tcg_gen_qemu_ld16u(tmp, addr,
> IS_USER(s));
> +break;
> +default:
> +abort();
> +}
> +store_reg(s, rd, tmp);
> +} else {
> +rm = insn & 0xf;
> +tmp = load_reg(s, rm);
> +switch (op1) {
> +case 0: /* stl */
> +tcg_gen_qemu_st32(tmp, addr, IS_USER(s));
> +break;
> +case 2: /* stlb */
> +tcg_gen_qemu_st8(tmp, addr, IS_USER(s));
> +break;
> +case 3: /* stlh */
> +tcg_gen_qemu_st16(tmp, addr, IS_USER(s));
> +break;
> +default:
> +abort();
> +}
> +tcg_temp_free_i32(tmp);
> +}
> +} else if (insn & (1 << 20)) {
> switch (op1) {
> case 0: /* ldrex */
> gen_load_exclusive(s, rd, 15, addr, 2);
> @@ -8126,7 +8166,7 @@ static int disas_thumb2_insn(CPUARMState *env,
> DisasContext *s, uint16_t insn_hw
> gen_store_exclusive(s, rd, rs, 15, addr, 2);
> }
> tcg_temp_free_i32(addr);
> -} else if ((insn & (1 << 6)) == 0) {
> +} else if ((insn & (3 << 6)) == 0) {
While we're fiddling with the decode here let's actually narrow
it down completely, by making this condition
((insn & (7 << 5)) == 0)
...
> /* Table Branch. */
> if (rn == 15) {
> addr = tcg_temp_new_i32();
> @@ -8153,14 +8193,53 @@ static int
Re: [Qemu-devel] [PATCH v2] target-arm: add feature flag for ARMv8
On 13 June 2013 14:25, Mans Rullgard wrote: > Signed-off-by: Mans Rullgard > --- > Make V8 imply ARM_DIV and LPAE. Reviewed-by: Peter Maydell -- PMM
Re: [Qemu-devel] Patch Round-up for stable 1.5.1, freeze on 2013-06-19
On Thu, Jun 13, 2013 at 03:29:46PM +0200, Frederic Konrad wrote: > On 13/06/2013 15:21, Andreas Färber wrote: > >Am 13.06.2013 14:44, schrieb Frederic Konrad: > >>On 12/06/2013 23:41, Michael Roth wrote: > >>>Hi everyone, > >>> > >>>The following new patches are queued for QEMU stable v1.5.1: > >>> > >>>https://github.com/mdroth/qemu/commits/stable-1.5-staging > >>> > >>>The release is planned for 2013-06-26: > >>> > >>>http://wiki.qemu.org/Planning/1.5 > >>> > >>>Please respond here or CC qemu-sta...@nongnu.org on any patches you > >>>think should be included in the release. The cut-off date is > >>>2013-06-19 for new patches. > >>> > >>>Testing/feedback is greatly appreciated. > >>And it seems you forget "virtio-rng: Fix crash with non-default backend". > >>You said you'll pick it up for 1.5.1 ;) > >It's not yet committed to master, so cannot be cherry-picked into the > >queue yet. Waiting for it myself. ;) > > > >Andreas > > > Oh ok, so it need to be in master for being merged in stable? Yes. There are exceptions in rare cases (such as preventing WW3), but for the most part we need patches to get the full scrutiny of going through upstream review process before we pull them into a stable branch. Same reason why: "virtio-scsi: forward scsibus for virtio-scsi-pci" isn't in yet. If you're targeting a patch for a stable release and think it may not make it upstream in time consider pinging the respective maintainers if it's had enough time for review. > > I didn't know that ;) > > Fred >
Re: [Qemu-devel] [PATCH v2 0/7] target-arm: cpregs list for migration, kvm reset
On 3 June 2013 14:47, Peter Maydell wrote: > This patch series overhauls how we handle ARM coprocessor registers, > so that we use a consistent approach for migration, reset and > QEMU<->KVM synchronisation, driven by the kernel's list of supported > registers. Applied to target-arm.next. (If these were on somebody's to-review list, yell and I'll unapply them; but these plus v1 have been on list for a fair while without attracting any particular interest.) thanks -- PMM
Re: [Qemu-devel] [RFC] sanitize memory on system reset
On 13.06.2013 12:55, Markus Armbruster wrote: Peter Lieven writes: On 13.06.2013 10:40, Stefan Hajnoczi wrote: On Thu, Jun 13, 2013 at 08:09:09AM +0200, Peter Lieven wrote: I was thinking if it would be a good idea to zeroize all memory resources on system reset and madvise dontneed them afterwards. This would avoid system reset attacks in case the attacker has only access to the console of a vServer but not on the physical host and it would shrink RSS size of the vServer siginificantly. I wonder if you'll hit weird OS installers or PXE clients that rely on stashing stuff in memory across reset. One point: Wouldn't a memory test which some systems do at startup break these as well? Systems that distinguish between warm and cold boot (such as PCs) generally run POST only on cold boot. I'm not saying triggering warm reboot and expecting memory contents to survive is a good idea, but it has been done. so you would vote for not touching it or at least enable it only through a cmdline paramter? Peter
[Qemu-devel] [PATCH RFC 2/3] acpi: add tables as ROM so they are migrated
As we are going to very likely change ACPI tables across QEMU versions,
cross-verion migration will be a pain.
Register the tables as a ROM: this way they are migrated, same as BIOS
code.
Since size is going to likely change, too, round it up to a multiple of
1MByte to avoid too much churn there.
Signed-off-by: Michael S. Tsirkin
---
hw/i386/acpi-build.c | 37 +
1 file changed, 33 insertions(+), 4 deletions(-)
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 43e4988..911c913 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -35,6 +35,7 @@
#include "hw/nvram/fw_cfg.h"
#include "hw/i386/bios-linker-loader.h"
#include "hw/pci/pci_bus.h"
+#include "hw/loader.h"
#define ACPI_BUILD_APPNAME "Bochs"
#define ACPI_BUILD_APPNAME6 "BOCHS "
@@ -933,6 +934,28 @@ build_rsdp(GArray *linker, unsigned rsdt)
return rsdp_table;
}
+static void acpi_add_rom_blob(PcGuestInfo *guest_info, GArray *blob,
+ const char *name, unsigned align)
+{
+MemoryRegion *mr = g_malloc(sizeof(*mr));
+
+/* Align size to multiple of given size. This reduces the chance
+ * we need to change size in the future (breaking cross version migration).
+ */
+g_array_set_size(blob, (ROUND_UP(acpi_data_len(blob), align) +
+g_array_get_element_size(blob) - 1) /
+ g_array_get_element_size(blob));
+memory_region_init_ram_ptr(mr, "etc/blob-script",
+ acpi_data_len(blob), blob->data);
+memory_region_set_readonly(mr, true);
+vmstate_register_ram_global(mr);
+rom_add_blob(ACPI_BUILD_TABLE_FILE, blob->data, acpi_data_len(blob),
+ -1, mr);
+
+fw_cfg_add_file(guest_info->fw_cfg, name,
+blob->data, acpi_data_len(blob));
+}
+
#define ACPI_MAX_ACPI_TABLES 20
void acpi_setup(PcGuestInfo *guest_info)
{
@@ -993,12 +1016,18 @@ void acpi_setup(PcGuestInfo *guest_info)
rsdp = build_rsdp(linker, rsdt);
/* Now expose it all to Guest */
-fw_cfg_add_file(guest_info->fw_cfg, ACPI_BUILD_TABLE_FILE,
-table_data->data, table_data->len);
+acpi_add_rom_blob(guest_info, table_data,
+ ACPI_BUILD_TABLE_FILE, 1 << 20);
+
+acpi_add_rom_blob(guest_info, linker,
+ "etc/linker-script", TARGET_PAGE_SIZE);
+
+/*
+ * RSDP is small so it's easy to keep it immutable, no need to
+ * bother with ROM blobs.
+ */
fw_cfg_add_file(guest_info->fw_cfg, ACPI_BUILD_RSDP_FILE,
rsdp->data, acpi_data_len(rsdp));
-fw_cfg_add_file(guest_info->fw_cfg, "etc/linker-script",
-linker->data, acpi_data_len(linker));
/* Cleanup GArray wrappers and memory if no longer used. */
bios_linker_cleanup(linker);
--
MST
[Qemu-devel] [PATCH RFC 3/3] acpi-build: disable acpi generation for compat
When running with -M 1.5 and older, disable ACPI
table generation, and don't expose ACPI
tables to guest.
Signed-off-by: Michael S. Tsirkin
---
hw/i386/acpi-build.c | 4
hw/i386/pc_piix.c| 12 ++--
hw/i386/pc_q35.c | 12 ++--
include/hw/i386/pc.h | 1 +
4 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 911c913..7e52457 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -966,6 +966,10 @@ void acpi_setup(PcGuestInfo *guest_info)
ACPI_BUILD_DPRINTF(3, "No fw cfg. Boiling out.\n");
}
+if (!guest_info->has_acpi_build) {
+ACPI_BUILD_DPRINTF(3, "ACPI build disabled. Boiling out.\n");
+}
+
table_data = g_array_new(false, true /* clear */, 1);
table_offsets = g_array_new(false, true /* clear */,
sizeof(uint32_t));
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index e46f19a..eb11456 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -59,6 +59,7 @@ static const int ide_iobase2[MAX_IDE_BUS] = { 0x3f6, 0x376 };
static const int ide_irq[MAX_IDE_BUS] = { 14, 15 };
static bool has_pvpanic = true;
+static bool has_acpi_build = true;
/* PC hardware initialisation */
static void pc_init1(MemoryRegion *system_memory,
@@ -124,6 +125,7 @@ static void pc_init1(MemoryRegion *system_memory,
guest_info = pc_guest_info_init(below_4g_mem_size, above_4g_mem_size);
+guest_info->has_acpi_build = has_acpi_build;
guest_info->dsdt_code = AcpiDsdtAmlCode;
guest_info->dsdt_size = sizeof AcpiDsdtAmlCode;
@@ -266,12 +268,18 @@ static void pc_init_pci(QEMUMachineInitArgs *args)
initrd_filename, cpu_model, 1, 1);
}
+static void pc_init_pci_1_5(QEMUMachineInitArgs *args)
+{
+has_acpi_build = false;
+pc_init_pci(args);
+}
+
static void pc_init_pci_1_4(QEMUMachineInitArgs *args)
{
pc_sysfw_flash_vs_rom_bug_compatible = true;
has_pvpanic = false;
x86_cpu_compat_set_features("n270", FEAT_1_ECX, 0, CPUID_EXT_MOVBE);
-pc_init_pci(args);
+pc_init_pci_1_5(args);
}
static void pc_init_pci_1_3(QEMUMachineInitArgs *args)
@@ -365,7 +373,7 @@ static QEMUMachine pc_i440fx_machine_v1_6 = {
static QEMUMachine pc_i440fx_machine_v1_5 = {
.name = "pc-i440fx-1.5",
.desc = "Standard PC (i440FX + PIIX, 1996)",
-.init = pc_init_pci,
+.init = pc_init_pci_1_5,
.hot_add_cpu = pc_hot_add_cpu,
.max_cpus = 255,
.compat_props = (GlobalProperty[]) {
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index c8a..e101112 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -49,6 +49,7 @@
#define MAX_SATA_PORTS 6
static bool has_pvpanic = true;
+static bool has_acpi_build = true;
/* PC hardware initialisation */
static void pc_q35_init(QEMUMachineInitArgs *args)
@@ -109,6 +110,7 @@ static void pc_q35_init(QEMUMachineInitArgs *args)
}
guest_info = pc_guest_info_init(below_4g_mem_size, above_4g_mem_size);
+guest_info->has_acpi_build = has_acpi_build;
guest_info->dsdt_code = Q35AcpiDsdtAmlCode;
guest_info->dsdt_size = sizeof Q35AcpiDsdtAmlCode;
@@ -216,12 +218,18 @@ static void pc_q35_init(QEMUMachineInitArgs *args)
}
}
+static void pc_q35_init_1_5(QEMUMachineInitArgs *args)
+{
+has_acpi_build = false;
+pc_q35_init(args);
+}
+
static void pc_q35_init_1_4(QEMUMachineInitArgs *args)
{
pc_sysfw_flash_vs_rom_bug_compatible = true;
has_pvpanic = false;
x86_cpu_compat_set_features("n270", FEAT_1_ECX, 0, CPUID_EXT_MOVBE);
-pc_q35_init(args);
+pc_q35_init_1_5(args);
}
static QEMUMachine pc_q35_machine_v1_6 = {
@@ -237,7 +245,7 @@ static QEMUMachine pc_q35_machine_v1_6 = {
static QEMUMachine pc_q35_machine_v1_5 = {
.name = "pc-q35-1.5",
.desc = "Standard PC (Q35 + ICH9, 2009)",
-.init = pc_q35_init,
+.init = pc_q35_init_1_5,
.hot_add_cpu = pc_hot_add_cpu,
.max_cpus = 255,
.compat_props = (GlobalProperty[]) {
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 80c9e71..722d7d0 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -51,6 +51,7 @@ struct PcGuestInfo {
uint64_t mcfg_base;
const unsigned char *dsdt_code;
unsigned dsdt_size;
+bool has_acpi_build;
FWCfgState *fw_cfg;
};
--
MST
[Qemu-devel] [PATCH RFC 1/3] loader: support for unmapped ROM blobs
Support ROM blobs not mapped into guest memory:
let user pass in MR for memory serving as the backing store.
Signed-off-by: Michael S. Tsirkin
---
hw/core/loader.c | 32 +---
hw/lm32/lm32_hwsetup.h | 2 +-
include/hw/loader.h| 4 ++--
3 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/hw/core/loader.c b/hw/core/loader.c
index a711145..ac62454 100644
--- a/hw/core/loader.c
+++ b/hw/core/loader.c
@@ -542,6 +542,7 @@ struct Rom {
size_t datasize;
uint8_t *data;
+MemoryRegion *mr;
int isrom;
char *fw_dir;
char *fw_file;
@@ -641,7 +642,7 @@ err:
}
int rom_add_blob(const char *name, const void *blob, size_t len,
- hwaddr addr)
+ hwaddr addr, MemoryRegion *mr)
{
Rom *rom;
@@ -651,6 +652,11 @@ int rom_add_blob(const char *name, const void *blob,
size_t len,
rom->romsize = len;
rom->datasize = len;
rom->data = g_malloc0(rom->datasize);
+rom->mr = mr;
+if (mr) {
+assert(memory_region_is_ram(mr));
+rom->isrom = memory_region_is_rom(mr);
+}
memcpy(rom->data, blob, len);
rom_insert(rom);
return 0;
@@ -697,7 +703,12 @@ static void rom_reset(void *unused)
if (rom->data == NULL) {
continue;
}
-cpu_physical_memory_write_rom(rom->addr, rom->data, rom->datasize);
+if (rom->mr) {
+void *host = memory_region_get_ram_ptr(rom->mr);
+memcpy(host, rom->data, rom->datasize);
+} else {
+cpu_physical_memory_write_rom(rom->addr, rom->data, rom->datasize);
+}
if (rom->isrom) {
/* rom needs to be written only once */
g_free(rom->data);
@@ -713,6 +724,9 @@ int rom_load_all(void)
Rom *rom;
QTAILQ_FOREACH(rom, &roms, next) {
+if (rom->mr) {
+continue;
+}
if (rom->fw_file) {
continue;
}
@@ -746,6 +760,9 @@ static Rom *find_rom(hwaddr addr)
if (rom->fw_file) {
continue;
}
+if (rom->mr) {
+continue;
+}
if (rom->addr > addr) {
continue;
}
@@ -773,6 +790,9 @@ int rom_copy(uint8_t *dest, hwaddr addr, size_t size)
if (rom->fw_file) {
continue;
}
+if (rom->mr) {
+continue;
+}
if (rom->addr + rom->romsize < addr) {
continue;
}
@@ -832,7 +852,13 @@ void do_info_roms(Monitor *mon, const QDict *qdict)
Rom *rom;
QTAILQ_FOREACH(rom, &roms, next) {
-if (!rom->fw_file) {
+if (rom->mr) {
+monitor_printf(mon, "%s"
+ " size=0x%06zx name=\"%s\"\n",
+ rom->mr->name,
+ rom->romsize,
+ rom->name);
+} else if (!rom->fw_file) {
monitor_printf(mon, "addr=" TARGET_FMT_plx
" size=0x%06zx mem=%s name=\"%s\"\n",
rom->addr, rom->romsize,
diff --git a/hw/lm32/lm32_hwsetup.h b/hw/lm32/lm32_hwsetup.h
index 3449bd8..d6914d6 100644
--- a/hw/lm32/lm32_hwsetup.h
+++ b/hw/lm32/lm32_hwsetup.h
@@ -73,7 +73,7 @@ static inline void hwsetup_free(HWSetup *hw)
static inline void hwsetup_create_rom(HWSetup *hw,
hwaddr base)
{
-rom_add_blob("hwsetup", hw->data, TARGET_PAGE_SIZE, base);
+rom_add_blob("hwsetup", hw->data, TARGET_PAGE_SIZE, base, NULL);
}
static inline void hwsetup_add_u8(HWSetup *hw, uint8_t u)
diff --git a/include/hw/loader.h b/include/hw/loader.h
index 15d4cc9..b39e7d1 100644
--- a/include/hw/loader.h
+++ b/include/hw/loader.h
@@ -27,7 +27,7 @@ void pstrcpy_targphys(const char *name,
int rom_add_file(const char *file, const char *fw_dir,
hwaddr addr, int32_t bootindex);
int rom_add_blob(const char *name, const void *blob, size_t len,
- hwaddr addr);
+ hwaddr addr, MemoryRegion *mr);
int rom_add_elf_program(const char *name, void *data, size_t datasize,
size_t romsize, hwaddr addr);
int rom_load_all(void);
@@ -39,7 +39,7 @@ void do_info_roms(Monitor *mon, const QDict *qdict);
#define rom_add_file_fixed(_f, _a, _i) \
rom_add_file(_f, NULL, _a, _i)
#define rom_add_blob_fixed(_f, _b, _l, _a) \
-rom_add_blob(_f, _b, _l, _a)
+rom_add_blob(_f, _b, _l, _a, NULL)
#define PC_ROM_MIN_VGA 0xc
#define PC_ROM_MIN_OPTION 0xc8000
--
MST
