Re: [Qemu-devel] [RFC][PATCH 0/21] QEMU Object Model
On 07/28/2011 07:59 PM, Anthony Liguori wrote: Just define an interface that returns a struct then. It's no more complicated than that. Ok, so we're debating whether to: 1) add an interface returning a pointer to an internal struct; 2) include in the internal struct a pointer-to-function that does a container_of and returns the outer Device object. Otherwise, we're on the same page. I'm quite relieved. ;) I can see advantages to both approach. The main advantage to (2) is that it scales better when you have multiple interfaces of the same kind exposed by the device. You cannot implement an interface twice. Paolo
Re: [Qemu-devel] [PATCH 18/55] scsi-disk: Reject CD-specific SCSI commands to disks
Markus Armbruster arm...@redhat.com writes: Christoph Hellwig h...@lst.de writes: On Wed, Jul 20, 2011 at 06:23:52PM +0200, Markus Armbruster wrote: Use a table to declare which drive kinds accept each command. Limit READ_CAPACITY, READ_TOC, GET_CONFIGURATION to SCSI_CD, as per SPC-4. READ CAPACITY is defined in SBC, and absolutely required for proper operation with disks. Will fix. Second thoughts: dropping this bug fix patch for now, because it clashes with Hannes's work in progress[*], and the rest of my series doesn't depend on it. [*] [PATCH 6/6] scsi-disk: Check for supported commands http://lists.gnu.org/archive/html/qemu-devel/2011-07/msg03082.html
Re: [Qemu-devel] Volume key in qcow3?
2011/7/28 Kevin Wolf kw...@redhat.com: Am 28.07.2011 10:05, schrieb Frediano Ziglio: Hi, I noted that AES encryption using qcow2 just use the password given as as key (and also truncating it to 16 bytes == 128 bits). This is prone to brute force attacks and is not also easy to change password (you have to decrypt and encrypt again the entire image). LUKS and EncFS use another way. They generate a random key (the volume key) then use the password you give to encrypt N times (where N is decided by security level or automatically based on time to decrypt the volume key. To change the password just give the old one, get the volume key and encrypt again using the new one. LUKS support also multiple slots to allow multiple password and even using an external key file. Obviously this require an additional extension to qcow2 so I think it require a new qcow3 format. Yes, once we have qcow3, adding things like this should be easy enough. I think the idea makes sense. Another thing to consider with encryption is that we don't encrypt metadata currently. I'm not entirely sure if this is a good or a bad thing. Metadata is relatively predictable and I think that might hurt the encryption? Though I'm really not an expert in this area. Kevin I don't think this is a big issue, usually sensitive data is not in knowing which clusters are allocated or in which sequence (perhaps looking at allocation strategy you can detect operating system and filesystem type), snapshot ids and descriptions are IMO more sensible. Do anybody though that qcow2 can support data-deduplication using refcounts? Well, in this case this is not possible with encrypted data. Frediano
Re: [Qemu-devel] Odd code in cpus.c
On 2011-07-29 10:34, Frediano Ziglio wrote:
I don't know that much this code however qemu_kvm_init_cpu_signals
seems a bit strange and duplicate to me, in cpus.c
static void qemu_kvm_init_cpu_signals(CPUState *env)
{
int r;
sigset_t set;
struct sigaction sigact;
memset(sigact, 0, sizeof(sigact));
sigact.sa_handler = dummy_signal;
sigaction(SIG_IPI, sigact, NULL);
#ifdef CONFIG_IOTHREAD
pthread_sigmask(SIG_BLOCK, NULL, set);
sigdelset(set, SIG_IPI);
sigdelset(set, SIGBUS);
r = kvm_set_signal_mask(env, set);
if (r) {
fprintf(stderr, kvm_set_signal_mask: %s\n, strerror(-r));
exit(1);
}
#else
sigemptyset(set);
sigaddset(set, SIG_IPI);
sigaddset(set, SIGIO);
sigaddset(set, SIGALRM);
pthread_sigmask(SIG_BLOCK, set, NULL);
pthread_sigmask(SIG_BLOCK, NULL, set);
sigdelset(set, SIGIO);
sigdelset(set, SIGALRM);
#endif
sigdelset(set, SIG_IPI);
sigdelset(set, SIGBUS);
r = kvm_set_signal_mask(env, set);
if (r) {
fprintf(stderr, kvm_set_signal_mask: %s\n, strerror(-r));
exit(1);
}
}
if CONFIG_IOTHREAD is set you get
static void qemu_kvm_init_cpu_signals(CPUState *env)
{
int r;
sigset_t set;
struct sigaction sigact;
memset(sigact, 0, sizeof(sigact));
sigact.sa_handler = dummy_signal;
sigaction(SIG_IPI, sigact, NULL);
pthread_sigmask(SIG_BLOCK, NULL, set);
sigdelset(set, SIG_IPI);
sigdelset(set, SIGBUS);
r = kvm_set_signal_mask(env, set);
if (r) {
fprintf(stderr, kvm_set_signal_mask: %s\n, strerror(-r));
exit(1);
}
sigdelset(set, SIG_IPI);
sigdelset(set, SIGBUS);
r = kvm_set_signal_mask(env, set);
if (r) {
fprintf(stderr, kvm_set_signal_mask: %s\n, strerror(-r));
exit(1);
}
}
which seems to set kvm signal twice with same values (taking into
account that in kvm_set_signal_mask the set is copied before the call
to kvm_vcpu_ioctl).
Indeed. Harmless fortunately. I suspect the duplicate bits in the #ifdef
CONFIG_IOTHREAD block were simply forgotten. Paolo?
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
Re: [Qemu-devel] Odd code in cpus.c
On 07/29/2011 10:49 AM, Jan Kiszka wrote: which seems to set kvm signal twice with same values (taking into account that in kvm_set_signal_mask the set is copied before the call to kvm_vcpu_ioctl). Indeed. Harmless fortunately. I suspect the duplicate bits in the #ifdef CONFIG_IOTHREAD block were simply forgotten. Paolo? Yes, perhaps a rebase conflict was resolved erroneously. Can probably get in via qemu-trivial. Paolo
Re: [Qemu-devel] [PATCH 49/55] block: Declare qemu_blockalign() in block.h, not block_int.h
Christoph Hellwig h...@lst.de writes: On Wed, Jul 20, 2011 at 06:24:23PM +0200, Markus Armbruster wrote: Device models should be able to use it without an unclean include of block_int.h. Hmm. We already do proper read-modify-write cycles for actual data transfers, so killing the buffer inside SD sounds like the better idea. qemu_blockalign really should be used only for block-layer internal allocations. What about the uses in scsi-disk.c and ide/core.c?
Re: [Qemu-devel] Volume key in qcow3?
Am 29.07.2011 10:47, schrieb Frediano Ziglio: 2011/7/28 Kevin Wolf kw...@redhat.com: Am 28.07.2011 10:05, schrieb Frediano Ziglio: Hi, I noted that AES encryption using qcow2 just use the password given as as key (and also truncating it to 16 bytes == 128 bits). This is prone to brute force attacks and is not also easy to change password (you have to decrypt and encrypt again the entire image). LUKS and EncFS use another way. They generate a random key (the volume key) then use the password you give to encrypt N times (where N is decided by security level or automatically based on time to decrypt the volume key. To change the password just give the old one, get the volume key and encrypt again using the new one. LUKS support also multiple slots to allow multiple password and even using an external key file. Obviously this require an additional extension to qcow2 so I think it require a new qcow3 format. Yes, once we have qcow3, adding things like this should be easy enough. I think the idea makes sense. Another thing to consider with encryption is that we don't encrypt metadata currently. I'm not entirely sure if this is a good or a bad thing. Metadata is relatively predictable and I think that might hurt the encryption? Though I'm really not an expert in this area. Kevin I don't think this is a big issue, usually sensitive data is not in knowing which clusters are allocated or in which sequence (perhaps looking at allocation strategy you can detect operating system and filesystem type), snapshot ids and descriptions are IMO more sensible. Do anybody though that qcow2 can support data-deduplication using refcounts? Well, in this case this is not possible with encrypted data. No, you can't have two clusters in the active L1 table that are mapped to the same cluster in the image file. The reason for this is that you can't update the QCOW_OFLAG_COPIED flag when doing COW (you would have to scan all L2 tables, which just doesn't work performance-wise) If we were to do this, we would have to have a flag that turns off the usage of QCOW_OFLAG_COPIED (it is only a performance optimisation, so doing this would be possible). Not sure if it's worth it. Kevin
Re: [Qemu-devel] [PATCH 0/3] small trivial patches
On Wed, Jul 27, 2011 at 7:11 PM, Frediano Ziglio fredd...@gmail.com wrote: Minor fixes and improves Frediano Ziglio (3): block: removed unused function block: typo fix aio: always check paio_init result block.c | 13 - block.h | 2 -- block/raw-posix.c | 13 ++--- 3 files changed, 6 insertions(+), 22 deletions(-) Reviewed-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com Please send block patches to Kevin even if they are trivial. The trivial-patches tree tries to stay out of the way of subsystems with an active maintainer. Stefan
Re: [Qemu-devel] [PATCH] [RFC] qcow2: group refcount updates during cow
Am 28.07.2011 16:15, schrieb Kevin Wolf: Am 28.07.2011 15:50, schrieb Frediano Ziglio: Well, I think this is the first real improve patch. Is more a RFC than a patch. Yes, some lines are terrible! It collapses refcount decrement during cow. From a first check time executing 015 test passed from about 600 seconds to 70. This at least prove that refcount updates counts! Some doubt: 1- place the code in qcow2-refcount.c as it update only refcount and not cluster? 2- allow some sort of begin transaction / commit / rollback like databases instead? 3- allow changing tables from different coroutines? 1) If you have a sequence like (1, 2, 4) probably these clusters are all in the same l2 table but with this code you get two write instead of one. I'm thinking about a function in qcow2-refcount.c that accept an array of cluster instead of a start + len. Signed-off-by: Frediano Ziglio fredd...@gmail.com I think what you're seeing is actually just one special case of a more general problem. The problem is that we're interpreting writethrough stricter than required. The semantics that we really need is that on completion of a request, all of its data and metadata must be flushed to disk. There is no requirement that we flush all intermediate states. My recent update to qcow2_update_snapshot_refcount() is just another case of the same problem. I think the solution should be similar to what I did there, i.e. switch the cache to writeback mode while we're operating on it and switch back when we're done. We should probably have functions that make both of this a one-liner (I think here we have some similarity to your begin/commit idea). With the right functions, this could become as easy as this (might need better function names, but you get the idea): diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c index 882f50a..45b67b1 100644 --- a/block/qcow2-cluster.c +++ b/block/qcow2-cluster.c @@ -612,6 +612,8 @@ int qcow2_alloc_cluster_link_l2(BlockDriverState *bs, QCowL2Meta *m) if (m-nb_clusters == 0) return 0; +qcow2_cache_disable_writethrough(bs); + old_cluster = qemu_malloc(m-nb_clusters * sizeof(uint64_t)); /* copy content of unmodified sectors */ @@ -683,6 +685,7 @@ int qcow2_alloc_cluster_link_l2(BlockDriverState *bs, QCowL2Meta *m) ret = 0; err: +qcow2_cache_restore_writethrough(bs); qemu_free(old_cluster); return ret; } Maybe that's a bit too easy for a solution. With coroutines this requires running under a CoMutex in order to avoid influencing other requests and possibly missing a cache flush. This is contrary to our goal of running requests in parallel, so maybe some more changes to how the cache handles cache=writethrough are required. Kevin
Re: [Qemu-devel] [PATCH 2/2] Makefile: delete config.log in distclean
On Mon, Jul 25, 2011 at 11:56:02PM -0400, Alexandre Raymond wrote: Distclean should remove anything created by the configure script. Signed-off-by: Alexandre Raymond cerb...@gmail.com --- Makefile |1 + 1 files changed, 1 insertions(+), 0 deletions(-) Thanks, applied to the trivial patches tree: http://repo.or.cz/w/qemu/stefanha.git/shortlog/refs/heads/trivial-patches-next Stefan
[Qemu-devel] [Bug 802588] Re: Latest GIT version fails to compile on Linux - setjmp.h problem
this issue got fixed. It doesn't exist in qemu-kvm.git fda19064e889d4419dd3dc69ca8e6e7a1535fdf5 ** Changed in: qemu Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/802588 Title: Latest GIT version fails to compile on Linux - setjmp.h problem Status in QEMU: Fix Released Bug description: Git version: f26e428da505709ec03b2ed2c9eb3db82b30bd7b Gcc: 4.6.1 Host: Debinan/x86_64 Fails to compile at In file included from /usr/include/png.h:518:0, from ui/vnc-enc-tight.c:37: /usr/include/pngconf.h: At top level: /usr/include/pngconf.h:371:21: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘.’ token /usr/include/pngconf.h:372:12: error: unknown type name ‘__dont__’ /usr/include/pngconf.h:372:29: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘it’ /usr/include/pngconf.h:372:29: error: unknown type name ‘it’ Looking at pngconf.h around line 370 gives the reason for the compilation failure: # ifdef _SETJMP_H /* If you encounter a compiler error here, see the explanation * near the end of INSTALL. */ __pngconf.h__ in libpng already includes setjmp.h; __dont__ include it again.; # endif To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/802588/+subscriptions
Re: [Qemu-devel] [Qemu-trivial] [PATCH 1/2] Makefile: distclean should clean all possible targets
On 07/27/2011 04:42 PM, Michael Roth wrote: Delete all files in the current directory (or created by this makefile) that are created by configuring or building the program. If you have unpacked the source and built the program without creating any other files, ‘make distclean’ should leave only the files that were in the distribution. However, there is no need to delete parent directories that were created with ‘mkdir -p’, since they could have existed anyway. Now, if everyone agrees that distclean is fine as it is, I won't insist on anything. I'm with you in that distclean to me reads as make clean for re-distribution. i.e. a pristine source tree. It should be like that _as long as you rerun make distclean before every reconfiguration_. Paolo
Re: [Qemu-devel] Block layer roadmap
Frediano suggested: Enhanced volume key in qcow3 * luks-like key scheme that allows changing passphrase without re-encrypting image data
Re: [Qemu-devel] [PATCH -V2] coroutine: Add CoRwlock support
Am 27.07.2011 18:21, schrieb Aneesh Kumar K.V: Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com --- qemu-coroutine-lock.c | 44 qemu-coroutine.h | 12 2 files changed, 56 insertions(+), 0 deletions(-) Looks good to me. What's your plan with getting this merged? Are you going to just include it with another series that you'll send once the basic coroutine support is in? Kevin
Re: [Qemu-devel] Bug#632192: [PATCH] add QEMU_LD_PREFIX environment variable
On Thu, Jul 28, 2011 at 11:41:09AM +0300, Riku Voipio wrote: On Sat, Jul 23, 2011 at 07:47:49AM +0200, josch wrote: This could be avoided by setting the proposed environment variable QEMU_LD_PREFIX to the just created debian rootfs. As mentioned earlier, the usage of the -L option is not possible in this scenario because qemu-user is only implicitly called by the binfmt mechanism. What worries me here is that we are beginning to add a enviroment variable for each and every command line option of qemu linux-user. I think it would be better to have a wrapper binary to be registered as the binfmt runner. setting up a wrapper makes trivial cross-architecture chroots harder as you'll have to copy two binaries into the chroot, and i'm not sure if it would work at all, as the wrapper will need to somehow emulate it's own interpreter... Alternatively we should have a generic setup for mapping enviroment variables to command line options. Now we get special per-option code every time someone needs to setup a command line option from binfmt. this would seem a bit better alternative to me... live well, vagrant
Re: [Qemu-devel] [PATCH v8 0/5] Coroutines for better asynchronous programming
On Tue, Jul 26, 2011 at 10:21 AM, Stefan Hajnoczi stefa...@linux.vnet.ibm.com wrote: QEMU is event-driven and suffers when blocking operations are performed because VM execution may be stopped until the operation completes. Therefore many operations that could block are performed asynchronously and a callback is invoked when the operation has completed. This allows QEMU to continue executing while the operation is pending. The downside to callbacks is that they split up code into many smaller functions, each of which is a single step in a state machine that quickly becomes complex and hard to understand. Callback functions also result in lots of noise as variables are packed and unpacked into temporary structs that pass state to the callback function. This patch series introduces coroutines as a solution for writing asynchronous code while still having a nice sequential control flow. The semantics are explained in the second patch. The fourth patch adds automated tests. A nice feature of coroutines is that it is relatively easy to take synchronous code and lift it into a coroutine to make it asynchronous. Work has been done to move qcow2 request processing into coroutines and thereby make it asynchronous (today qcow2 will perform synchronous metadata accesses). This qcow2 work is still ongoing and not quite ready for mainline yet. v8: * Bisectability: introduce gthread implementation before ucontext/fibers Aneesh's code on top of this will go in separately. We're good to go. Stefan
Re: [Qemu-devel] [PATCH 2/2] pc: Support system flash memory with pflash
On 07/25/2011 04:34 PM, Jordan Justen wrote:
If a pflash image is found, then it is used for the system
firmware image.
If a pflash image is not initially found, then a read-only
pflash device is created using the -bios filename.
Signed-off-by: Jordan Justenjordan.l.jus...@intel.com
Cc: Anthony Liguorialigu...@us.ibm.com
Cc: Aurelien Jarnoaurel...@aurel32.net
---
Makefile.target|2 +-
default-configs/i386-softmmu.mak |1 +
default-configs/x86_64-softmmu.mak |1 +
hw/boards.h|1 +
hw/pc.c| 46 +
hw/pc.h|2 +
hw/pcflash.c | 130
vl.c |2 +-
8 files changed, 141 insertions(+), 44 deletions(-)
create mode 100644 hw/pcflash.c
diff --git a/Makefile.target b/Makefile.target
index cde509b..4d8821f 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -223,7 +223,7 @@ obj-$(CONFIG_IVSHMEM) += ivshmem.o
# Hardware support
obj-i386-y += vga.o
-obj-i386-y += mc146818rtc.o i8259.o pc.o
+obj-i386-y += mc146818rtc.o i8259.o pc.o pcflash.o
This should be able to live in hw-obj-y in Makefile.objs since it
doesn't depend on any TARGET_ defines or CPUState.
diff --git a/hw/pc.c b/hw/pc.c
index a3e8539..cf7257b 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -55,10 +55,6 @@
#define DPRINTF(fmt, ...)
#endif
-#define BIOS_FILENAME bios.bin
-
-#define PC_MAX_BIOS_SIZE (4 * 1024 * 1024)
-
/* Leave a chunk of memory at the top of RAM for the BIOS ACPI tables. */
#define ACPI_DATA_SIZE 0x1
#define BIOS_CFG_IOPORT 0x510
@@ -963,10 +959,8 @@ void pc_memory_init(const char *kernel_filename,
ram_addr_t below_4g_mem_size,
ram_addr_t above_4g_mem_size)
{
-char *filename;
-int ret, linux_boot, i;
-ram_addr_t ram_addr, bios_offset, option_rom_offset;
-int bios_size, isa_bios_size;
+int linux_boot, i;
+ram_addr_t ram_addr, option_rom_offset;
void *fw_cfg;
linux_boot = (kernel_filename != NULL);
@@ -983,44 +977,12 @@ void pc_memory_init(const char *kernel_filename,
ram_addr + below_4g_mem_size);
}
-/* BIOS load */
-if (bios_name == NULL)
-bios_name = BIOS_FILENAME;
-filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name);
-if (filename) {
-bios_size = get_image_size(filename);
-} else {
-bios_size = -1;
-}
-if (bios_size= 0 ||
-(bios_size % 65536) != 0) {
-goto bios_error;
-}
-bios_offset = qemu_ram_alloc(NULL, pc.bios, bios_size);
-ret = rom_add_file_fixed(bios_name, (uint32_t)(-bios_size), -1);
-if (ret != 0) {
-bios_error:
-fprintf(stderr, qemu: could not load PC BIOS '%s'\n, bios_name);
-exit(1);
-}
-if (filename) {
-qemu_free(filename);
-}
-/* map the last 128KB of the BIOS in ISA space */
-isa_bios_size = bios_size;
-if (isa_bios_size (128 * 1024))
-isa_bios_size = 128 * 1024;
-cpu_register_physical_memory(0x10 - isa_bios_size,
- isa_bios_size,
- (bios_offset + bios_size - isa_bios_size) |
IO_MEM_ROM);
+/* Initialize ROM or flash ranges for PC firmware */
+pc_system_firmware_init();
option_rom_offset = qemu_ram_alloc(NULL, pc.rom, PC_ROM_SIZE);
cpu_register_physical_memory(PC_ROM_MIN_VGA, PC_ROM_SIZE,
option_rom_offset);
-/* map all the bios at the top of memory */
-cpu_register_physical_memory((uint32_t)(-bios_size),
- bios_size, bios_offset | IO_MEM_ROM);
-
fw_cfg = bochs_bios_init();
rom_set_fw(fw_cfg);
diff --git a/hw/pc.h b/hw/pc.h
index 6d5730b..114816d 100644
--- a/hw/pc.h
+++ b/hw/pc.h
@@ -238,4 +238,6 @@ static inline bool isa_ne2000_init(int base, int irq,
NICInfo *nd)
int e820_add_entry(uint64_t, uint64_t, uint32_t);
+void pc_system_firmware_init(void);
+
#endif
diff --git a/hw/pcflash.c b/hw/pcflash.c
new file mode 100644
index 000..514b1ed
--- /dev/null
+++ b/hw/pcflash.c
@@ -0,0 +1,130 @@
+/*
+ * QEMU PC System Flash
+ *
+ * Copyright (c) 2003-2004 Fabrice Bellard
+ * Copyright (c) 2011 Intel Corporation
+ *
+ * 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
Re: [Qemu-devel] [RFC PATCH 1/4] add support for machine models to specify their migration format
On 06/30/2011 10:46 AM, Paolo Bonzini wrote:
We need to provide a new migration format, and not break migration
in old machine models. So add a migration_format field to QEMUMachine.
Signed-off-by: Paolo Bonzinipbonz...@redhat.com
---
cpu-common.h |3 ---
hw/boards.h |1 +
qemu-common.h |3 +++
savevm.c |7 +--
4 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/cpu-common.h b/cpu-common.h
index b027e43..8c06dbb 100644
--- a/cpu-common.h
+++ b/cpu-common.h
@@ -26,9 +26,6 @@ enum device_endian {
DEVICE_LITTLE_ENDIAN,
};
-/* address in the RAM (different from a physical address) */
-typedef unsigned long ram_addr_t;
-
/* memory API */
typedef void CPUWriteMemoryFunc(void *opaque, target_phys_addr_t addr,
uint32_t value);
diff --git a/hw/boards.h b/hw/boards.h
index 716fd7b..560dbaf 100644
--- a/hw/boards.h
+++ b/hw/boards.h
@@ -19,6 +19,7 @@ typedef struct QEMUMachine {
QEMUMachineInitFunc *init;
int use_scsi;
int max_cpus;
+unsigned migration_format;
unsigned int no_serial:1,
no_parallel:1,
use_virtcon:1,
diff --git a/qemu-common.h b/qemu-common.h
index 109498d..550fe2c 100644
--- a/qemu-common.h
+++ b/qemu-common.h
@@ -119,6 +119,9 @@ static inline char *realpath(const char *path, char
*resolved_path)
#define PRIo64 I64o
#endif
+/* address in the RAM (different from a physical address) */
+typedef unsigned long ram_addr_t;
+
/* FIXME: Remove NEED_CPU_H. */
#ifndef NEED_CPU_H
diff --git a/savevm.c b/savevm.c
index 8139bc7..74e6e99 100644
--- a/savevm.c
+++ b/savevm.c
@@ -72,6 +72,7 @@
#include qemu-common.h
#include hw/hw.h
#include hw/qdev.h
+#include hw/boards.h
#include net.h
#include monitor.h
#include sysemu.h
@@ -1474,7 +1475,7 @@ int qemu_savevm_state_begin(Monitor *mon, QEMUFile *f,
int blk_enable,
}
qemu_put_be32(f, QEMU_VM_FILE_MAGIC);
-qemu_put_be32(f, QEMU_VM_FILE_VERSION);
+qemu_put_be32(f, current_machine-migration_format ?:
QEMU_VM_FILE_VERSION);
Please avoid this gcc extension as it's relatively obscure. But in
addition, why would use you 0 as the new format instead of
QEMU_VM_FILE_VERSION + 1?
Regards,
Anthony Liguori
QTAILQ_FOREACH(se,savevm_handlers, entry) {
int len;
@@ -1747,8 +1748,10 @@ int qemu_loadvm_state(QEMUFile *f)
fprintf(stderr, SaveVM v2 format is obsolete and don't work
anymore\n);
return -ENOTSUP;
}
-if (v != QEMU_VM_FILE_VERSION)
+if (v != (current_machine-migration_format ?: QEMU_VM_FILE_VERSION)) {
+fprintf(stderr, Mismatching SaveVM format v%d\n, v);
return -ENOTSUP;
+}
while ((section_type = qemu_get_byte(f)) != QEMU_VM_EOF) {
uint32_t instance_id, version_id, section_id;
Re: [Qemu-devel] [PATCH 49/55] block: Declare qemu_blockalign() in block.h, not block_int.h
On Fri, Jul 29, 2011 at 10:56:07AM +0200, Markus Armbruster wrote: Hmm. We already do proper read-modify-write cycles for actual data transfers, so killing the buffer inside SD sounds like the better idea. qemu_blockalign really should be used only for block-layer internal allocations. What about the uses in scsi-disk.c and ide/core.c? They are allocating internal bounce buffers due to suboptimal I/O models. But given that this is the reality in multiple qemu drivers I think I'll give up and ack the move.
Re: [Qemu-devel] [RFC PATCH 3/4] savevm: define new unambiguous migration format
On 06/30/2011 10:46 AM, Paolo Bonzini wrote:
With the current migration format, VMS_STRUCTs with subsections
are ambiguous. The protocol cannot tell whether a 0x5 byte after
the VMS_STRUCT is a subsection or part of the parent data stream.
In the past QEMU assumed it was always a part of a subsection; after
commit eb60260 (savevm: fix corruption in vmstate_subsection_load().,
2011-02-03) the choice depends on whether the VMS_STRUCT has subsections
defined.
Unfortunately, this means that if a destination has no subsections
defined for the struct, it will happily read subsection data into
its own fields. And if you are lucky enough to stumble on a
zero byte at the right time, it will be interpreted as QEMU_VM_EOF
and migration will be interrupted.
There is no way out of this except defining an incompatible
migration protocol with a sentinel at the end of embedded structs.
Of course, this is restricted to new machine models.
Signed-off-by: Paolo Bonzinipbonz...@redhat.com
---
hw/pc_piix.c |6 ++
savevm.c | 27 +++
2 files changed, 25 insertions(+), 8 deletions(-)
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index 18cc942..d8d629c 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -271,6 +271,7 @@ static QEMUMachine pc_machine_v0_14 = {
.desc = Standard PC,
.init = pc_init_pci,
.max_cpus = 255,
+.migration_format = 3,
};
Please introduce a macro so this code is readable.
We have other machines that support migration in other archs too.
Regards,
Anthony Liguori
Re: [Qemu-devel] [RFC PATCH 0/4] Fix subsection ambiguity in the migration format
On 07/25/2011 04:10 PM, Paolo Bonzini wrote: On Thu, Jun 30, 2011 at 17:46, Paolo Bonzinipbonz...@redhat.com wrote: I have now tested this series (exactly as sent) both by examining manually the differences between the two formats on the same guest state, and by a mix of saves/restores (new on new, 0.14 on new pc-0.14, new pc-0.14 on 0.14; also the same combinations on RHEL). It always does what is expected. Michael Tsirkin objected that the format should be passed as a parameter in the migrate command. I kind of agree, however since this is a real bug you would need to bump the default for new machine types, and this default would still go in the QEMUMachine struct like I am doing. So I consider the two settings to be orthogonal. Also, the alternative requires changes to the whole management stack and if the default is not changed it imposes a broken format unless you update the management tools. Clearly much less bang for the buck. I think this is ready to go into 0.15. The bug happens when migrating to 0.14 a pc-0.14 machine created with QEMU 0.15 and which has a floppy. The media changed subsection is almost always included, and this causes problems when migrating to 0.14 which didn't have any subsection for the floppy device. While QEMU support for migration to old version admittedly depends on luck, this isn't true of certain downstreams :) which would like to have an unambiguous migration format. I really hate the idea of changing the migration format moments before the release. Since subsections are optional, can't we take the offending subsections, remove them, bump the section version numbers and make the fields required? That fixes this issue temporarily without changing the format and we can change the format for 1.0. Regards, Anthony Liguori Paolo
Re: [Qemu-devel] [PATCH 05/10] qcow2: Use coroutines
On Tue, Jul 26, 2011 at 12:49 PM, Kevin Wolf kw...@redhat.com wrote: Signed-off-by: Kevin Wolf kw...@redhat.com --- block/qcow2-cluster.c | 26 +++--- block/qcow2.c | 240 ++--- block/qcow2.h | 5 +- 3 files changed, 102 insertions(+), 169 deletions(-) I like this. The only thing that I would like to see is comments explain what lock protects and why. As I understand it lock is needed because the metadata accesses which use bdrv_pread() and friends will yield. So it is necessary to prevent in-memory qcow2 metadata from getting corrupted during these operations. Stefan
Re: [Qemu-devel] [PATCH 0/3] small trivial patches
Am 27.07.2011 20:11, schrieb Frediano Ziglio: Minor fixes and improves Frediano Ziglio (3): block: removed unused function block: typo fix aio: always check paio_init result block.c | 13 - block.h |2 -- block/raw-posix.c | 13 ++--- 3 files changed, 6 insertions(+), 22 deletions(-) Thanks, applied all to the block branch (and modified the commit log to say raw-posix: ... for patches 2 and 3) Kevin
Re: [Qemu-devel] [RFC PATCH 0/4] Fix subsection ambiguity in the migration format
Am 26.07.2011 14:37, schrieb Anthony Liguori: On 07/26/2011 07:07 AM, Juan Quintela wrote: Anthony Liguorianth...@codemonkey.ws wrote: == What we need == We need to decompose migration into three different problems: 1) serializing device state 2) transforming the device model in order to satisfy forwards and backwards compatibility 3) encoding the serialized device model on the wire. I will change this to: - We need to be able to enable/disable features of a device. A.K.A. make -M pc-0.14 work with devices with the same features than 0.14. Notice that this is _independent_ of migration. In theory, we already have this with qdev flags. - Be able to describe that different features/versions. This is not the difficult part, it can be subsections, optional fields, whatever. What is the difficult part is _knowing_ what fields needs to be on each version. That again depends of the device, not migration. - Be able to to do forward/bacward compatibility (and without comunication both sides is basically impossible). Hrm, I'm not sure I agree with these conclusions. Management tools should do their best job to create two compatible device models. Given two compatible device models, there *may* be differences in the structure of the device models since we evolve things over time. We may rename a field, change the type, etc. To support this, we can use filters both on the destination and receive end to do our best to massage the device model into something compatible. But creating two creating compatible device models is not the job of the migration protocol. It's the job of management tools. I'm not sure if I agree with this. Let's forget about management tools for a moment, and just think of a qemu instance with a given set of command line option describing its devices. Then you start another instance with different options and -incoming and start a migration. The result will be something, but definitely not a successfully migrated VM (even though it might look like one at first). This is why I believe that the information about which devices to use actually belongs into the migration data. There's no way to make use of it with different options. 5) Once we're here, we can implement the next 5-year format. That could be ASN.1 and be bidirectional or whatever makes the most sense. We could support 50 formats if we wanted to. As long as the transport is distinct from the serialization and compat routines, it really doesn't matter. This means finishing the VMState support, once there, only thing needs to change is copy the savevm, and change the visitors to whatever else that we need/want. There's no need to finish VMState to convert to visitors. It's just sed -e 's:qemu_put_be32:visit_type_int32:g' Actually I think the real question is whether we want to have VMState or not. If we do (and I think it's a good thing), then yes, we need to finish it. If not, then we should revert the parts that are already there. We shouldn't end up in an inconsistent state where half of qemu is converted and we don't feel a need to do anything about the other half. Kevin
Re: [Qemu-devel] [PATCH v2 00/23] Memory API, batch 1
On 07/26/2011 06:25 AM, Avi Kivity wrote: This patchset contains the core of the memory API, with one device (usb-ohci) coverted for reference. The API is currently implemented on top of the old ram_addr_t/cpu_register_physical_memory() API, but the plan is to make it standalone later. The goals of the API are: - correctness: by modelling the memory hierarchy, things like the 440FX PAM registers and movable, overlapping PCI BARs can be modelled accurately. - efficiency: by maintaining an object tree describing guest memory, we can eventually get rid of the page descriptor array - security: by having more information available declaratively, we reduce coding errors that may be exploited by malicious guests Applied all. Thanks. Regards, Anthony Liguori Also available from git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git refs/tags/memory-region-batch-1-v2 Changes from v1: - switched to gtk-doc - more copyright blurbs - simplified flatview_simplify() - use assert() instead of abort() for invariant checks (but keep abort() for runtime errors) - commit log fixups Avi Kivity (23): Add memory API documentation Hierarchical memory region API memory: implement dirty tracking memory: merge adjacent segments of a single memory region Internal interfaces for memory API memory: abstract address space operations memory: rename MemoryRegion::has_ram_addr to ::terminates memory: late initialization of ram_addr memory: I/O address space support memory: add backward compatibility for old portio registration memory: add backward compatibility for old mmio registration memory: add ioeventfd support memory: separate building the final memory map into two steps memory: transaction API exec.c: initialize memory map ioport: register ranges by byte aligned addresses always pc: grab system_memory pc: convert pc_memory_init() to memory API pc: move global memory map out of pc_init1() and into its callers pci: pass address space to pci bus when created pci: add MemoryRegion based BAR management API sysbus: add MemoryRegion based memory management API usb-ohci: convert to MemoryRegion Makefile.target|1 + docs/memory.txt| 172 exec-memory.h | 39 ++ exec.c | 19 + hw/apb_pci.c |2 + hw/bonito.c|4 +- hw/grackle_pci.c |5 +- hw/gt64xxx.c |4 +- hw/pc.c| 62 ++- hw/pc.h|9 +- hw/pc_piix.c | 20 +- hw/pci.c | 63 +++- hw/pci.h | 15 +- hw/pci_host.h |1 + hw/pci_internals.h |1 + hw/piix_pci.c | 13 +- hw/ppc4xx_pci.c|5 +- hw/ppc_mac.h |9 +- hw/ppc_newworld.c |5 +- hw/ppc_oldworld.c |3 +- hw/ppc_prep.c |3 +- hw/ppce500_pci.c |6 +- hw/prep_pci.c |5 +- hw/prep_pci.h |3 +- hw/sh_pci.c|4 +- hw/sysbus.c| 27 ++- hw/sysbus.h|3 + hw/unin_pci.c | 10 +- hw/usb-ohci.c | 42 +-- hw/versatile_pci.c |2 + ioport.c |4 +- memory.c | 1141 memory.h | 469 + 33 files changed, 2072 insertions(+), 99 deletions(-) create mode 100644 docs/memory.txt create mode 100644 exec-memory.h create mode 100644 memory.c create mode 100644 memory.h
Re: [Qemu-devel] [PATCH v7] showing a splash picture when start
On 07/27/2011 05:04 AM, Wayne Xia wrote:
From: waynexiaw...@linux.vnet.ibm.com
Added options to let qemu transfer two configuration files to bios:
bootsplash.bmp and etc/boot-menu-wait, which could be specified by command
-boot splash=P,splash-time=T
P is jpg/bmp file name or an absolute path, T have a max value of 0x, unit
is ms. With these two options, if user invoke qemu with menu=on option, then
a splash picture would be showed in a given time. For example:
qemu -boot menu=on,splash=/root/boot.bmp,splash-time=5000
would make boot.bmp shown as a brand with 5 seconds in the booting up process.
This feature need the new seabios's support, which could be got from git.
Signed-off-by: Wayne Xiaxiaw...@linux.vnet.ibm.com
Applied but haven't bumped SeaBIOS yet. Will bump SeaBIOS once -rc1
goes out.
Regards,
Anthony Liguori
---
hw/fw_cfg.c | 140 ++-
qemu-config.c | 27 +++
qemu-options.hx | 16 ++-
sysemu.h|3 +
vl.c| 17 ++-
5 files changed, 199 insertions(+), 4 deletions(-)
diff --git a/hw/fw_cfg.c b/hw/fw_cfg.c
index 34e7526..a29db90 100644
--- a/hw/fw_cfg.c
+++ b/hw/fw_cfg.c
@@ -26,6 +26,7 @@
#include isa.h
#include fw_cfg.h
#include sysbus.h
+#include qemu-error.h
/* debug firmware config */
//#define DEBUG_FW_CFG
@@ -56,6 +57,143 @@ struct FWCfgState {
Notifier machine_ready;
};
+#define JPG_FILE 0
+#define BMP_FILE 1
+
+static FILE *probe_splashfile(char *filename, int *file_sizep, int *file_typep)
+{
+FILE *fp = NULL;
+int fop_ret;
+int file_size;
+int file_type = -1;
+unsigned char buf[2] = {0, 0};
+unsigned int filehead_value = 0;
+int bmp_bpp;
+
+fp = fopen(filename, rb);
+if (fp == NULL) {
+error_report(failed to open file '%s'., filename);
+return fp;
+}
+/* check file size */
+fseek(fp, 0L, SEEK_END);
+file_size = ftell(fp);
+if (file_size 2) {
+error_report(file size is less than 2 bytes '%s'., filename);
+fclose(fp);
+fp = NULL;
+return fp;
+}
+/* check magic ID */
+fseek(fp, 0L, SEEK_SET);
+fop_ret = fread(buf, 1, 2, fp);
+filehead_value = (buf[0] + (buf[1] 8)) 0x;
+if (filehead_value == 0xd8ff) {
+file_type = JPG_FILE;
+} else {
+if (filehead_value == 0x4d42) {
+file_type = BMP_FILE;
+}
+}
+if (file_type 0) {
+error_report('%s' not jpg/bmp file,head:0x%x.,
+ filename, filehead_value);
+fclose(fp);
+fp = NULL;
+return fp;
+}
+/* check BMP bpp */
+if (file_type == BMP_FILE) {
+fseek(fp, 28, SEEK_SET);
+fop_ret = fread(buf, 1, 2, fp);
+bmp_bpp = (buf[0] + (buf[1] 8)) 0x;
+if (bmp_bpp != 24) {
+error_report(only 24bpp bmp file is supported.);
+fclose(fp);
+fp = NULL;
+return fp;
+}
+}
+/* return values */
+*file_sizep = file_size;
+*file_typep = file_type;
+return fp;
+}
+
+static void fw_cfg_bootsplash(FWCfgState *s)
+{
+int boot_splash_time = -1;
+const char *boot_splash_filename = NULL;
+char *p;
+char *filename;
+FILE *fp;
+int fop_ret;
+int file_size;
+int file_type = -1;
+const char *temp;
+
+/* get user configuration */
+QemuOptsList *plist = qemu_find_opts(boot-opts);
+QemuOpts *opts = QTAILQ_FIRST(plist-head);
+if (opts != NULL) {
+temp = qemu_opt_get(opts, splash);
+if (temp != NULL) {
+boot_splash_filename = temp;
+}
+temp = qemu_opt_get(opts, splash-time);
+if (temp != NULL) {
+p = (char *)temp;
+boot_splash_time = strtol(p, (char **)p, 10);
+}
+}
+
+/* insert splash time if user configurated */
+if (boot_splash_time= 0) {
+/* validate the input */
+if (boot_splash_time 0x) {
+error_report(splash time is big than 65535, force it to 65535.);
+boot_splash_time = 0x;
+}
+/* use little endian format */
+qemu_extra_params_fw[0] = (uint8_t)(boot_splash_time 0xff);
+qemu_extra_params_fw[1] = (uint8_t)((boot_splash_time 8) 0xff);
+fw_cfg_add_file(s, etc/boot-menu-wait, qemu_extra_params_fw, 2);
+}
+
+/* insert splash file if user configurated */
+if (boot_splash_filename != NULL) {
+filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, boot_splash_filename);
+if (filename == NULL) {
+error_report(failed to find file '%s'., boot_splash_filename);
+return;
+}
+/* probing the file */
+fp = probe_splashfile(filename,file_size,file_type);
+if (fp == NULL) {
+qemu_free(filename);
+return;
+}
+/* loading file data */
+
Re: [Qemu-devel] [PATCH 0.16 v3 0/3] make endian-independent unaligned memory access functions available to libhw
On 07/28/2011 05:10 AM, Paolo Bonzini wrote:
Functions like ldl_be_p and ldl_le_p are currently used only as building
blocks for {ld,st}XX_p. As such, they are in cpu-all.h even though they
have absolutely no dependency on the target.
In order to make them globally available, this series moves them to
bswap.h instead.
An interesting part of this is that there are functions also for floating
point values. Leaving them in cpu-all.h would be possible but untidy.
In fact handling these is easy, but it requires to make softfloat.h
target-dependent as well. This is what patch 2 does.
Applied. Thanks.
Regards,
Anthony Liguori
v2-v3:
rebase
v1-v2:
rebase, use softfloat-specialize.h instead of introducing
softfloat-target.h
Paolo Bonzini (3):
move WORDS_ALIGNED to qemu-common.h
softfloat: change default nan definitions to variables
move unaligned memory access functions to bswap.h
Makefile.hw|2 +-
bswap.h| 474
configure |3 +-
cpu-all.h | 446 +-
cpu-common.h |4 -
fpu/softfloat-specialize.h | 72 +++
fpu/softfloat.h| 60 +-
qemu-common.h |4 +
8 files changed, 562 insertions(+), 503 deletions(-)
Re: [Qemu-devel] [PATCH 1/2] linux aio: support flush operation
On Thu, Jul 28, 2011 at 02:41:02PM +0200, Kevin Wolf wrote: More or less. There's one corner case for all Linux I/O, and that is only writes up to INT_MAX are supported, and larger writes (and reads) get truncated to it. It's pretty nasty, but Linux has been vocally opposed to fixing this issue. I think we can safely ignore this. So just replacing the current ret = -EINVAL; by a memset(buf + ret, 0, len - ret); ret = 0; should be okay, right? (Of course using the qiov versions, but you get the idea) This should be safe.
Re: [Qemu-devel] [PATCH -V2] coroutine: Add CoRwlock support
On Fri, 29 Jul 2011 14:53:14 +0200, Kevin Wolf kw...@redhat.com wrote: Am 27.07.2011 18:21, schrieb Aneesh Kumar K.V: Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com --- qemu-coroutine-lock.c | 44 qemu-coroutine.h | 12 2 files changed, 56 insertions(+), 0 deletions(-) Looks good to me. What's your plan with getting this merged? Are you going to just include it with another series that you'll send once the basic coroutine support is in? Since the patch already is dependent on CoQueue, it would be nice if you can push it through your tree. I will stage the dependent VirtFS patch after that get merged upstream. -aneesh
Re: [Qemu-devel] [RFC PATCH 0/4] Fix subsection ambiguity in the migration format
On 07/29/2011 09:03 AM, Kevin Wolf wrote: Am 26.07.2011 14:37, schrieb Anthony Liguori: Hrm, I'm not sure I agree with these conclusions. Management tools should do their best job to create two compatible device models. Given two compatible device models, there *may* be differences in the structure of the device models since we evolve things over time. We may rename a field, change the type, etc. To support this, we can use filters both on the destination and receive end to do our best to massage the device model into something compatible. But creating two creating compatible device models is not the job of the migration protocol. It's the job of management tools. I'm not sure if I agree with this. Let's forget about management tools for a moment, and just think of a qemu instance with a given set of command line option describing its devices. Then you start another instance with different options and -incoming and start a migration. The result will be something, but definitely not a successfully migrated VM (even though it might look like one at first). This is why I believe that the information about which devices to use actually belongs into the migration data. There's no way to make use of it with different options. I agree with you actually. Right now, it's the management tools job. The complexity is daunting. Recreating the same object model, particularly after hotplug, is difficult and in many cases impossible. I think the primary problem is that there are so many ways to create things. -M pc creates a bunch of stuff that there's no way to create individually. The stuff it creates can sort of be manipulated by using -global but not on a per device basis. Much of it isn't even addressable. Creating backends is a totally different mechanism and each backend has different mechanisms to enumerate and create. The result is that introspecting what's there and recreating it is insanely complex today. That's the motivation behind QOM. plug_list lists *everything*. All objects, whether they are created as part of the PIIX3 or whether it's a backing file, can be directly addressed and manipulated. If you look at qsh, there's an import command. The export command is trivial and I don't remember if I've already added it. But the point is that you should be able to 'qsh export' everything and then 'qsh import' everything to create the exact same device model in another QEMU instance. And yeah, this should end up becoming part of the migration protocol. 5) Once we're here, we can implement the next 5-year format. That could be ASN.1 and be bidirectional or whatever makes the most sense. We could support 50 formats if we wanted to. As long as the transport is distinct from the serialization and compat routines, it really doesn't matter. This means finishing the VMState support, once there, only thing needs to change is copy the savevm, and change the visitors to whatever else that we need/want. There's no need to finish VMState to convert to visitors. It's just sed -e 's:qemu_put_be32:visit_type_int32:g' Actually I think the real question is whether we want to have VMState or not. VMState doesn't give me what I want by itself. I want to be able to marshal the device tree to an in-memory representation that can be manipulated. One approach to doing that is first completing VMState, and then writing something that can walk the VMState descriptions. The VMState descriptions are fairly complicated but it's doable. Another approach, which I'm arguing is much simpler, the imperative nature of our current serialization and use visitors. There may be other advantages of a declarative description of VMState that would justify completing the conversions. But I don't think we need it to start improving the migration protocol. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH] lm832x: Take DeviceState pointer in lm832x_key_event()
On 07/28/2011 09:47 AM, Peter Maydell wrote:
Since lm832x has been qdev'ified, its users will generally
have a DeviceState pointer rather than an i2c_slave pointer,
so adjust lm832x_key_event's prototype to suit.
This allows the n810 (its only user) to actually pass a correct
pointer to it rather than NULL. The effect is that we no longer
segfault when a key is pressed.
Signed-off-by: Peter Maydellpeter.mayd...@linaro.org
---
NB: this patch depends on the OMAP GPIO v2 patchset.
Could you put together a pull request for these devices?
Regards,
Anthony Liguori
hw/i2c.h |2 +-
hw/lm832x.c |4 ++--
hw/nseries.c |7 +++
3 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/hw/i2c.h b/hw/i2c.h
index 5514402..9381d01 100644
--- a/hw/i2c.h
+++ b/hw/i2c.h
@@ -72,6 +72,6 @@ void wm8750_set_bclk_in(void *opaque, int new_hz);
void tmp105_set(i2c_slave *i2c, int temp);
/* lm832x.c */
-void lm832x_key_event(i2c_slave *i2c, int key, int state);
+void lm832x_key_event(DeviceState *dev, int key, int state);
#endif
diff --git a/hw/lm832x.c b/hw/lm832x.c
index 590a4cc..992ce49 100644
--- a/hw/lm832x.c
+++ b/hw/lm832x.c
@@ -474,9 +474,9 @@ static int lm8323_init(i2c_slave *i2c)
return 0;
}
-void lm832x_key_event(struct i2c_slave *i2c, int key, int state)
+void lm832x_key_event(DeviceState *dev, int key, int state)
{
-LM823KbdState *s = (LM823KbdState *) i2c;
+LM823KbdState *s = FROM_I2C_SLAVE(LM823KbdState, I2C_SLAVE_FROM_QDEV(dev));
if ((s-status INT_ERROR) (s-error ERR_FIFOOVR))
return;
diff --git a/hw/nseries.c b/hw/nseries.c
index 32f2f53..45b52bb 100644
--- a/hw/nseries.c
+++ b/hw/nseries.c
@@ -45,7 +45,7 @@ struct n800_s {
i2c_bus *i2c;
int keymap[0x80];
-i2c_slave *kbd;
+DeviceState *kbd;
TUSBState *usb;
void *retu;
@@ -362,7 +362,6 @@ static int n810_keys[0x80] = {
static void n810_kbd_setup(struct n800_s *s)
{
qemu_irq kbd_irq = qdev_get_gpio_in(s-cpu-gpio, N810_KEYBOARD_GPIO);
-DeviceState *dev;
int i;
for (i = 0; i 0x80; i ++)
@@ -375,8 +374,8 @@ static void n810_kbd_setup(struct n800_s *s)
/* Attach the LM8322 keyboard to the I2C bus,
* should happen in n8x0_i2c_setup and s-kbd be initialised here. */
-dev = i2c_create_slave(s-i2c, lm8323, N810_LM8323_ADDR);
-qdev_connect_gpio_out(dev, 0, kbd_irq);
+s-kbd = i2c_create_slave(s-i2c, lm8323, N810_LM8323_ADDR);
+qdev_connect_gpio_out(s-kbd, 0, kbd_irq);
}
/* LCD MIPI DBI-C controller (URAL) */
Re: [Qemu-devel] [RFC PATCH 1/4] add support for machine models to specify their migration format
On 07/29/2011 03:08 PM, Anthony Liguori wrote: Please avoid this gcc extension as it's relatively obscure. But in addition, why would use you 0 as the new format instead of QEMU_VM_FILE_VERSION + 1? 0 is the default. If a machine doesn't specify a format, it gets the newest one automatically. Paolo
Re: [Qemu-devel] [RFC PATCH 3/4] savevm: define new unambiguous migration format
On 07/29/2011 03:12 PM, Anthony Liguori wrote: Please introduce a macro so this code is readable. Ok. We have other machines that support migration in other archs too. Those machine types are not versioned, so they will automatically switch to the newest version. Paolo
Re: [Qemu-devel] [PATCH v2] multiboot: Fix bss segment support
On 07/24/2011 10:55 AM, Göran Weinholt wrote:
Multiboot images can specify a bss segment. The boot loader must clear
the memory of the bss and ensure that no modules or structures are
allocated inside it. Several fields are provided in the Multiboot
header that were previously not used properly. The header is now used
to determine how much data should be read from the image and how much
memory should be reserved to the bss segment.
Signed-off-by: Göran Weinholtgo...@weinholt.se
Applied. Thanks.
Regards,
Anthony Liguori
---
hw/multiboot.c | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/hw/multiboot.c b/hw/multiboot.c
index 2426e84..a1d3f41 100644
--- a/hw/multiboot.c
+++ b/hw/multiboot.c
@@ -198,11 +198,14 @@ int load_multiboot(void *fw_cfg,
} else {
/* Valid if mh_flags sets MULTIBOOT_HEADER_HAS_ADDR. */
uint32_t mh_header_addr = ldl_p(header+i+12);
+uint32_t mh_load_end_addr = ldl_p(header+i+20);
+uint32_t mh_bss_end_addr = ldl_p(header+i+24);
mh_load_addr = ldl_p(header+i+16);
uint32_t mb_kernel_text_offset = i - (mh_header_addr - mh_load_addr);
+uint32_t mb_load_size = mh_load_end_addr - mh_load_addr;
mh_entry_addr = ldl_p(header+i+28);
-mb_kernel_size = kernel_file_size - mb_kernel_text_offset;
+mb_kernel_size = mh_bss_end_addr - mh_load_addr;
/* Valid if mh_flags sets MULTIBOOT_HEADER_HAS_VBE.
uint32_t mh_mode_type = ldl_p(header+i+32);
@@ -212,17 +215,18 @@ int load_multiboot(void *fw_cfg,
mb_debug(multiboot: mh_header_addr = %#x\n, mh_header_addr);
mb_debug(multiboot: mh_load_addr = %#x\n, mh_load_addr);
-mb_debug(multiboot: mh_load_end_addr = %#x\n, ldl_p(header+i+20));
-mb_debug(multiboot: mh_bss_end_addr = %#x\n, ldl_p(header+i+24));
+mb_debug(multiboot: mh_load_end_addr = %#x\n, mh_load_end_addr);
+mb_debug(multiboot: mh_bss_end_addr = %#x\n, mh_bss_end_addr);
mb_debug(qemu: loading multiboot kernel (%#x bytes) at %#x\n,
- mb_kernel_size, mh_load_addr);
+ mb_load_size, mh_load_addr);
mbs.mb_buf = qemu_malloc(mb_kernel_size);
fseek(f, mb_kernel_text_offset, SEEK_SET);
-if (fread(mbs.mb_buf, 1, mb_kernel_size, f) != mb_kernel_size) {
+if (fread(mbs.mb_buf, 1, mb_load_size, f) != mb_load_size) {
fprintf(stderr, fread() failed\n);
exit(1);
}
+memset(mbs.mb_buf + mb_load_size, 0, mb_kernel_size - mb_load_size);
fclose(f);
}
Re: [Qemu-devel] [PATCH] monitor: fix build breakage with --disable-vnc
On 07/25/2011 03:29 AM, TeLeMan wrote:
The breakage was introduced by the commit
13661089810d3e59931f3e80d7cb541b99af7071
Signed-off-by: TeLeMangele...@gmail.com
Applied. Thanks.
Regards,
Anthony Liguori
---
monitor.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/monitor.c b/monitor.c
index 92cdd05..52ae5f2 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1200,10 +1200,12 @@ static int add_graphics_client(Monitor *mon, const
QDict *qdict, QObject **ret_d
}
qerror_report(QERR_ADD_CLIENT_FAILED);
return -1;
+#ifdef CONFIG_VNC
} else if (strcmp(protocol, vnc) == 0) {
int fd = monitor_get_fd(mon, fdname);
vnc_display_add_client(NULL, fd, skipauth);
return 0;
+#endif
} else if ((s = qemu_chr_find(protocol)) != NULL) {
int fd = monitor_get_fd(mon, fdname);
if (qemu_chr_add_client(s, fd) 0) {
Re: [Qemu-devel] [PATCH] Fix last sector write on sd card
On 07/25/2011 07:21 AM, Dr. David Alan Gilbert wrote:
When writing the last sector of an SD card using WRITE_MULTIPLE_BLOCK
QEmu throws an error saying that we've run off the end, and leaves
itself in the wrong state.
Tested on ARM Vexpress model.
Signed-off-by: Dr. David Alan Gilbertdavid.gilb...@linaro.org
Applied. Thanks.
Regards,
Anthony Liguori
---
Don't throw address error on last block, and leave in correct state.
diff --git a/hw/sd.c b/hw/sd.c
index cedfb20..219a0dd 100644
--- a/hw/sd.c
+++ b/hw/sd.c
@@ -1450,14 +1450,8 @@ void sd_write_data(SDState *sd, uint8_t value)
break;
case 25: /* CMD25: WRITE_MULTIPLE_BLOCK */
-sd-data[sd-data_offset ++] = value;
-if (sd-data_offset= sd-blk_len) {
-/* TODO: Check CRC before committing */
-sd-state = sd_programming_state;
-BLK_WRITE_BLOCK(sd-data_start, sd-data_offset);
-sd-blk_written ++;
-sd-data_start += sd-blk_len;
-sd-data_offset = 0;
+if (sd-data_offset == 0) {
+/* Start of the block - lets check the address is valid */
if (sd-data_start + sd-blk_len sd-size) {
sd-card_status |= ADDRESS_ERROR;
break;
@@ -1466,6 +1460,15 @@ void sd_write_data(SDState *sd, uint8_t value)
sd-card_status |= WP_VIOLATION;
break;
}
+}
+sd-data[sd-data_offset++] = value;
+if (sd-data_offset= sd-blk_len) {
+/* TODO: Check CRC before committing */
+sd-state = sd_programming_state;
+BLK_WRITE_BLOCK(sd-data_start, sd-data_offset);
+sd-blk_written++;
+sd-data_start += sd-blk_len;
+sd-data_offset = 0;
sd-csd[14] |= 0x40;
/* Bzzztt Operation complete. */
Re: [Qemu-devel] [PATCH resend] Add missing trace call to oslib-posix.c:qemu_vmalloc()
On 07/25/2011 10:13 AM, jes.soren...@redhat.com wrote:
From: Jes Sorensenjes.soren...@redhat.com
Signed-off-by: Jes Sorensenjes.soren...@redhat.com
Applied. Thanks.
Regards,
Anthony Liguori
---
oslib-posix.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/oslib-posix.c b/oslib-posix.c
index 3a18e86..196099c 100644
--- a/oslib-posix.c
+++ b/oslib-posix.c
@@ -79,7 +79,10 @@ void *qemu_memalign(size_t alignment, size_t size)
/* alloc shared memory pages */
void *qemu_vmalloc(size_t size)
{
-return qemu_memalign(getpagesize(), size);
+void *ptr;
+ptr = qemu_memalign(getpagesize(), size);
+trace_qemu_vmalloc(size, ptr);
+return ptr;
}
void qemu_vfree(void *ptr)
Re: [Qemu-devel] [PATCH] Allow to leave type on default in -machine
On 07/25/2011 11:11 AM, Jan Kiszka wrote:
On 2011-07-25 13:48, Jan Kiszka wrote:
On 2011-07-25 13:39, Markus Armbruster wrote:
Jan Kiszkajan.kis...@siemens.com writes:
On 2011-07-25 12:45, Richard W.M. Jones wrote:
On Mon, Jul 25, 2011 at 12:33:01PM +0200, Jan Kiszka wrote:
On 2011-07-25 11:41, Richard W.M. Jones wrote:
On Sat, Jul 23, 2011 at 12:38:37PM +0200, Jan Kiszka wrote:
From: Jan Kiszkajan.kis...@siemens.com
-machine somehow suggests that it selects the machine, but it doesn't.
Fix that before this command is set in stone.
Actually, -machine should supersede -M and allow to introduce arbitrary
per-machine options to the command line. That will change the internal
realization again, but we will be able to keep the user interface
stable.
This breaks libguestfs which was doing:
qemu -machine accel=kvm:tcg ...
We are not passing any -M option at all. We don't particularly care
about the machine type since we're not that performance sensitive and
we don't need to serialize the machine state.
I have checked, and this works:
qemu -machine pc,accel=kvm:tcg ...
pc is the default, right? What about for other architectures?
Yes, pc is the right default. Other arch have other defaults.
So what you're saying is we have to parse qemu -machine \? output by
looking for the string '(default)'? eg:
$ ./arm-softmmu/qemu-system-arm -machine \?|fgrep '(default)'
integratorcp ARM Integrator/CP (ARM926EJ-S) (default)
$ ./i386-softmmu/qemu -machine \?|fgrep '(default)'
pc-0.14Standard PC (default)
I understand, this is clumsy. Will see if we can do better.
Is there a technical reason why type isn't optional with -machine?
[...]
Maybe it's just the
assert(!permit_abbrev || list-implied_opt_name);
in qemu_opts_parse, but I haven't looked at all details (and all other
users) yet.
I was incorrectly pointing the core, the problem is solvable at the
level where we parse -machine:
---8
This allows to specify -machine options without setting an explicit
machine type. We will pick the default machine in this case. Requesting
the list of available machines is still possible via '-machine ?' e.g.
Signed-off-by: Jan Kiszkajan.kis...@siemens.com
Applied. Thanks.
Regards,
Anthony Liguori
---
vl.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/vl.c b/vl.c
index 8256504..5e53ddc 100644
--- a/vl.c
+++ b/vl.c
@@ -2720,7 +2720,10 @@ int main(int argc, char **argv, char **envp)
fprintf(stderr, parse error: %s\n, optarg);
exit(1);
}
-machine = machine_parse(qemu_opt_get(opts, type));
+optarg = qemu_opt_get(opts, type);
+if (optarg) {
+machine = machine_parse(optarg);
+}
break;
case QEMU_OPTION_usb:
usb_enabled = 1;
Re: [Qemu-devel] [PATCH] CODING_STYLE: explicitly allow braceless 'else if'
On 07/25/2011 10:55 AM, Avi Kivity wrote:
It's already allowed by the example; there are about 1800 instances in the
tree; and disallowing it would lead to
if (a) {
...
} else {
if (b) {
...
} else {
if (c) {
...
} else {
if (d) {
...
} else {
...
}
}
}
}
instead of
if (a) {
...
} else if (b) {
...
} else if (c) {
...
} else if (d) {
...
} else {
...
}
which is more readable.
Signed-off-by: Avi Kivitya...@redhat.com
Applied. Thanks.
Regards,
Anthony Liguori
---
CODING_STYLE |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/CODING_STYLE b/CODING_STYLE
index 5ecfa22..6e61c49 100644
--- a/CODING_STYLE
+++ b/CODING_STYLE
@@ -68,6 +68,10 @@ keyword. Example:
printf(a was something else entirely.\n);
}
+Note that 'else if' is considered a single statement; otherwise a long if/
+else if/else if/.../else sequence would need an indent for every else
+statement.
+
An exception is the opening brace for a function; for reasons of tradition
and clarity it comes on a line by itself:
Re: [Qemu-devel] [PATCH] configure: add --disable-zlib-test
On 07/26/2011 04:30 AM, Alon Levy wrote:
This is required for building libcacard which doesn't itself require
zlib without bringing in this requirement to the build environment.
Signed-off-by: Alon Levyal...@redhat.com
Applied. Thanks.
Regards,
Anthony Liguori
---
I'd like this to go into 0.15.0 too, it makes building libcacard possible
without zlib-devel being installed.
---
configure | 23 ++-
1 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/configure b/configure
index 88159ac..5fc0f82 100755
--- a/configure
+++ b/configure
@@ -178,6 +178,7 @@ rbd=
smartcard=
smartcard_nss=
opengl=
+zlib=yes
# parse CC options first
for opt do
@@ -743,6 +744,8 @@ for opt do
;;
--enable-smartcard-nss) smartcard_nss=yes
;;
+ --disable-zlib-test) zlib=no
+ ;;
*) echo ERROR: unknown option $opt; show_help=yes
;;
esac
@@ -1172,18 +1175,20 @@ fi
##
# zlib check
-cat $TMPC EOF
+if test $zlib != no ; then
+cat $TMPC EOF
#includezlib.h
int main(void) { zlibVersion(); return 0; }
EOF
-if compile_prog -lz ; then
-:
-else
-echo
-echo Error: zlib check failed
-echo Make sure to have the zlib libs and headers installed.
-echo
-exit 1
+if compile_prog -lz ; then
+:
+else
+echo
+echo Error: zlib check failed
+echo Make sure to have the zlib libs and headers installed.
+echo
+exit 1
+fi
fi
##
Re: [Qemu-devel] [PATCH] Fix a compilation error in xen-mapcache.c
On 07/26/2011 09:33 AM, Stefan Berger wrote:
This patch fixes a compilation error in xen-mapcache.c .
/home/stefanb/qemu/qemu-git/xen-mapcache.c: In function
‘xen_ram_addr_from_mapcache’:
/home/stefanb/qemu/qemu-git/xen-mapcache.c:240:42: error: variable ‘pentry’ set
but not used [-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors
Signed-off-by: Stefan Bergerstef...@linux.vnet.ibm.com
Applied. Thanks.
Regards,
Anthony Liguori
---
xen-mapcache.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Index: qemu-git/xen-mapcache.c
===
--- qemu-git.orig/xen-mapcache.c
+++ qemu-git/xen-mapcache.c
@@ -237,7 +237,7 @@ uint8_t *xen_map_cache(target_phys_addr_
ram_addr_t xen_ram_addr_from_mapcache(void *ptr)
{
-MapCacheEntry *entry = NULL, *pentry = NULL;
+MapCacheEntry *entry = NULL;
MapCacheRev *reventry;
target_phys_addr_t paddr_index;
target_phys_addr_t size;
@@ -263,7 +263,6 @@ ram_addr_t xen_ram_addr_from_mapcache(vo
entry =mapcache-entry[paddr_index % mapcache-nr_buckets];
while (entry (entry-paddr_index != paddr_index || entry-size !=
size)) {
-pentry = entry;
entry = entry-next;
}
if (!entry) {
Re: [Qemu-devel] [PATCH] lm832x: Take DeviceState pointer in lm832x_key_event()
On 29 July 2011 15:31, Anthony Liguori anth...@codemonkey.ws wrote: On 07/28/2011 09:47 AM, Peter Maydell wrote: Since lm832x has been qdev'ified, its users will generally have a DeviceState pointer rather than an i2c_slave pointer, so adjust lm832x_key_event's prototype to suit. This allows the n810 (its only user) to actually pass a correct pointer to it rather than NULL. The effect is that we no longer segfault when a key is pressed. Signed-off-by: Peter Maydellpeter.mayd...@linaro.org --- NB: this patch depends on the OMAP GPIO v2 patchset. Could you put together a pull request for these devices? Sure. Do you want just the GPIO patches and this patch, or shall I put the nand/onenand patches in too? thanks -- PMM
Re: [Qemu-devel] [RFC PATCH 0/4] Fix subsection ambiguity in the migration format
On 07/29/2011 03:14 PM, Anthony Liguori wrote: I really hate the idea of changing the migration format moments before the release. So do I, but that's life. Since subsections are optional, can't we take the offending subsections, remove them, bump the section version numbers and make the fields required? The bug happens when you migrate from 0.15 to 0.15, and 0.14 didn't have any subsection for that device. This happens pretty much in all cases that were added to 0.15. It quickly makes a bigger patch than this one, and actually one that's harder to review. At least with this one things can only go _royally_ wrong, and any serious automated test would catch it. Paolo
[Qemu-devel] [PATCH] MAINTAINERS: add entry for Xen
From: Stefano Stabellini stefano.stabell...@eu.citrix.com Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com --- MAINTAINERS | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 6115e4e..273a6a7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -143,6 +143,16 @@ L: k...@vger.kernel.org S: Supported F: target-i386/kvm.c +Guest CPU Cores (Xen): +-- + +X86 +M: Stefano Stabellini stefano.stabell...@eu.citrix.com +L: xen-de...@lists.xensource.com +S: Supported +F: xen-* +F: */xen* + ARM Machines Gumstix -- 1.7.2.3
Re: [Qemu-devel] [RFC PATCH 0/4] Fix subsection ambiguity in the migration format
Am 29.07.2011 16:28, schrieb Anthony Liguori: On 07/29/2011 09:03 AM, Kevin Wolf wrote: Am 26.07.2011 14:37, schrieb Anthony Liguori: Hrm, I'm not sure I agree with these conclusions. Management tools should do their best job to create two compatible device models. Given two compatible device models, there *may* be differences in the structure of the device models since we evolve things over time. We may rename a field, change the type, etc. To support this, we can use filters both on the destination and receive end to do our best to massage the device model into something compatible. But creating two creating compatible device models is not the job of the migration protocol. It's the job of management tools. I'm not sure if I agree with this. Let's forget about management tools for a moment, and just think of a qemu instance with a given set of command line option describing its devices. Then you start another instance with different options and -incoming and start a migration. The result will be something, but definitely not a successfully migrated VM (even though it might look like one at first). This is why I believe that the information about which devices to use actually belongs into the migration data. There's no way to make use of it with different options. I agree with you actually. Right now, it's the management tools job. The complexity is daunting. Recreating the same object model, particularly after hotplug, is difficult and in many cases impossible. I think the primary problem is that there are so many ways to create things. -M pc creates a bunch of stuff that there's no way to create individually. The stuff it creates can sort of be manipulated by using -global but not on a per device basis. Much of it isn't even addressable. Creating backends is a totally different mechanism and each backend has different mechanisms to enumerate and create. And backends are actually something totally different: They are the part that you can't migrate automatically, but that you must create on the destination host like we're doing it today. The paths to images etc. could be completely different from the source host. The one change for backends is that if we migrate a device in way so that it can say I need the block backend with the ID 'foo', then we can at least make sure that the backend actually exists and is usable. The result is that introspecting what's there and recreating it is insanely complex today. That's the motivation behind QOM. plug_list lists *everything*. All objects, whether they are created as part of the PIIX3 or whether it's a backing file, can be directly addressed and manipulated. If you look at qsh, there's an import command. The export command is trivial and I don't remember if I've already added it. But the point is that you should be able to 'qsh export' everything and then 'qsh import' everything to create the exact same device model in another QEMU instance. And yeah, this should end up becoming part of the migration protocol. If all you're saying is that we can't get it tomorrow, that's fine for me. Good to know that we agree on the goal anyway. 5) Once we're here, we can implement the next 5-year format. That could be ASN.1 and be bidirectional or whatever makes the most sense. We could support 50 formats if we wanted to. As long as the transport is distinct from the serialization and compat routines, it really doesn't matter. This means finishing the VMState support, once there, only thing needs to change is copy the savevm, and change the visitors to whatever else that we need/want. There's no need to finish VMState to convert to visitors. It's just sed -e 's:qemu_put_be32:visit_type_int32:g' Actually I think the real question is whether we want to have VMState or not. VMState doesn't give me what I want by itself. I want to be able to marshal the device tree to an in-memory representation that can be manipulated. One approach to doing that is first completing VMState, and then writing something that can walk the VMState descriptions. The VMState descriptions are fairly complicated but it's doable. Another approach, which I'm arguing is much simpler, the imperative nature of our current serialization and use visitors. There may be other advantages of a declarative description of VMState that would justify completing the conversions. But I don't think we need it to start improving the migration protocol. Yeah, I somehow read it as there's no reason to continue with converting to VMState, which isn't what you were saying. Kevin
Re: [Qemu-devel] [PATCH -V2] coroutine: Add CoRwlock support
Am 29.07.2011 16:24, schrieb Aneesh Kumar K.V: On Fri, 29 Jul 2011 14:53:14 +0200, Kevin Wolf kw...@redhat.com wrote: Am 27.07.2011 18:21, schrieb Aneesh Kumar K.V: Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com --- qemu-coroutine-lock.c | 44 qemu-coroutine.h | 12 2 files changed, 56 insertions(+), 0 deletions(-) Looks good to me. What's your plan with getting this merged? Are you going to just include it with another series that you'll send once the basic coroutine support is in? Since the patch already is dependent on CoQueue, it would be nice if you can push it through your tree. I will stage the dependent VirtFS patch after that get merged upstream. Okay, I applied it to my branch so that I won't forget about it, but while merging I noticed two things that you could fix: The patch adds an #include qemu-thread.h to qemu-coroutine.h for apparently no reason, and it would be nice to have comments in qemu-coroutine.h like all other functions have. Kevin
Re: [Qemu-devel] [PATCH 1/2] linux aio: support flush operation
On Thu, Jul 28, 2011 at 1:15 PM, Christoph Hellwig h...@lst.de wrote: On Thu, Jul 28, 2011 at 09:47:05AM +0200, Kevin Wolf wrote: Indeed. This has come up a few times, and actually is a mostly trivial task. Maybe we should give up waiting for -blockdev and separate cache mode settings and allow a nocache-writethrough or similar mode now? It's going to be around 10 lines of code + documentation. I understand that there may be reasons for using O_DIRECT | O_DSYNC, but what is the explanation for O_DSYNC improving performance? There isn't any, at least for modern Linux. O_DSYNC at this point is equivalent to a range fdatasync for each write call, and given that we're doing O_DIRECT the ranges flush doesn't matter. If you do have a modern host and an old guest it might end up beeing faster because the barrier implementation in Linux used to suck so badly, but that's not inhrent to the I/O model. If you guest however doesn't support cache flushes at all O_DIRECT | O_DSYNC is the only sane model to use for local filesystems and block devices. I can rebase this cache=directsync patch and send it: http://repo.or.cz/w/qemu/stefanha.git/commitdiff/6756719a46ac9876ac6d0460a33ad98e96a3a923 The other weird caching-related option I was playing with is -drive ...,readahead=on|off. It lets you disable the host kernel readahead on buffered modes (cache=writeback|writethrough): http://repo.or.cz/w/qemu/stefanha.git/commitdiff/f2fc2b297a2b2dd0cccd1dc2f7c519f3b0374e0d Stefan
[Qemu-devel] [PATCH v2 0.15 1/4] add support for machine models to specify their migration format
We need to provide a new migration format, and not break migration
in old machine models. So add a migration_format field to QEMUMachine.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
cpu-common.h |3 ---
hw/boards.h |1 +
qemu-common.h |3 +++
savevm.c | 16 ++--
4 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/cpu-common.h b/cpu-common.h
index 44b04b3..8c61b18 100644
--- a/cpu-common.h
+++ b/cpu-common.h
@@ -26,9 +26,6 @@ enum device_endian {
DEVICE_LITTLE_ENDIAN,
};
-/* address in the RAM (different from a physical address) */
-typedef unsigned long ram_addr_t;
-
/* memory API */
typedef void CPUWriteMemoryFunc(void *opaque, target_phys_addr_t addr,
uint32_t value);
diff --git a/hw/boards.h b/hw/boards.h
index 716fd7b..560dbaf 100644
--- a/hw/boards.h
+++ b/hw/boards.h
@@ -19,6 +19,7 @@ typedef struct QEMUMachine {
QEMUMachineInitFunc *init;
int use_scsi;
int max_cpus;
+unsigned migration_format;
unsigned int no_serial:1,
no_parallel:1,
use_virtcon:1,
diff --git a/qemu-common.h b/qemu-common.h
index ba55719..24330be 100644
--- a/qemu-common.h
+++ b/qemu-common.h
@@ -91,6 +91,9 @@ static inline char *realpath(const char *path, char
*resolved_path)
}
#endif
+/* address in the RAM (different from a physical address) */
+typedef unsigned long ram_addr_t;
+
/* FIXME: Remove NEED_CPU_H. */
#ifndef NEED_CPU_H
diff --git a/savevm.c b/savevm.c
index 8139bc7..3049aa1 100644
--- a/savevm.c
+++ b/savevm.c
@@ -72,6 +72,7 @@
#include qemu-common.h
#include hw/hw.h
#include hw/qdev.h
+#include hw/boards.h
#include net.h
#include monitor.h
#include sysemu.h
@@ -1461,6 +1462,16 @@ bool qemu_savevm_state_blocked(Monitor *mon)
return false;
}
+static inline int qemu_current_migration_format(void)
+{
+if (current_machine-migration_format) {
+return current_machine-migration_format;
+}
+
+/* No format specified, default to the latest. */
+return QEMU_VM_FILE_VERSION;
+}
+
int qemu_savevm_state_begin(Monitor *mon, QEMUFile *f, int blk_enable,
int shared)
{
@@ -1474,7 +1484,7 @@ int qemu_savevm_state_begin(Monitor *mon, QEMUFile *f,
int blk_enable,
}
qemu_put_be32(f, QEMU_VM_FILE_MAGIC);
-qemu_put_be32(f, QEMU_VM_FILE_VERSION);
+qemu_put_be32(f, qemu_current_migration_format());
QTAILQ_FOREACH(se, savevm_handlers, entry) {
int len;
@@ -1747,8 +1757,10 @@ int qemu_loadvm_state(QEMUFile *f)
fprintf(stderr, SaveVM v2 format is obsolete and don't work
anymore\n);
return -ENOTSUP;
}
-if (v != QEMU_VM_FILE_VERSION)
+if (v != qemu_current_migration_format()) {
+fprintf(stderr, Mismatching SaveVM format v%d\n, v);
return -ENOTSUP;
+}
while ((section_type = qemu_get_byte(f)) != QEMU_VM_EOF) {
uint32_t instance_id, version_id, section_id;
--
1.7.6
[Qemu-devel] [PATCH v2 0.15 0/4] Fix subsection ambiguity in the migration format
With the current migration format, VMS_STRUCTs with subsections are ambiguous. The protocol cannot tell whether a 0x5 byte after the VMS_STRUCT is a subsection or part of the parent data stream. In the past QEMU assumed it was always a part of a subsection; after commit eb60260 (savevm: fix corruption in vmstate_subsection_load(), 2011-02-03) the choice depends on whether the VMS_STRUCT has subsections defined. Unfortunately, this means that if a destination has no subsections defined for the struct, it will happily read subsection data into its own fields. And if you are lucky enough to stumble on a zero byte at the right time, it will be interpreted as QEMU_VM_EOF and migration will be interrupted with half-loaded state. There is no way out of this except defining an incompatible migration protocol. Not-so-long-term we should really try to define one that is not a joke, but the bug is serious so we need a solution for 0.15. A sentinel at the end of embedded structs does remove the ambiguity. Of course, this can be restricted to new machine models, and this is what the patch series does. (And note that only patch 3 is specific to the short-term solution, everything else is entirely generic). I am still proposing this for 0.15. Tested new on new, 0.14 on new pc-0.14, new pc-0.14 on 0.14; also for v1 the same combinations on RHEL. v1-v2: added qemu_current_migration_format() and QEMU_VM_FILE_VERSION_0_14. Paolo Bonzini (4): add support for machine models to specify their migration format add pc-0.14 machine savevm: define new unambiguous migration format Partially revert savevm: fix corruption in vmstate_subsection_load(). cpu-common.h |3 --- hw/boards.h |4 hw/pc_piix.c | 15 ++- qemu-common.h |3 +++ savevm.c | 46 -- 5 files changed, 53 insertions(+), 18 deletions(-) -- 1.7.6
[Qemu-devel] [PATCH v2 0.15 3/4] savevm: define new unambiguous migration format
With the current migration format, VMS_STRUCTs with subsections
are ambiguous. The protocol cannot tell whether a 0x5 byte after
the VMS_STRUCT is a subsection or part of the parent data stream.
In the past QEMU assumed it was always a part of a subsection; after
commit eb60260 (savevm: fix corruption in vmstate_subsection_load().,
2011-02-03) the choice depends on whether the VMS_STRUCT has subsections
defined.
Unfortunately, this means that if a destination has no subsections
defined for the struct, it will happily read subsection data into
its own fields. And if you are lucky enough to stumble on a
zero byte at the right time, it will be interpreted as QEMU_VM_EOF
and migration will be interrupted.
There is no way out of this except defining an incompatible
migration protocol with a sentinel at the end of embedded structs.
Of course, this is restricted to new machine models.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
hw/boards.h |3 +++
hw/pc_piix.c |5 +
savevm.c | 26 ++
3 files changed, 26 insertions(+), 8 deletions(-)
diff --git a/hw/boards.h b/hw/boards.h
index 560dbaf..1cca3ce 100644
--- a/hw/boards.h
+++ b/hw/boards.h
@@ -5,6 +5,9 @@
#include qdev.h
+#define QEMU_VM_FILE_VERSION_0_140x0003
+#define QEMU_VM_FILE_VERSION 0x0004
+
typedef void QEMUMachineInitFunc(ram_addr_t ram_size,
const char *boot_device,
const char *kernel_filename,
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index 61f8cbb..38818de 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -271,6 +271,7 @@ static QEMUMachine pc_machine_v0_14 = {
.desc = Standard PC,
.init = pc_init_pci,
.max_cpus = 255,
+.migration_format = QEMU_VM_FILE_VERSION_0_14,
};
static QEMUMachine pc_machine_v0_13 = {
@@ -278,6 +279,7 @@ static QEMUMachine pc_machine_v0_13 = {
.desc = Standard PC,
.init = pc_init_pci_no_kvmclock,
.max_cpus = 255,
+.migration_format = QEMU_VM_FILE_VERSION_0_14,
.compat_props = (GlobalProperty[]) {
{
.driver = virtio-9p-pci,
@@ -317,6 +319,7 @@ static QEMUMachine pc_machine_v0_12 = {
.desc = Standard PC,
.init = pc_init_pci_no_kvmclock,
.max_cpus = 255,
+.migration_format = QEMU_VM_FILE_VERSION_0_14,
.compat_props = (GlobalProperty[]) {
{
.driver = virtio-serial-pci,
@@ -360,6 +363,7 @@ static QEMUMachine pc_machine_v0_11 = {
.desc = Standard PC, qemu 0.11,
.init = pc_init_pci_no_kvmclock,
.max_cpus = 255,
+.migration_format = QEMU_VM_FILE_VERSION_0_14,
.compat_props = (GlobalProperty[]) {
{
.driver = virtio-blk-pci,
@@ -411,6 +415,7 @@ static QEMUMachine pc_machine_v0_10 = {
.desc = Standard PC, qemu 0.10,
.init = pc_init_pci_no_kvmclock,
.max_cpus = 255,
+.migration_format = QEMU_VM_FILE_VERSION_0_14,
.compat_props = (GlobalProperty[]) {
{
.driver = virtio-blk-pci,
diff --git a/savevm.c b/savevm.c
index 3049aa1..197af4b 100644
--- a/savevm.c
+++ b/savevm.c
@@ -158,6 +158,14 @@ void qemu_announce_self(void)
#define IO_BUF_SIZE 32768
+#define QEMU_VM_EOF 0x00
+#define QEMU_VM_SECTION_START0x01
+#define QEMU_VM_SECTION_PART 0x02
+#define QEMU_VM_SECTION_END 0x03
+#define QEMU_VM_SECTION_FULL 0x04
+#define QEMU_VM_SUBSECTION 0x05
+#define QEMU_VM_SUBSECTIONS_END 0x06
+
struct QEMUFile {
QEMUFilePutBufferFunc *put_buffer;
QEMUFileGetBufferFunc *get_buffer;
@@ -1348,6 +1356,12 @@ int vmstate_load_state(QEMUFile *f, const
VMStateDescription *vmsd,
}
if (field-flags VMS_STRUCT) {
ret = vmstate_load_state(f, field-vmsd, addr,
field-vmsd-version_id);
+if (!current_machine-migration_format ||
+current_machine-migration_format = 4) {
+if (qemu_get_byte(f) != QEMU_VM_SUBSECTIONS_END) {
+return -EINVAL;
+}
+}
} else {
ret = field-info-get(f, addr, size);
@@ -1410,6 +1424,10 @@ void vmstate_save_state(QEMUFile *f, const
VMStateDescription *vmsd,
}
if (field-flags VMS_STRUCT) {
vmstate_save_state(f, field-vmsd, addr);
+if (!current_machine-migration_format ||
+current_machine-migration_format = 4) {
+qemu_put_byte(f, QEMU_VM_SUBSECTIONS_END);
+}
} else {
field-info-put(f, addr, size);
}
@@ -1439,14 +1457,6 @@ static void vmstate_save(QEMUFile *f, SaveStateEntry *se)
#define QEMU_VM_FILE_MAGIC 0x5145564d
#define QEMU_VM_FILE_VERSION_COMPAT 0x0002
-#define
[Qemu-devel] [PATCH v2 0.15 4/4] Partially revert savevm: fix corruption in vmstate_subsection_load().
This reverts the additional check in commit eb60260d (but not the
assertions).
The new format does not require the check, and with the old format
it traded one kind of bogus failure for a different kind of silent
failure.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
savevm.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/savevm.c b/savevm.c
index 197af4b..c849914 100644
--- a/savevm.c
+++ b/savevm.c
@@ -1687,10 +1687,6 @@ static int vmstate_subsection_load(QEMUFile *f, const
VMStateDescription *vmsd,
{
const VMStateSubsection *sub = vmsd-subsections;
-if (!sub || !sub-needed) {
-return 0;
-}
-
while (qemu_peek_byte(f) == QEMU_VM_SUBSECTION) {
char idstr[256];
int ret;
--
1.7.6
[Qemu-devel] [PATCH 10/15] hw/nand: Writing to NAND can only clear bits
Writing to a NAND device cannot set bits, it can only clear them;
implement this rather than simply copying the data.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
hw/nand.c | 17 +
1 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/hw/nand.c b/hw/nand.c
index e6c551d..d068eb6 100644
--- a/hw/nand.c
+++ b/hw/nand.c
@@ -75,6 +75,15 @@ struct NANDFlashState {
uint32_t ioaddr_vmstate;
};
+static void mem_and(uint8_t *dest, const uint8_t *src, size_t n)
+{
+/* Like memcpy() but we logical-AND the data into the destination */
+int i;
+for (i = 0; i n; i++) {
+dest[i] = src[i];
+}
+}
+
# define NAND_NO_AUTOINCR 0x0001
# define NAND_BUSWIDTH_16 0x0002
# define NAND_NO_PADDING 0x0004
@@ -595,7 +604,7 @@ static void glue(nand_blk_write_, PAGE_SIZE)(NANDFlashState
*s)
return;
if (!s-bdrv) {
-memcpy(s-storage + PAGE_START(s-addr) + (s-addr PAGE_MASK) +
+mem_and(s-storage + PAGE_START(s-addr) + (s-addr PAGE_MASK) +
s-offset, s-io, s-iolen);
} else if (s-mem_oob) {
sector = SECTOR(s-addr);
@@ -606,10 +615,10 @@ static void glue(nand_blk_write_,
PAGE_SIZE)(NANDFlashState *s)
return;
}
-memcpy(iobuf + (soff | off), s-io, MIN(s-iolen, PAGE_SIZE - off));
+mem_and(iobuf + (soff | off), s-io, MIN(s-iolen, PAGE_SIZE - off));
if (off + s-iolen PAGE_SIZE) {
page = PAGE(s-addr);
-memcpy(s-storage + (page OOB_SHIFT), s-io + PAGE_SIZE - off,
+mem_and(s-storage + (page OOB_SHIFT), s-io + PAGE_SIZE - off,
MIN(OOB_SIZE, off + s-iolen - PAGE_SIZE));
}
@@ -624,7 +633,7 @@ static void glue(nand_blk_write_, PAGE_SIZE)(NANDFlashState
*s)
return;
}
-memcpy(iobuf + soff, s-io, s-iolen);
+mem_and(iobuf + soff, s-io, s-iolen);
if (bdrv_write(s-bdrv, sector, iobuf, PAGE_SECTORS + 2) == -1)
printf(%s: write error in sector % PRIu64 \n, __func__,
sector);
--
1.7.1
[Qemu-devel] [PATCH 14/15] onenand: Ignore zero writes to boot command space
From: Juha Riihimäki juha.riihim...@nokia.com Ignore zero writes to the boot command space; Linux will issue these in the powerdown/reset sequence. Signed-off-by: Juha Riihimäki juha.riihim...@nokia.com [Riku Voipio: Fixes and restructuring patchset] Signed-off-by: Riku Voipio riku.voi...@iki.fi [Peter Maydell: More fixes and cleanups for upstream submission] Signed-off-by: Peter Maydell peter.mayd...@linaro.org --- hw/onenand.c |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/hw/onenand.c b/hw/onenand.c index 9f02736..0edcfe2 100644 --- a/hw/onenand.c +++ b/hw/onenand.c @@ -550,6 +550,13 @@ static void onenand_write(void *opaque, target_phys_addr_t addr, s-boot[0][2 s-shift] = s-wpstatus 0xff; break; +case 0x: +/* ignore zero writes without error messages, + * linux omap2/3 kernel will issue these upon + * powerdown/reset sequence. + */ +break; + default: fprintf(stderr, %s: unknown OneNAND boot command %x\n, __FUNCTION__, value); -- 1.7.1
[Qemu-devel] [PATCH 06/15] hw/nand: Pass block device state to init function
Pass the BlockDeviceState to the nand_init() function rather
than having it look it up via drive_get() itself.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
hw/axis_dev88.c |6 +-
hw/flash.h |2 +-
hw/nand.c |8 ++--
hw/spitz.c |4 +++-
hw/tc6393xb.c |5 -
5 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/hw/axis_dev88.c b/hw/axis_dev88.c
index 0e2135a..de1f5a5 100644
--- a/hw/axis_dev88.c
+++ b/hw/axis_dev88.c
@@ -30,6 +30,7 @@
#include loader.h
#include elf.h
#include cris-boot.h
+#include blockdev.h
#define D(x)
#define DNAND(x)
@@ -251,6 +252,7 @@ void axisdev88_init (ram_addr_t ram_size,
CPUState *env;
DeviceState *dev;
SysBusDevice *s;
+DriveInfo *nand;
qemu_irq irq[30], nmi[2], *cpu_irq;
void *etraxfs_dmac;
struct etraxfs_dma_client *eth[2] = {NULL, NULL};
@@ -278,7 +280,9 @@ void axisdev88_init (ram_addr_t ram_size,
/* Attach a NAND flash to CS1. */
-nand_state.nand = nand_init(NAND_MFR_STMICRO, 0x39);
+nand = drive_get(IF_MTD, 0, 0);
+nand_state.nand = nand_init(nand ? nand-bdrv : NULL,
+NAND_MFR_STMICRO, 0x39);
nand_regs = cpu_register_io_memory(nand_read, nand_write, nand_state,
DEVICE_NATIVE_ENDIAN);
cpu_register_physical_memory(0x1000, 0x0500, nand_regs);
diff --git a/hw/flash.h b/hw/flash.h
index c22e1a9..a992bb8 100644
--- a/hw/flash.h
+++ b/hw/flash.h
@@ -19,7 +19,7 @@ pflash_t *pflash_cfi02_register(target_phys_addr_t base,
ram_addr_t off,
/* nand.c */
typedef struct NANDFlashState NANDFlashState;
-NANDFlashState *nand_init(int manf_id, int chip_id);
+NANDFlashState *nand_init(BlockDriverState *bdrv, int manf_id, int chip_id);
void nand_done(NANDFlashState *s);
void nand_setpins(NANDFlashState *s, uint8_t cle, uint8_t ale,
uint8_t ce, uint8_t wp, uint8_t gnd);
diff --git a/hw/nand.c b/hw/nand.c
index 37e51d7..d6204d9 100644
--- a/hw/nand.c
+++ b/hw/nand.c
@@ -14,7 +14,6 @@
# include hw.h
# include flash.h
# include blockdev.h
-/* FIXME: Pass block device as an argument. */
# define NAND_CMD_READ00x00
# define NAND_CMD_READ10x01
@@ -451,20 +450,17 @@ uint8_t nand_getio(NANDFlashState *s)
return *(s-ioaddr ++);
}
-NANDFlashState *nand_init(int manf_id, int chip_id)
+NANDFlashState *nand_init(BlockDriverState *bdrv, int manf_id, int chip_id)
{
int pagesize;
NANDFlashState *s;
-DriveInfo *dinfo;
if (nand_flash_ids[chip_id].size == 0) {
hw_error(%s: Unsupported NAND chip ID.\n, __FUNCTION__);
}
s = (NANDFlashState *) qemu_mallocz(sizeof(NANDFlashState));
-dinfo = drive_get(IF_MTD, 0, 0);
-if (dinfo)
-s-bdrv = dinfo-bdrv;
+s-bdrv = bdrv;
s-manf_id = manf_id;
s-chip_id = chip_id;
s-size = nand_flash_ids[s-chip_id].size 20;
diff --git a/hw/spitz.c b/hw/spitz.c
index 006f7a9..78e9c34 100644
--- a/hw/spitz.c
+++ b/hw/spitz.c
@@ -169,11 +169,13 @@ static void sl_flash_register(PXA2xxState *cpu, int size)
static int sl_nand_init(SysBusDevice *dev) {
int iomemtype;
SLNANDState *s;
+DriveInfo *nand;
s = FROM_SYSBUS(SLNANDState, dev);
s-ctl = 0;
-s-nand = nand_init(s-manf_id, s-chip_id);
+nand = drive_get(IF_MTD, 0, 0);
+s-nand = nand_init(nand ? nand-bdrv : NULL, s-manf_id, s-chip_id);
iomemtype = cpu_register_io_memory(sl_readfn,
sl_writefn, s, DEVICE_NATIVE_ENDIAN);
diff --git a/hw/tc6393xb.c b/hw/tc6393xb.c
index ed49e94..4de0819 100644
--- a/hw/tc6393xb.c
+++ b/hw/tc6393xb.c
@@ -12,6 +12,7 @@
#include flash.h
#include console.h
#include pixel_ops.h
+#include blockdev.h
#define IRQ_TC6393_NAND0
#define IRQ_TC6393_MMC 1
@@ -566,6 +567,7 @@ TC6393xbState *tc6393xb_init(uint32_t base, qemu_irq irq)
{
int iomemtype;
TC6393xbState *s;
+DriveInfo *nand;
CPUReadMemoryFunc * const tc6393xb_readfn[] = {
tc6393xb_readb,
tc6393xb_readw,
@@ -586,7 +588,8 @@ TC6393xbState *tc6393xb_init(uint32_t base, qemu_irq irq)
s-sub_irqs = qemu_allocate_irqs(tc6393xb_sub_irq, s, TC6393XB_NR_IRQS);
-s-flash = nand_init(NAND_MFR_TOSHIBA, 0x76);
+nand = drive_get(IF_MTD, 0, 0);
+s-flash = nand_init(nand ? nand-bdrv : NULL, NAND_MFR_TOSHIBA, 0x76);
iomemtype = cpu_register_io_memory(tc6393xb_readfn,
tc6393xb_writefn, s, DEVICE_NATIVE_ENDIAN);
--
1.7.1
[Qemu-devel] [PATCH 04/15] hw/omap_gpio.c: Convert to qdev
From: Juha Riihimäki juha.riihim...@nokia.com
Convert the OMAP GPIO module to qdev.
Signed-off-by: Juha Riihimäki juha.riihim...@nokia.com
[Riku Voipio: Fixes and restructuring patchset]
Signed-off-by: Riku Voipio riku.voi...@iki.fi
[Peter Maydell: More fixes and cleanups for upstream submission]
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
hw/nseries.c | 47 +-
hw/omap.h | 20 +
hw/omap1.c | 10 ++-
hw/omap2.c | 34 ++--
hw/omap_gpio.c | 259 ---
hw/palm.c | 26 +++---
6 files changed, 220 insertions(+), 176 deletions(-)
diff --git a/hw/nseries.c b/hw/nseries.c
index 2f84f53..32f2f53 100644
--- a/hw/nseries.c
+++ b/hw/nseries.c
@@ -134,9 +134,9 @@ static void n800_mmc_cs_cb(void *opaque, int line, int
level)
static void n8x0_gpio_setup(struct n800_s *s)
{
qemu_irq *mmc_cs = qemu_allocate_irqs(n800_mmc_cs_cb, s-cpu-mmc, 1);
-omap2_gpio_out_set(s-cpu-gpif, N8X0_MMC_CS_GPIO, mmc_cs[0]);
+qdev_connect_gpio_out(s-cpu-gpio, N8X0_MMC_CS_GPIO, mmc_cs[0]);
-qemu_irq_lower(omap2_gpio_in_get(s-cpu-gpif, N800_BAT_COVER_GPIO)[0]);
+qemu_irq_lower(qdev_get_gpio_in(s-cpu-gpio, N800_BAT_COVER_GPIO));
}
#define MAEMO_CAL_HEADER(...) \
@@ -168,8 +168,8 @@ static void n8x0_nand_setup(struct n800_s *s)
omap_gpmc_attach(s-cpu-gpmc, N8X0_ONENAND_CS, 0, onenand_base_update,
onenand_base_unmap,
(s-nand = onenand_init(0xec4800, 1,
-omap2_gpio_in_get(s-cpu-gpif,
-N8X0_ONENAND_GPIO)[0])));
+qdev_get_gpio_in(s-cpu-gpio,
+N8X0_ONENAND_GPIO;
otp_region = onenand_raw_otp(s-nand);
memcpy(otp_region + 0x000, n8x0_cal_wlan_mac, sizeof(n8x0_cal_wlan_mac));
@@ -180,7 +180,7 @@ static void n8x0_nand_setup(struct n800_s *s)
static void n8x0_i2c_setup(struct n800_s *s)
{
DeviceState *dev;
-qemu_irq tmp_irq = omap2_gpio_in_get(s-cpu-gpif, N8X0_TMP105_GPIO)[0];
+qemu_irq tmp_irq = qdev_get_gpio_in(s-cpu-gpio, N8X0_TMP105_GPIO);
/* Attach the CPU on one end of our I2C bus. */
s-i2c = omap_i2c_bus(s-cpu-i2c[0]);
@@ -249,8 +249,8 @@ static void n800_tsc_kbd_setup(struct n800_s *s)
/* XXX: are the three pins inverted inside the chip between the
* tsc and the cpu (N4111)? */
qemu_irq penirq = NULL;/* NC */
-qemu_irq kbirq = omap2_gpio_in_get(s-cpu-gpif, N800_TSC_KP_IRQ_GPIO)[0];
-qemu_irq dav = omap2_gpio_in_get(s-cpu-gpif, N800_TSC_TS_GPIO)[0];
+qemu_irq kbirq = qdev_get_gpio_in(s-cpu-gpio, N800_TSC_KP_IRQ_GPIO);
+qemu_irq dav = qdev_get_gpio_in(s-cpu-gpio, N800_TSC_TS_GPIO);
s-ts.chip = tsc2301_init(penirq, kbirq, dav);
s-ts.opaque = s-ts.chip-opaque;
@@ -269,7 +269,7 @@ static void n800_tsc_kbd_setup(struct n800_s *s)
static void n810_tsc_setup(struct n800_s *s)
{
-qemu_irq pintdav = omap2_gpio_in_get(s-cpu-gpif, N810_TSC_TS_GPIO)[0];
+qemu_irq pintdav = qdev_get_gpio_in(s-cpu-gpio, N810_TSC_TS_GPIO);
s-ts.opaque = tsc2005_init(pintdav);
s-ts.txrx = tsc2005_txrx;
@@ -361,7 +361,7 @@ static int n810_keys[0x80] = {
static void n810_kbd_setup(struct n800_s *s)
{
-qemu_irq kbd_irq = omap2_gpio_in_get(s-cpu-gpif, N810_KEYBOARD_GPIO)[0];
+qemu_irq kbd_irq = qdev_get_gpio_in(s-cpu-gpio, N810_KEYBOARD_GPIO);
DeviceState *dev;
int i;
@@ -726,15 +726,15 @@ static void n8x0_dss_setup(struct n800_s *s)
static void n8x0_cbus_setup(struct n800_s *s)
{
-qemu_irq dat_out = omap2_gpio_in_get(s-cpu-gpif, N8X0_CBUS_DAT_GPIO)[0];
-qemu_irq retu_irq = omap2_gpio_in_get(s-cpu-gpif, N8X0_RETU_GPIO)[0];
-qemu_irq tahvo_irq = omap2_gpio_in_get(s-cpu-gpif, N8X0_TAHVO_GPIO)[0];
+qemu_irq dat_out = qdev_get_gpio_in(s-cpu-gpio, N8X0_CBUS_DAT_GPIO);
+qemu_irq retu_irq = qdev_get_gpio_in(s-cpu-gpio, N8X0_RETU_GPIO);
+qemu_irq tahvo_irq = qdev_get_gpio_in(s-cpu-gpio, N8X0_TAHVO_GPIO);
CBus *cbus = cbus_init(dat_out);
-omap2_gpio_out_set(s-cpu-gpif, N8X0_CBUS_CLK_GPIO, cbus-clk);
-omap2_gpio_out_set(s-cpu-gpif, N8X0_CBUS_DAT_GPIO, cbus-dat);
-omap2_gpio_out_set(s-cpu-gpif, N8X0_CBUS_SEL_GPIO, cbus-sel);
+qdev_connect_gpio_out(s-cpu-gpio, N8X0_CBUS_CLK_GPIO, cbus-clk);
+qdev_connect_gpio_out(s-cpu-gpio, N8X0_CBUS_DAT_GPIO, cbus-dat);
+qdev_connect_gpio_out(s-cpu-gpio, N8X0_CBUS_SEL_GPIO, cbus-sel);
cbus_attach(cbus, s-retu = retu_init(retu_irq, 1));
cbus_attach(cbus, s-tahvo = tahvo_init(tahvo_irq, 1));
@@ -743,13 +743,12 @@ static void n8x0_cbus_setup(struct n800_s *s)
static void n8x0_uart_setup(struct n800_s *s)
{
CharDriverState *radio = uart_hci_init(
-omap2_gpio_in_get(s-cpu-gpif,
-
[Qemu-devel] [PATCH 07/15] hw/nand: Support large NAND devices
From: Juha Riihimäki juha.riihim...@nokia.com
Add support for NAND devices of over 1Gb.
Signed-off-by: Juha Riihimäki juha.riihim...@nokia.com
[Riku Voipio: Fixes and restructuring patchset]
Signed-off-by: Riku Voipio riku.voi...@iki.fi
[Peter Maydell: More fixes and cleanups for upstream submission]
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
hw/nand.c | 48 +++-
1 files changed, 27 insertions(+), 21 deletions(-)
diff --git a/hw/nand.c b/hw/nand.c
index d6204d9..18aa226 100644
--- a/hw/nand.c
+++ b/hw/nand.c
@@ -6,6 +6,10 @@
* Copyright (c) 2006 Openedhand Ltd.
* Written by Andrzej Zaborowski bal...@zabor.org
*
+ * Support for additional features based on MT29F2G16ABCWP 2Gx16
+ * datasheet from Micron Technology and NAND02G-B2C datasheet
+ * from ST Microelectronics.
+ *
* This code is licensed under the GNU GPL v2.
*/
@@ -57,14 +61,15 @@ struct NANDFlashState {
uint8_t *ioaddr;
int iolen;
-uint32_t cmd, addr;
+uint32_t cmd;
+uint64_t addr;
int addrlen;
int status;
int offset;
void (*blk_write)(NANDFlashState *s);
void (*blk_erase)(NANDFlashState *s);
-void (*blk_load)(NANDFlashState *s, uint32_t addr, int offset);
+void (*blk_load)(NANDFlashState *s, uint64_t addr, int offset);
uint32_t ioaddr_vmstate;
};
@@ -318,7 +323,7 @@ static const VMStateDescription vmstate_nand = {
VMSTATE_UINT32(ioaddr_vmstate, NANDFlashState),
VMSTATE_INT32(iolen, NANDFlashState),
VMSTATE_UINT32(cmd, NANDFlashState),
-VMSTATE_UINT32(addr, NANDFlashState),
+VMSTATE_UINT64(addr, NANDFlashState),
VMSTATE_INT32(addrlen, NANDFlashState),
VMSTATE_INT32(status, NANDFlashState),
VMSTATE_INT32(offset, NANDFlashState),
@@ -432,7 +437,7 @@ uint8_t nand_getio(NANDFlashState *s)
/* Allow sequential reading */
if (!s-iolen s-cmd == NAND_CMD_READ0) {
-offset = (s-addr ((1 s-addr_shift) - 1)) + s-offset;
+offset = (int)(s-addr ((1 s-addr_shift) - 1)) + s-offset;
s-offset = 0;
s-blk_load(s, s-addr, offset);
@@ -526,7 +531,7 @@ void nand_done(NANDFlashState *s)
/* Program a single page */
static void glue(nand_blk_write_, PAGE_SIZE)(NANDFlashState *s)
{
-uint32_t off, page, sector, soff;
+uint64_t off, page, sector, soff;
uint8_t iobuf[(PAGE_SECTORS + 2) * 0x200];
if (PAGE(s-addr) = s-pages)
return;
@@ -539,7 +544,7 @@ static void glue(nand_blk_write_, PAGE_SIZE)(NANDFlashState
*s)
off = (s-addr PAGE_MASK) + s-offset;
soff = SECTOR_OFFSET(s-addr);
if (bdrv_read(s-bdrv, sector, iobuf, PAGE_SECTORS) == -1) {
-printf(%s: read error in sector %i\n, __FUNCTION__, sector);
+printf(%s: read error in sector % PRIu64 \n, __func__, sector);
return;
}
@@ -551,20 +556,20 @@ static void glue(nand_blk_write_,
PAGE_SIZE)(NANDFlashState *s)
}
if (bdrv_write(s-bdrv, sector, iobuf, PAGE_SECTORS) == -1)
-printf(%s: write error in sector %i\n, __FUNCTION__, sector);
+printf(%s: write error in sector % PRIu64 \n, __func__,
sector);
} else {
off = PAGE_START(s-addr) + (s-addr PAGE_MASK) + s-offset;
sector = off 9;
soff = off 0x1ff;
if (bdrv_read(s-bdrv, sector, iobuf, PAGE_SECTORS + 2) == -1) {
-printf(%s: read error in sector %i\n, __FUNCTION__, sector);
+printf(%s: read error in sector % PRIu64 \n, __func__, sector);
return;
}
memcpy(iobuf + soff, s-io, s-iolen);
if (bdrv_write(s-bdrv, sector, iobuf, PAGE_SECTORS + 2) == -1)
-printf(%s: write error in sector %i\n, __FUNCTION__, sector);
+printf(%s: write error in sector % PRIu64 \n, __func__,
sector);
}
s-offset = 0;
}
@@ -572,7 +577,7 @@ static void glue(nand_blk_write_, PAGE_SIZE)(NANDFlashState
*s)
/* Erase a single block */
static void glue(nand_blk_erase_, PAGE_SIZE)(NANDFlashState *s)
{
-uint32_t i, page, addr;
+uint64_t i, page, addr;
uint8_t iobuf[0x200] = { [0 ... 0x1ff] = 0xff, };
addr = s-addr ~((1 (ADDR_SHIFT + s-erase_shift)) - 1);
@@ -589,34 +594,35 @@ static void glue(nand_blk_erase_,
PAGE_SIZE)(NANDFlashState *s)
page = SECTOR(addr + (ADDR_SHIFT + s-erase_shift));
for (; i page; i ++)
if (bdrv_write(s-bdrv, i, iobuf, 1) == -1)
-printf(%s: write error in sector %i\n, __FUNCTION__, i);
+printf(%s: write error in sector % PRIu64 \n, __func__, i);
} else {
addr = PAGE_START(addr);
page = addr 9;
if (bdrv_read(s-bdrv, page, iobuf, 1) == -1)
-printf(%s: read error in sector %i\n, __FUNCTION__, page);
+printf(%s: read error in sector % PRIu64 \n, __func__, page);
memset(iobuf + (addr 0x1ff),
Re: [Qemu-devel] [PATCH] MAINTAINERS: add entry for Xen
Am 29.07.2011 um 17:05 schrieb stefano.stabell...@eu.citrix.com: From: Stefano Stabellini stefano.stabell...@eu.citrix.com Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com Acked-by: Alexander Graf ag...@suse.de :) Alex --- MAINTAINERS | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 6115e4e..273a6a7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -143,6 +143,16 @@ L: k...@vger.kernel.org S: Supported F: target-i386/kvm.c +Guest CPU Cores (Xen): +-- + +X86 +M: Stefano Stabellini stefano.stabell...@eu.citrix.com +L: xen-de...@lists.xensource.com +S: Supported +F: xen-* +F: */xen* + ARM Machines Gumstix -- 1.7.2.3
[Qemu-devel] [PATCH 15/15] hw/onenand: program actions can only clear bits
From: Juha Riihimäki juha.riihim...@nokia.com
The program actions onenand_prog_main() and onenand_prog_spare()
can only set bits.
This implies a rewrite of onenand_erase() to not use the program
functions, since erase does need to set bits.
Signed-off-by: Juha Riihimäki juha.riihim...@nokia.com
[Riku Voipio: Fixes and restructuring patchset]
Signed-off-by: Riku Voipio riku.voi...@iki.fi
[Peter Maydell: More fixes and cleanups for upstream submission]
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
hw/onenand.c | 135 +
1 files changed, 106 insertions(+), 29 deletions(-)
diff --git a/hw/onenand.c b/hw/onenand.c
index 0edcfe2..981d23c 100644
--- a/hw/onenand.c
+++ b/hw/onenand.c
@@ -179,14 +179,39 @@ static inline int onenand_load_main(OneNANDState *s, int
sec, int secn,
static inline int onenand_prog_main(OneNANDState *s, int sec, int secn,
void *src)
{
-if (s-bdrv_cur)
-return bdrv_write(s-bdrv_cur, sec, src, secn) 0;
-else if (sec + secn s-secs_cur)
-return 1;
-
-memcpy(s-current + (sec 9), src, secn 9);
+int result = 0;
+
+if (secn 0) {
+uint32_t size = (uint32_t)secn * 512;
+const uint8_t *sp = (const uint8_t *)src;
+uint8_t *dp = 0;
+if (s-bdrv_cur) {
+dp = qemu_malloc(size);
+if (!dp || bdrv_read(s-bdrv_cur, sec, dp, secn) 0) {
+result = 1;
+}
+} else {
+if (sec + secn s-secs_cur) {
+result = 1;
+} else {
+dp = (uint8_t *)s-current + (sec 9);
+}
+}
+if (!result) {
+uint32_t i;
+for (i = 0; i size; i++) {
+dp[i] = sp[i];
+}
+if (s-bdrv_cur) {
+result = bdrv_write(s-bdrv_cur, sec, dp, secn) 0;
+}
+}
+if (dp s-bdrv_cur) {
+qemu_free(dp);
+}
+}
-return 0;
+return result;
}
static inline int onenand_load_spare(OneNANDState *s, int sec, int secn,
@@ -209,35 +234,87 @@ static inline int onenand_load_spare(OneNANDState *s, int
sec, int secn,
static inline int onenand_prog_spare(OneNANDState *s, int sec, int secn,
void *src)
{
-uint8_t buf[512];
-
-if (s-bdrv_cur) {
-if (bdrv_read(s-bdrv_cur, s-secs_cur + (sec 5), buf, 1) 0)
-return 1;
-memcpy(buf + ((sec 31) 4), src, secn 4);
-return bdrv_write(s-bdrv_cur, s-secs_cur + (sec 5), buf, 1) 0;
-} else if (sec + secn s-secs_cur)
-return 1;
-
-memcpy(s-current + (s-secs_cur 9) + (sec 4), src, secn 4);
-
-return 0;
+int result = 0;
+if (secn 0) {
+const uint8_t *sp = (const uint8_t *)src;
+uint8_t *dp = 0, *dpp = 0;
+if (s-bdrv_cur) {
+dp = qemu_malloc(512);
+if (!dp || bdrv_read(s-bdrv_cur,
+ s-secs_cur + (sec 5),
+ dp, 1) 0) {
+result = 1;
+} else {
+dpp = dp + ((sec 31) 4);
+}
+} else {
+if (sec + secn s-secs_cur) {
+result = 1;
+} else {
+dpp = s-current + (s-secs_cur 9) + (sec 4);
+}
+}
+if (!result) {
+uint32_t i;
+for (i = 0; i (secn 4); i++) {
+dpp[i] = sp[i];
+}
+if (s-bdrv_cur) {
+result = bdrv_write(s-bdrv_cur, s-secs_cur + (sec 5),
+dp, 1) 0;
+}
+}
+if (dp) {
+qemu_free(dp);
+}
+}
+return result;
}
static inline int onenand_erase(OneNANDState *s, int sec, int num)
{
-/* TODO: optimise */
-uint8_t buf[512];
-
-memset(buf, 0xff, sizeof(buf));
-for (; num 0; num --, sec ++) {
-if (onenand_prog_main(s, sec, 1, buf))
-return 1;
-if (onenand_prog_spare(s, sec, 1, buf))
-return 1;
+uint8_t *blankbuf, *tmpbuf;
+blankbuf = qemu_malloc(512);
+if (!blankbuf) {
+return 1;
+}
+tmpbuf = qemu_malloc(512);
+if (!tmpbuf) {
+qemu_free(blankbuf);
+return 1;
+}
+memset(blankbuf, 0xff, 512);
+for (; num 0; num--, sec++) {
+if (s-bdrv_cur) {
+int erasesec = s-secs_cur + (sec 5);
+if (bdrv_write(s-bdrv_cur, sec, blankbuf, 1)) {
+goto fail;
+}
+if (bdrv_read(s-bdrv_cur, erasesec, tmpbuf, 1) 0) {
+goto fail;
+}
+memcpy(tmpbuf + ((sec 31) 4), blankbuf, 1 4);
+if (bdrv_write(s-bdrv_cur, erasesec, tmpbuf, 1) 0) {
+goto fail;
+}
+} else {
+if (sec + 1 s-secs_cur) {
+goto fail;
+
Re: [Qemu-devel] [PULL] non-migratable devices
On 07/20/2011 05:09 AM, Gerd Hoffmann wrote: Hi, This patch series adds an easy way to tag devices as non-migratable and puts it into use for ahci, ehci and a number of usb devices. Pulled. Thanks. Regards, Anthony Liguori cheers, Gerd The following changes since commit 03ff09580ef6cbc4a893b6e3e6bbff33180ec70a: Merge remote-tracking branch 'agraf/xen-next' into staging (2011-07-19 08:04:35 -0500) are available in the git repository at: git://git.kraxel.org/qemu migration.1 Gerd Hoffmann (9): vmstate: add no_migrate flag to VMStateDescription vmstate: complain about devices without vmstate ahci doesn't support migration ehci doesn't support migration usb storage: first migration support bits. usb-wacom doesn't support migration usb-bt doesn't support migration usb-net doesn't support migration usb-serial doesn't support migration hw/hw.h |3 +++ hw/ide/ich.c|6 ++ hw/qdev.c |7 ++- hw/usb-bt.c |6 ++ hw/usb-ehci.c |7 +++ hw/usb-msd.c| 12 hw/usb-net.c|6 ++ hw/usb-serial.c |7 +++ hw/usb-wacom.c |6 ++ savevm.c|1 + 10 files changed, 60 insertions(+), 1 deletions(-)
Re: [Qemu-devel] [PULL] libcacard AFE support and bug fixes
On 07/22/2011 10:08 AM, Alon Levy wrote: Hi, Please pull fixes for AFE smart cards, cleanup and missing frees by Robert Relyea and Christophe Fergeau. Thanks. The following changes since commit d1afc48b7cfdb4490f322d5d82a2aae6d545ec06: SPARC64: implement addtional MMU faults related to nonfaulting load (2011-07-21 20:02:22 +) are available in the git repository at: git://anongit.freedesktop.org/~alon/qemu pull-libcacard.afe Pulled. Thanks. Regards, Anthony Liguori Christophe Fergeau (5): libcacard: don't leak vcard_emul_alloc_arrays mem libcacard: s/strip(args++)/strip(args+1) libcacard: fix soft=... parsing in vcard_emul_options libcacard: introduce NEXT_TOKEN macro libcacard: replace copy_string with strndup Robert Relyea (1): libcacard/vcard_emul_nss: support cards lying about CKM_RSA_X_509 support libcacard/vcard_emul_nss.c | 257 +++- 1 files changed, 182 insertions(+), 75 deletions(-) Alon
Re: [Qemu-devel] [PULL v2] Trivial patches for June 25 to July 27 2011
On 07/27/2011 10:14 AM, Stefan Hajnoczi wrote: Quick update: I have dropped the superfluous Makefile: fix out-of-tree builds patch. The following changes since commit c886edfb851c0c590d4e77f058f2ec8ed95ad1b5: Let users select their pythons (2011-07-25 16:50:12 +) are available in the git repository at: ssh://repo.or.cz/srv/git/qemu/stefanha.git trivial-patches Pulled. Thanks. Regards, Anthony Liguori Alexandre Raymond (1): Makefile: Minor cscope fixups Juan Quintela (1): xen_mapcache: remove unused variable Michael Roth (1): Makefile: add missing deps on $(GENERATED_HEADERS) Stefan Weil (1): slirp: Fix unusual comments in unused code Wolfgang Mauerer (1): vhost build fix for i386 Zhi Yong Wu (1): qmp: fix efect - effect typo in qmp-commands.hx Makefile |6 -- configure| 23 +++ qmp-commands.hx |2 +- slirp/ip_input.c |4 ++-- xen-mapcache.c |3 +-- 5 files changed, 31 insertions(+), 7 deletions(-)
Re: [Qemu-devel] [PULL 0/9] xen patch queue 2011-07-26
On 07/27/2011 08:30 AM, Alexander Graf wrote: Hi Anthony, This is my current patch queue for xen. Please pull. Alex The following changes since commit c886edfb851c0c590d4e77f058f2ec8ed95ad1b5: Blue Swirl (1): Let users select their pythons are available in the git repository at: git://repo.or.cz/qemu/agraf.git xen-next Pulled. Thanks. Regards, Anthony Liguori Alexander Graf (2): xen: remove CONFIG_XEN_MAPCACHE xen: make xen_enabled even more clever Anthony PERARD (6): xen: introduce xen_change_state_handler xen: Fix xen_enabled(). exec.c: Use ram_addr_t in cpu_physical_memory_rw(...). cpu-common: Have a ram_addr_t of uint64 with Xen. xen: Fix the memory registration to reflect of what is done by Xen. vl.c: Check the asked ram_size later. Stefano Stabellini (1): xen: implement unplug protocol in xen_platform configure |8 -- cpu-common.h |8 +++ exec.c| 13 ++- hw/ide.h |1 + hw/ide/piix.c | 44 +++ hw/pc_piix.c |6 - hw/xen.h |2 +- hw/xen_platform.c | 43 +- vl.c | 16 +- xen-all.c | 54 ++-- 10 files changed, 162 insertions(+), 33 deletions(-)
Re: [Qemu-devel] [PATCH 5/9] usb storage: first migration support bits.
On 07/20/2011 12:09 PM, Gerd Hoffmann wrote: Tag vmstate as unmigratable for the time being, to be removed when mgration support is finished. I'm going to handle this at the SCSI level by canceling all transactions on pre-load. Expect patches next week. Paolo
Re: [Qemu-devel] [PATCH 6/9] usb-wacom doesn't support migration
On 07/20/2011 12:09 PM, Gerd Hoffmann wrote:
Signed-off-by: Gerd Hoffmannkra...@redhat.com
---
hw/usb-wacom.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/hw/usb-wacom.c b/hw/usb-wacom.c
index 9d348e1..d76ee97 100644
--- a/hw/usb-wacom.c
+++ b/hw/usb-wacom.c
@@ -349,6 +349,11 @@ static int usb_wacom_initfn(USBDevice *dev)
return 0;
}
+static const VMStateDescription vmstate_usb_wacom = {
+.name = usb-wacom,
+.unmigratable = 1,
+};
+
static struct USBDeviceInfo wacom_info = {
.product_desc = QEMU PenPartner Tablet,
.qdev.name = usb-wacom-tablet,
@@ -356,6 +361,7 @@ static struct USBDeviceInfo wacom_info = {
.usbdevice_name = wacom-tablet,
.usb_desc =desc_wacom,
.qdev.size = sizeof(USBWacomState),
+.qdev.vmsd =vmstate_usb_wacom,
.init = usb_wacom_initfn,
.handle_packet = usb_generic_handle_packet,
.handle_reset = usb_wacom_handle_reset,
Since usb_wacom does not support auto-wakeup, it should actually kinda
sorta work like usb-tablet used to, right?
Paolo
[Qemu-devel] [PATCH 03/15] hw/omap_clk: Add the clock for the OMAP2430-specific fifth GPIO module
The OMAP2430 has a fifth GPIO module which earlier OMAP2 models lack; add
the clock definition for it.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
hw/omap_clk.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/hw/omap_clk.c b/hw/omap_clk.c
index 6bcabef..577b326 100644
--- a/hw/omap_clk.c
+++ b/hw/omap_clk.c
@@ -836,7 +836,7 @@ static struct clk i2c2_iclk = {
.parent= core_l4_iclk,
};
-static struct clk gpio_dbclk[4] = {
+static struct clk gpio_dbclk[5] = {
{
.name = gpio1_dbclk,
.flags = CLOCK_IN_OMAP242X | CLOCK_IN_OMAP243X,
@@ -853,6 +853,10 @@ static struct clk gpio_dbclk[4] = {
.name = gpio4_dbclk,
.flags = CLOCK_IN_OMAP242X | CLOCK_IN_OMAP243X,
.parent= wu_32k_clk,
+}, {
+.name = gpio5_dbclk,
+.flags = CLOCK_IN_OMAP243X,
+.parent = wu_32k_clk,
},
};
--
1.7.1
[Qemu-devel] [PATCH 13/15] onenand: Handle various ID fields separately
From: Juha Riihimäki juha.riihim...@nokia.com
Handle the manufacturer, device and version IDs separately rather than
smooshing them all together into a single uint32_t. Note that the ID
registers are actually 16 bit, even though typically the top bits are 0
and the Read Identification Data command only returns the bottom 8 bits.
Signed-off-by: Juha Riihimäki juha.riihim...@nokia.com
[Riku Voipio: Fixes and restructuring patchset]
Signed-off-by: Riku Voipio riku.voi...@iki.fi
[Peter Maydell: More fixes and cleanups for upstream submission]
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
hw/flash.h |3 ++-
hw/nseries.c |5 +++--
hw/onenand.c | 29 ++---
3 files changed, 23 insertions(+), 14 deletions(-)
diff --git a/hw/flash.h b/hw/flash.h
index 1aae43d..1064fd0 100644
--- a/hw/flash.h
+++ b/hw/flash.h
@@ -38,7 +38,8 @@ uint32_t nand_getbuswidth(DeviceState *dev);
/* onenand.c */
void onenand_base_update(void *opaque, target_phys_addr_t new);
void onenand_base_unmap(void *opaque);
-void *onenand_init(BlockDriverState *bdrv, uint32_t id,
+void *onenand_init(BlockDriverState *bdrv,
+ uint16_t man_id, uint16_t dev_id, uint16_t ver_id,
int regshift, qemu_irq irq);
void *onenand_raw_otp(void *opaque);
diff --git a/hw/nseries.c b/hw/nseries.c
index 96cc490..7cdba25 100644
--- a/hw/nseries.c
+++ b/hw/nseries.c
@@ -167,8 +167,9 @@ static void n8x0_nand_setup(struct n800_s *s)
DriveInfo *dinfo;
dinfo = drive_get(IF_MTD, 0, 0);
-/* Either ec40xx or ec48xx are OK for the ID */
-s-nand = onenand_init(dinfo ? dinfo-bdrv : 0, 0xec4800, 1,
+/* Either 0x40 or 0x48 are OK for the device ID */
+s-nand = onenand_init(dinfo ? dinfo-bdrv : 0,
+ NAND_MFR_SAMSUNG, 0x48, 0, 1,
qdev_get_gpio_in(s-cpu-gpio, N8X0_ONENAND_GPIO));
omap_gpmc_attach(s-cpu-gpmc, N8X0_ONENAND_CS, 0, onenand_base_update,
onenand_base_unmap, s-nand);
diff --git a/hw/onenand.c b/hw/onenand.c
index 3a19d7f..9f02736 100644
--- a/hw/onenand.c
+++ b/hw/onenand.c
@@ -31,7 +31,11 @@
#define BLOCK_SHIFT(PAGE_SHIFT + 6)
typedef struct {
-uint32_t id;
+struct {
+uint16_t man;
+uint16_t dev;
+uint16_t ver;
+} id;
int shift;
target_phys_addr_t base;
qemu_irq intr;
@@ -453,12 +457,12 @@ static uint32_t onenand_read(void *opaque,
target_phys_addr_t addr)
return lduw_le_p(s-boot[0] + addr);
case 0xf000: /* Manufacturer ID */
-return (s-id 16) 0xff;
+return s-id.man;
case 0xf001: /* Device ID */
-return (s-id 8) 0xff;
-/* TODO: get the following values from a real chip! */
+return s-id.dev;
case 0xf002: /* Version ID */
-return (s-id 0) 0xff;
+return s-id.ver;
+/* TODO: get the following values from a real chip! */
case 0xf003: /* Data Buffer size */
return 1 PAGE_SHIFT;
case 0xf004: /* Boot Buffer size */
@@ -541,8 +545,8 @@ static void onenand_write(void *opaque, target_phys_addr_t
addr,
case 0x0090: /* Read Identification Data */
memset(s-boot[0], 0, 3 s-shift);
-s-boot[0][0 s-shift] = (s-id 16) 0xff;
-s-boot[0][1 s-shift] = (s-id 8) 0xff;
+s-boot[0][0 s-shift] = s-id.man 0xff;
+s-boot[0][1 s-shift] = s-id.dev 0xff;
s-boot[0][2 s-shift] = s-wpstatus 0xff;
break;
@@ -615,21 +619,24 @@ static CPUWriteMemoryFunc * const onenand_writefn[] = {
onenand_write,
};
-void *onenand_init(BlockDriverState *bdrv, uint32_t id,
+void *onenand_init(BlockDriverState *bdrv,
+ uint16_t man_id, uint16_t dev_id, uint16_t ver_id,
int regshift, qemu_irq irq)
{
OneNANDState *s = (OneNANDState *) qemu_mallocz(sizeof(*s));
-uint32_t size = 1 (24 + ((id 12) 7));
+uint32_t size = 1 (24 + ((dev_id 4) 7));
void *ram;
s-shift = regshift;
s-intr = irq;
s-rdy = NULL;
-s-id = id;
+s-id.man = man_id;
+s-id.dev = dev_id;
+s-id.ver = ver_id;
s-blocks = size BLOCK_SHIFT;
s-secs = size 9;
s-blockwp = qemu_malloc(s-blocks);
-s-density_mask = (id (1 11)) ? (1 (6 + ((id 12) 7))) : 0;
+s-density_mask = (dev_id 0x08) ? (1 (6 + ((dev_id 4) 7))) : 0;
s-iomemtype = cpu_register_io_memory(onenand_readfn,
onenand_writefn, s, DEVICE_NATIVE_ENDIAN);
s-bdrv = bdrv;
--
1.7.1
[Qemu-devel] [PATCH 11/15] hw/nand: qdevify
From: Juha Riihimäki juha.riihim...@nokia.com
Qdevify the NAND device.
Signed-off-by: Juha Riihimäki juha.riihim...@nokia.com
[Riku Voipio: Fixes and restructuring patchset]
Signed-off-by: Riku Voipio riku.voi...@iki.fi
[Peter Maydell: More fixes and cleanups for upstream submission]
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
hw/axis_dev88.c |2 +-
hw/flash.h | 14 ++---
hw/nand.c | 164 +++
hw/spitz.c |2 +-
hw/tc6393xb.c |2 +-
5 files changed, 102 insertions(+), 82 deletions(-)
diff --git a/hw/axis_dev88.c b/hw/axis_dev88.c
index de1f5a5..e0a8c14 100644
--- a/hw/axis_dev88.c
+++ b/hw/axis_dev88.c
@@ -37,7 +37,7 @@
struct nand_state_t
{
-NANDFlashState *nand;
+DeviceState *nand;
unsigned int rdy:1;
unsigned int ale:1;
unsigned int cle:1;
diff --git a/hw/flash.h b/hw/flash.h
index 132ad29..43260ce 100644
--- a/hw/flash.h
+++ b/hw/flash.h
@@ -18,15 +18,13 @@ pflash_t *pflash_cfi02_register(target_phys_addr_t base,
ram_addr_t off,
int be);
/* nand.c */
-typedef struct NANDFlashState NANDFlashState;
-NANDFlashState *nand_init(BlockDriverState *bdrv, int manf_id, int chip_id);
-void nand_done(NANDFlashState *s);
-void nand_setpins(NANDFlashState *s, uint8_t cle, uint8_t ale,
+DeviceState *nand_init(BlockDriverState *bdrv, int manf_id, int chip_id);
+void nand_setpins(DeviceState *dev, uint8_t cle, uint8_t ale,
uint8_t ce, uint8_t wp, uint8_t gnd);
-void nand_getpins(NANDFlashState *s, int *rb);
-void nand_setio(NANDFlashState *s, uint32_t value);
-uint32_t nand_getio(NANDFlashState *s);
-uint32_t nand_getbuswidth(NANDFlashState *s);
+void nand_getpins(DeviceState *dev, int *rb);
+void nand_setio(DeviceState *dev, uint32_t value);
+uint32_t nand_getio(DeviceState *dev);
+uint32_t nand_getbuswidth(DeviceState *dev);
#define NAND_MFR_TOSHIBA 0x98
#define NAND_MFR_SAMSUNG 0xec
diff --git a/hw/nand.c b/hw/nand.c
index d068eb6..2f5a40e 100644
--- a/hw/nand.c
+++ b/hw/nand.c
@@ -18,6 +18,7 @@
# include hw.h
# include flash.h
# include blockdev.h
+# include sysbus.h
# define NAND_CMD_READ00x00
# define NAND_CMD_READ10x01
@@ -47,7 +48,9 @@
# define MAX_PAGE 0x800
# define MAX_OOB 0x40
+typedef struct NANDFlashState NANDFlashState;
struct NANDFlashState {
+SysBusDevice busdev;
uint8_t manf_id, chip_id;
uint8_t buswidth; /* in BYTES */
int size, pages;
@@ -215,8 +218,9 @@ static const struct {
[0xc5] = { 2048, 16, 0, 0, LP_OPTIONS16 },
};
-static void nand_reset(NANDFlashState *s)
+static void nand_reset(DeviceState *dev)
{
+NANDFlashState *s = FROM_SYSBUS(NANDFlashState, sysbus_from_qdev(dev));
s-cmd = NAND_CMD_READ0;
s-addr = 0;
s-addrlen = 0;
@@ -270,7 +274,7 @@ static void nand_command(NANDFlashState *s)
break;
case NAND_CMD_RESET:
-nand_reset(s);
+nand_reset(s-busdev.qdev);
break;
case NAND_CMD_PAGEPROGRAM1:
@@ -354,15 +358,84 @@ static const VMStateDescription vmstate_nand = {
}
};
+static int nand_device_init(SysBusDevice *dev)
+{
+int pagesize;
+NANDFlashState *s = FROM_SYSBUS(NANDFlashState, dev);
+s-buswidth = nand_flash_ids[s-chip_id].width 3;
+s-size = nand_flash_ids[s-chip_id].size 20;
+if (nand_flash_ids[s-chip_id].options NAND_SAMSUNG_LP) {
+s-page_shift = 11;
+s-erase_shift = 6;
+} else {
+s-page_shift = nand_flash_ids[s-chip_id].page_shift;
+s-erase_shift = nand_flash_ids[s-chip_id].erase_shift;
+}
+
+switch (1 s-page_shift) {
+case 256:
+nand_init_256(s);
+break;
+case 512:
+nand_init_512(s);
+break;
+case 2048:
+nand_init_2048(s);
+break;
+default:
+hw_error(%s: Unsupported NAND block size.\n, __func__);
+}
+
+pagesize = 1 s-oob_shift;
+s-mem_oob = 1;
+if (s-bdrv bdrv_getlength(s-bdrv) =
+(s-pages s-page_shift) + (s-pages s-oob_shift)) {
+pagesize = 0;
+s-mem_oob = 0;
+}
+
+if (!s-bdrv) {
+pagesize += 1 s-page_shift;
+}
+if (pagesize) {
+s-storage = (uint8_t *) memset(qemu_malloc(s-pages * pagesize),
+0xff, s-pages * pagesize);
+}
+/* Give s-ioaddr a sane value in case we save state before it is used. */
+s-ioaddr = s-io;
+
+return 0;
+}
+
+static SysBusDeviceInfo nand_info = {
+.init = nand_device_init,
+.qdev.name = nand,
+.qdev.size = sizeof(NANDFlashState),
+.qdev.reset = nand_reset,
+.qdev.vmsd = vmstate_nand,
+.qdev.props = (Property[]) {
+DEFINE_PROP_UINT8(manufacturer_id, NANDFlashState, manf_id, 0),
+DEFINE_PROP_UINT8(chip_id, NANDFlashState, chip_id, 0),
+DEFINE_PROP_DRIVE(drive, NANDFlashState,
[Qemu-devel] [PATCH 08/15] hw/nand: Support devices wider than 8 bits
From: Juha Riihimäki juha.riihim...@nokia.com
Support NAND devices which are wider than 8 bits.
Signed-off-by: Juha Riihimäki juha.riihim...@nokia.com
[Riku Voipio: Fixes and restructuring patchset]
Signed-off-by: Riku Voipio riku.voi...@iki.fi
[Peter Maydell: More fixes and cleanups for upstream submission]
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
hw/flash.h |5 ++-
hw/nand.c | 119 +++-
2 files changed, 89 insertions(+), 35 deletions(-)
diff --git a/hw/flash.h b/hw/flash.h
index a992bb8..132ad29 100644
--- a/hw/flash.h
+++ b/hw/flash.h
@@ -24,8 +24,9 @@ void nand_done(NANDFlashState *s);
void nand_setpins(NANDFlashState *s, uint8_t cle, uint8_t ale,
uint8_t ce, uint8_t wp, uint8_t gnd);
void nand_getpins(NANDFlashState *s, int *rb);
-void nand_setio(NANDFlashState *s, uint8_t value);
-uint8_t nand_getio(NANDFlashState *s);
+void nand_setio(NANDFlashState *s, uint32_t value);
+uint32_t nand_getio(NANDFlashState *s);
+uint32_t nand_getbuswidth(NANDFlashState *s);
#define NAND_MFR_TOSHIBA 0x98
#define NAND_MFR_SAMSUNG 0xec
diff --git a/hw/nand.c b/hw/nand.c
index 18aa226..2e98f25 100644
--- a/hw/nand.c
+++ b/hw/nand.c
@@ -49,6 +49,7 @@
struct NANDFlashState {
uint8_t manf_id, chip_id;
+uint8_t buswidth; /* in BYTES */
int size, pages;
int page_shift, oob_shift, erase_shift, addr_shift;
uint8_t *storage;
@@ -215,6 +216,14 @@ static void nand_reset(NANDFlashState *s)
s-status = NAND_IOSTATUS_UNPROTCT;
}
+static inline void nand_pushio_byte(NANDFlashState *s, uint8_t value)
+{
+s-ioaddr[s-iolen++] = value;
+for (value = s-buswidth; --value;) {
+s-ioaddr[s-iolen++] = 0;
+}
+}
+
static void nand_command(NANDFlashState *s)
{
unsigned int offset;
@@ -224,15 +233,19 @@ static void nand_command(NANDFlashState *s)
break;
case NAND_CMD_READID:
-s-io[0] = s-manf_id;
-s-io[1] = s-chip_id;
-s-io[2] = 'Q';/* Don't-care byte (often 0xa5) */
-if (nand_flash_ids[s-chip_id].options NAND_SAMSUNG_LP)
-s-io[3] = 0x15; /* Page Size, Block Size, Spare Size.. */
-else
-s-io[3] = 0xc0; /* Multi-plane */
s-ioaddr = s-io;
-s-iolen = 4;
+s-iolen = 0;
+nand_pushio_byte(s, s-manf_id);
+nand_pushio_byte(s, s-chip_id);
+nand_pushio_byte(s, 'Q'); /* Don't-care byte (often 0xa5) */
+if (nand_flash_ids[s-chip_id].options NAND_SAMSUNG_LP) {
+/* Page Size, Block Size, Spare Size; bit 6 indicates
+ * 8 vs 16 bit width NAND.
+ */
+nand_pushio_byte(s, (s-buswidth == 2) ? 0x55 : 0x15);
+} else {
+nand_pushio_byte(s, 0xc0); /* Multi-plane */
+}
break;
case NAND_CMD_RANDOMREAD2:
@@ -277,9 +290,9 @@ static void nand_command(NANDFlashState *s)
break;
case NAND_CMD_READSTATUS:
-s-io[0] = s-status;
s-ioaddr = s-io;
-s-iolen = 1;
+s-iolen = 0;
+nand_pushio_byte(s, s-status);
break;
default:
@@ -357,8 +370,10 @@ void nand_getpins(NANDFlashState *s, int *rb)
*rb = 1;
}
-void nand_setio(NANDFlashState *s, uint8_t value)
+void nand_setio(NANDFlashState *s, uint32_t value)
{
+int i;
+
if (!s-ce s-cle) {
if (nand_flash_ids[s-chip_id].options NAND_SAMSUNG_LP) {
if (s-cmd == NAND_CMD_READ0 value == NAND_CMD_LPREAD2)
@@ -404,36 +419,64 @@ void nand_setio(NANDFlashState *s, uint8_t value)
s-addr = (s-addr mask) | v;
s-addrlen ++;
-if (s-addrlen == 1 s-cmd == NAND_CMD_READID)
-nand_command(s);
-
-if (!(nand_flash_ids[s-chip_id].options NAND_SAMSUNG_LP)
-s-addrlen == 3 (
-s-cmd == NAND_CMD_READ0 ||
-s-cmd == NAND_CMD_PAGEPROGRAM1))
-nand_command(s);
-if ((nand_flash_ids[s-chip_id].options NAND_SAMSUNG_LP)
- s-addrlen == 4 (
-s-cmd == NAND_CMD_READ0 ||
-s-cmd == NAND_CMD_PAGEPROGRAM1))
-nand_command(s);
+switch (s-addrlen) {
+case 1:
+if (s-cmd == NAND_CMD_READID) {
+nand_command(s);
+}
+break;
+case 2: /* fix cache address as a byte address */
+s-addr = (s-buswidth - 1);
+break;
+case 3:
+if (!(nand_flash_ids[s-chip_id].options NAND_SAMSUNG_LP)
+ (s-cmd == NAND_CMD_READ0
+|| s-cmd == NAND_CMD_PAGEPROGRAM1)) {
+nand_command(s);
+}
+break;
+case 4:
+if ((nand_flash_ids[s-chip_id].options NAND_SAMSUNG_LP)
+ nand_flash_ids[s-chip_id].size 256 /* 1Gb or less */
+ (s-cmd == NAND_CMD_READ0 ||
[Qemu-devel] [PULL 00/15] omap patches (gpio, nand, onenand, lm832x)
This pull request gathers up my recent omap patches: * omap-gpio qdevification * nand bugfixes and qdevification * onenand bugfixes * fix crash bug in n810/lm832x when key is pressed I have omitted patch 11/12 from the nand/onenand patchset (http://patchwork.ozlabs.org/patch/104841/ hw/sysbus: Add sysbus_mmio_unmap() for unmapping a region) because it needs updating now Avi's memory API changes have landed, and 12/12 (hw/onenand: qdevify) because that depends on 11/12. I'll post newer versions of those next week, probably. The following changes since commit c62f6d1d76aea587556c85b6b7b5c44167006264: monitor: fix build breakage with --disable-vnc (2011-07-29 09:33:56 -0500) are available in the git repository at: git://git.linaro.org/people/pmaydell/qemu-arm.git omap-for-upstream Juha Riihimäki (9): hw/omap_l4.c: Add helper function omap_l4_region_base hw/omap_gpio.c: Convert to qdev hw/nand: Support large NAND devices hw/nand: Support devices wider than 8 bits hw/nand: Support multiple reads following READ STATUS hw/nand: qdevify onenand: Handle various ID fields separately onenand: Ignore zero writes to boot command space hw/onenand: program actions can only clear bits Peter Maydell (6): hw/omap_gpio.c: Don't complain about some writes to r/o registers hw/omap_clk: Add the clock for the OMAP2430-specific fifth GPIO module lm832x: Take DeviceState pointer in lm832x_key_event() hw/nand: Pass block device state to init function hw/nand: Writing to NAND can only clear bits onenand: Pass BlockDriverState to init function hw/axis_dev88.c |8 +- hw/flash.h | 17 ++-- hw/i2c.h|2 +- hw/lm832x.c |4 +- hw/nand.c | 345 +++ hw/nseries.c| 63 +- hw/omap.h | 22 +--- hw/omap1.c | 10 +- hw/omap2.c | 34 -- hw/omap_clk.c |6 +- hw/omap_gpio.c | 263 -- hw/omap_l4.c|6 + hw/onenand.c| 183 ++--- hw/palm.c | 26 ++-- hw/spitz.c |6 +- hw/tc6393xb.c |7 +- 16 files changed, 627 insertions(+), 375 deletions(-)
[Qemu-devel] [PATCH v2 0.15 2/4] add pc-0.14 machine
The new pc-0.15 machine will have a different migration format, so
define the compatibility one right now.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
hw/pc_piix.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index c5c16b4..61f8cbb 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -258,7 +258,7 @@ static void pc_xen_hvm_init(ram_addr_t ram_size,
#endif
static QEMUMachine pc_machine = {
-.name = pc-0.14,
+.name = pc-0.15,
.alias = pc,
.desc = Standard PC,
.init = pc_init_pci,
@@ -266,6 +266,13 @@ static QEMUMachine pc_machine = {
.is_default = 1,
};
+static QEMUMachine pc_machine_v0_14 = {
+.name = pc-0.14,
+.desc = Standard PC,
+.init = pc_init_pci,
+.max_cpus = 255,
+};
+
static QEMUMachine pc_machine_v0_13 = {
.name = pc-0.13,
.desc = Standard PC,
@@ -482,6 +489,7 @@ static QEMUMachine xenfv_machine = {
static void pc_machine_init(void)
{
qemu_register_machine(pc_machine);
+qemu_register_machine(pc_machine_v0_14);
qemu_register_machine(pc_machine_v0_13);
qemu_register_machine(pc_machine_v0_12);
qemu_register_machine(pc_machine_v0_11);
--
1.7.6
[Qemu-devel] [PATCH 01/15] hw/omap_l4.c: Add helper function omap_l4_region_base
From: Juha Riihimäki juha.riihim...@nokia.com
Add helper function omap_l4_region_base() to return the base address
of a particular region of an L4 target agent.
Signed-off-by: Juha Riihimäki juha.riihim...@nokia.com
[Riku Voipio: Fixes and restructuring patchset]
Signed-off-by: Riku Voipio riku.voi...@iki.fi
[Peter Maydell: More fixes and cleanups for upstream submission]
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
hw/omap.h|2 ++
hw/omap_l4.c |6 ++
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/hw/omap.h b/hw/omap.h
index c227a82..00a0ea9 100644
--- a/hw/omap.h
+++ b/hw/omap.h
@@ -93,6 +93,8 @@ struct omap_target_agent_s *omap_l4ta_get(
int cs);
target_phys_addr_t omap_l4_attach(struct omap_target_agent_s *ta, int region,
int iotype);
+target_phys_addr_t omap_l4_region_base(struct omap_target_agent_s *ta,
+ int region);
int l4_register_io_memory(CPUReadMemoryFunc * const *mem_read,
CPUWriteMemoryFunc * const *mem_write, void *opaque);
diff --git a/hw/omap_l4.c b/hw/omap_l4.c
index 4af0ca8..59c84b1 100644
--- a/hw/omap_l4.c
+++ b/hw/omap_l4.c
@@ -146,6 +146,12 @@ struct omap_l4_s *omap_l4_init(target_phys_addr_t base,
int ta_num)
return bus;
}
+target_phys_addr_t omap_l4_region_base(struct omap_target_agent_s *ta,
+ int region)
+{
+return ta-bus-base + ta-start[region].offset;
+}
+
static uint32_t omap_l4ta_read(void *opaque, target_phys_addr_t addr)
{
struct omap_target_agent_s *s = (struct omap_target_agent_s *) opaque;
--
1.7.1
[Qemu-devel] [PATCH 05/15] lm832x: Take DeviceState pointer in lm832x_key_event()
Since lm832x has been qdev'ified, its users will generally
have a DeviceState pointer rather than an i2c_slave pointer,
so adjust lm832x_key_event's prototype to suit.
This allows the n810 (its only user) to actually pass a correct
pointer to it rather than NULL. The effect is that we no longer
segfault when a key is pressed.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
hw/i2c.h |2 +-
hw/lm832x.c |4 ++--
hw/nseries.c |7 +++
3 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/hw/i2c.h b/hw/i2c.h
index 5514402..9381d01 100644
--- a/hw/i2c.h
+++ b/hw/i2c.h
@@ -72,6 +72,6 @@ void wm8750_set_bclk_in(void *opaque, int new_hz);
void tmp105_set(i2c_slave *i2c, int temp);
/* lm832x.c */
-void lm832x_key_event(i2c_slave *i2c, int key, int state);
+void lm832x_key_event(DeviceState *dev, int key, int state);
#endif
diff --git a/hw/lm832x.c b/hw/lm832x.c
index 590a4cc..992ce49 100644
--- a/hw/lm832x.c
+++ b/hw/lm832x.c
@@ -474,9 +474,9 @@ static int lm8323_init(i2c_slave *i2c)
return 0;
}
-void lm832x_key_event(struct i2c_slave *i2c, int key, int state)
+void lm832x_key_event(DeviceState *dev, int key, int state)
{
-LM823KbdState *s = (LM823KbdState *) i2c;
+LM823KbdState *s = FROM_I2C_SLAVE(LM823KbdState, I2C_SLAVE_FROM_QDEV(dev));
if ((s-status INT_ERROR) (s-error ERR_FIFOOVR))
return;
diff --git a/hw/nseries.c b/hw/nseries.c
index 32f2f53..45b52bb 100644
--- a/hw/nseries.c
+++ b/hw/nseries.c
@@ -45,7 +45,7 @@ struct n800_s {
i2c_bus *i2c;
int keymap[0x80];
-i2c_slave *kbd;
+DeviceState *kbd;
TUSBState *usb;
void *retu;
@@ -362,7 +362,6 @@ static int n810_keys[0x80] = {
static void n810_kbd_setup(struct n800_s *s)
{
qemu_irq kbd_irq = qdev_get_gpio_in(s-cpu-gpio, N810_KEYBOARD_GPIO);
-DeviceState *dev;
int i;
for (i = 0; i 0x80; i ++)
@@ -375,8 +374,8 @@ static void n810_kbd_setup(struct n800_s *s)
/* Attach the LM8322 keyboard to the I2C bus,
* should happen in n8x0_i2c_setup and s-kbd be initialised here. */
-dev = i2c_create_slave(s-i2c, lm8323, N810_LM8323_ADDR);
-qdev_connect_gpio_out(dev, 0, kbd_irq);
+s-kbd = i2c_create_slave(s-i2c, lm8323, N810_LM8323_ADDR);
+qdev_connect_gpio_out(s-kbd, 0, kbd_irq);
}
/* LCD MIPI DBI-C controller (URAL) */
--
1.7.1
[Qemu-devel] [PATCH 12/15] onenand: Pass BlockDriverState to init function
Pass the BlockDriverState to the onenand init function so it doesn't
need to look up the drive itself.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
hw/flash.h |3 ++-
hw/nseries.c | 10 ++
hw/onenand.c | 14 --
3 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/hw/flash.h b/hw/flash.h
index 43260ce..1aae43d 100644
--- a/hw/flash.h
+++ b/hw/flash.h
@@ -38,7 +38,8 @@ uint32_t nand_getbuswidth(DeviceState *dev);
/* onenand.c */
void onenand_base_update(void *opaque, target_phys_addr_t new);
void onenand_base_unmap(void *opaque);
-void *onenand_init(uint32_t id, int regshift, qemu_irq irq);
+void *onenand_init(BlockDriverState *bdrv, uint32_t id,
+ int regshift, qemu_irq irq);
void *onenand_raw_otp(void *opaque);
/* ecc.c */
diff --git a/hw/nseries.c b/hw/nseries.c
index 45b52bb..96cc490 100644
--- a/hw/nseries.c
+++ b/hw/nseries.c
@@ -31,6 +31,7 @@
#include hw.h
#include bt.h
#include loader.h
+#include blockdev.h
/* Nokia N8x0 support */
struct n800_s {
@@ -163,13 +164,14 @@ static const uint8_t n8x0_cal_bt_id[] = {
static void n8x0_nand_setup(struct n800_s *s)
{
char *otp_region;
+DriveInfo *dinfo;
+dinfo = drive_get(IF_MTD, 0, 0);
/* Either ec40xx or ec48xx are OK for the ID */
+s-nand = onenand_init(dinfo ? dinfo-bdrv : 0, 0xec4800, 1,
+ qdev_get_gpio_in(s-cpu-gpio, N8X0_ONENAND_GPIO));
omap_gpmc_attach(s-cpu-gpmc, N8X0_ONENAND_CS, 0, onenand_base_update,
-onenand_base_unmap,
-(s-nand = onenand_init(0xec4800, 1,
-qdev_get_gpio_in(s-cpu-gpio,
-N8X0_ONENAND_GPIO;
+ onenand_base_unmap, s-nand);
otp_region = onenand_raw_otp(s-nand);
memcpy(otp_region + 0x000, n8x0_cal_wlan_mac, sizeof(n8x0_cal_wlan_mac));
diff --git a/hw/onenand.c b/hw/onenand.c
index 71c1ab4..3a19d7f 100644
--- a/hw/onenand.c
+++ b/hw/onenand.c
@@ -615,10 +615,10 @@ static CPUWriteMemoryFunc * const onenand_writefn[] = {
onenand_write,
};
-void *onenand_init(uint32_t id, int regshift, qemu_irq irq)
+void *onenand_init(BlockDriverState *bdrv, uint32_t id,
+ int regshift, qemu_irq irq)
{
OneNANDState *s = (OneNANDState *) qemu_mallocz(sizeof(*s));
-DriveInfo *dinfo = drive_get(IF_MTD, 0, 0);
uint32_t size = 1 (24 + ((id 12) 7));
void *ram;
@@ -632,11 +632,13 @@ void *onenand_init(uint32_t id, int regshift, qemu_irq
irq)
s-density_mask = (id (1 11)) ? (1 (6 + ((id 12) 7))) : 0;
s-iomemtype = cpu_register_io_memory(onenand_readfn,
onenand_writefn, s, DEVICE_NATIVE_ENDIAN);
-if (!dinfo)
+s-bdrv = bdrv;
+if (!s-bdrv) {
s-image = memset(qemu_malloc(size + (size 5)),
-0xff, size + (size 5));
-else
-s-bdrv = dinfo-bdrv;
+ 0xff, size + (size 5));
+} else {
+s-bdrv_cur = s-bdrv;
+}
s-otp = memset(qemu_malloc((64 + 2) PAGE_SHIFT),
0xff, (64 + 2) PAGE_SHIFT);
s-ram = qemu_ram_alloc(NULL, onenand.ram, 0xc000 s-shift);
--
1.7.1
[Qemu-devel] [PATCH 09/15] hw/nand: Support multiple reads following READ STATUS
From: Juha Riihimäki juha.riihim...@nokia.com
After receiving READ STATUS command all subsequent IO reads should return
the status register value until another command is issued.
Signed-off-by: Juha Riihimäki juha.riihim...@nokia.com
[Riku Voipio: Fixes and restructuring patchset]
Signed-off-by: Riku Voipio riku.voi...@iki.fi
[Peter Maydell: More fixes and cleanups for upstream submission]
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
hw/nand.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/hw/nand.c b/hw/nand.c
index 2e98f25..e6c551d 100644
--- a/hw/nand.c
+++ b/hw/nand.c
@@ -496,9 +496,14 @@ uint32_t nand_getio(NANDFlashState *s)
for (offset = s-buswidth; offset--;) {
x |= s-ioaddr[offset] (offset 3);
}
-s-addr += s-buswidth;
-s-ioaddr += s-buswidth;
-s-iolen -= s-buswidth;
+/* after receiving READ STATUS command all subsequent reads will
+ * return the status register value until another command is issued
+ */
+if (s-cmd != NAND_CMD_READSTATUS) {
+s-addr += s-buswidth;
+s-ioaddr += s-buswidth;
+s-iolen -= s-buswidth;
+}
return x;
}
--
1.7.1
[Qemu-devel] [PATCH 02/15] hw/omap_gpio.c: Don't complain about some writes to r/o registers
Don't complain about some writes to r/o OMAP2 GPIO registers, because the kernel will do them anyway. Signed-off-by: Peter Maydell peter.mayd...@linaro.org --- hw/omap_gpio.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/hw/omap_gpio.c b/hw/omap_gpio.c index 478f7d9..b53b13b 100644 --- a/hw/omap_gpio.c +++ b/hw/omap_gpio.c @@ -385,7 +385,7 @@ static void omap2_gpio_module_write(void *opaque, target_phys_addr_t addr, case 0x00: /* GPIO_REVISION */ case 0x14: /* GPIO_SYSSTATUS */ case 0x38: /* GPIO_DATAIN */ -OMAP_RO_REG(addr); +/* read-only, ignore quietly */ break; case 0x10: /* GPIO_SYSCONFIG */ @@ -531,7 +531,7 @@ static void omap2_gpio_module_writep(void *opaque, target_phys_addr_t addr, case 0x00: /* GPIO_REVISION */ case 0x14: /* GPIO_SYSSTATUS */ case 0x38: /* GPIO_DATAIN */ -OMAP_RO_REG(addr); +/* read-only, ignore quietly */ break; case 0x10: /* GPIO_SYSCONFIG */ -- 1.7.1
Re: [Qemu-devel] [PATCH V2 1/2] [SLIRP] Simple ARP table
On 2011-07-29 18:25, Fabien Chouteau wrote:
This patch adds a simple ARP table in Slirp and also adds handling of
gratuitous ARP requests.
Signed-off-by: Fabien Chouteau chout...@adacore.com
---
Makefile.objs |2 +-
slirp/arp_table.c | 50 ++
slirp/bootp.c | 23 --
slirp/slirp.c | 63 +---
slirp/slirp.h | 50 +++--
5 files changed, 129 insertions(+), 59 deletions(-)
create mode 100644 slirp/arp_table.c
diff --git a/Makefile.objs b/Makefile.objs
index 6991a9f..0c10557 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -151,7 +151,7 @@ common-obj-y += qemu-timer.o qemu-timer-common.o
slirp-obj-y = cksum.o if.o ip_icmp.o ip_input.o ip_output.o
slirp-obj-y += slirp.o mbuf.o misc.o sbuf.o socket.o tcp_input.o tcp_output.o
-slirp-obj-y += tcp_subr.o tcp_timer.o udp.o bootp.o tftp.o
+slirp-obj-y += tcp_subr.o tcp_timer.o udp.o bootp.o tftp.o arp_table.o
common-obj-$(CONFIG_SLIRP) += $(addprefix slirp/, $(slirp-obj-y))
# xen backend driver support
diff --git a/slirp/arp_table.c b/slirp/arp_table.c
new file mode 100644
index 000..5d7404b
--- /dev/null
+++ b/slirp/arp_table.c
@@ -0,0 +1,50 @@
+#include slirp.h
+
+void arp_table_add(ArpTable *arptbl,
+ int ip_addr,
+ uint8_t ethaddr[ETH_ALEN])
I still prefer the condensed formatting, but that's a minor nit.
+{
+int i;
+
+DEBUG_CALL(arp_table_add);
+DEBUG_ARG(ip = 0x%x, ip_addr);
+DEBUG_ARGS((dfd, hw addr = %02x:%02x:%02x:%02x:%02x:%02x\n,
+ethaddr[0], ethaddr[1], ethaddr[2],
+ethaddr[3], ethaddr[4], ethaddr[5]));
+
+/* Search for an entry */
+for (i = 0; i ARP_TABLE_SIZE arptbl-table[i].ar_sip != 0; i++) {
Missed that on round #1: Why treating 0.0.0.0 special? If ip_addr can be
zero, the current logic will append every update of that address as a
new entry.
+if (arptbl-table[i].ar_sip == ip_addr) {
+/* Update the entry */
+memcpy(arptbl-table[i].ar_sha, ethaddr, ETH_ALEN);
+return;
+}
+}
+
+/* No entry found, create a new one */
+arptbl-table[arptbl-next_victim].ar_sip = ip_addr;
+memcpy(arptbl-table[arptbl-next_victim].ar_sha, ethaddr, ETH_ALEN);
+arptbl-next_victim = (arptbl-next_victim + 1) % ARP_TABLE_SIZE;
+}
+
+bool arp_table_search(ArpTable *arptbl,
+ int in_ip_addr,
+ uint8_t out_ethaddr[ETH_ALEN])
+{
+int i;
+
+DEBUG_CALL(arp_table_search);
+DEBUG_ARG(ip = 0x%x, in_ip_addr);
+
+for (i = 0; i ARP_TABLE_SIZE; i++) {
+if (arptbl-table[i].ar_sip == in_ip_addr) {
+memcpy(out_ethaddr, arptbl-table[i].ar_sha, ETH_ALEN);
+DEBUG_ARGS((dfd, found hw addr =
%02x:%02x:%02x:%02x:%02x:%02x\n,
+out_ethaddr[0], out_ethaddr[1], out_ethaddr[2],
+out_ethaddr[3], out_ethaddr[4], out_ethaddr[5]));
+return 1;
+}
+}
+
+return 0;
+}
diff --git a/slirp/bootp.c b/slirp/bootp.c
index 1eb2ed1..07cbb80 100644
--- a/slirp/bootp.c
+++ b/slirp/bootp.c
@@ -149,6 +149,7 @@ static void bootp_reply(Slirp *slirp, const struct
bootp_t *bp)
struct in_addr preq_addr;
int dhcp_msg_type, val;
uint8_t *q;
+uint8_t client_ethaddr[ETH_ALEN];
/* extract exact DHCP msg type */
dhcp_decode(bp, dhcp_msg_type, preq_addr);
@@ -164,8 +165,9 @@ static void bootp_reply(Slirp *slirp, const struct
bootp_t *bp)
if (dhcp_msg_type != DHCPDISCOVER
dhcp_msg_type != DHCPREQUEST)
return;
-/* XXX: this is a hack to get the client mac address */
-memcpy(slirp-client_ethaddr, bp-bp_hwaddr, 6);
+
+/* Get client's hardware address from bootp request */
+memcpy(client_ethaddr, bp-bp_hwaddr, ETH_ALEN);
m = m_get(slirp);
if (!m) {
@@ -178,25 +180,25 @@ static void bootp_reply(Slirp *slirp, const struct
bootp_t *bp)
if (dhcp_msg_type == DHCPDISCOVER) {
if (preq_addr.s_addr != htonl(0L)) {
-bc = request_addr(slirp, preq_addr, slirp-client_ethaddr);
+bc = request_addr(slirp, preq_addr, client_ethaddr);
if (bc) {
daddr.sin_addr = preq_addr;
}
}
if (!bc) {
new_addr:
-bc = get_new_addr(slirp, daddr.sin_addr, slirp-client_ethaddr);
+bc = get_new_addr(slirp, daddr.sin_addr, client_ethaddr);
if (!bc) {
DPRINTF(no address left\n);
return;
}
}
-memcpy(bc-macaddr, slirp-client_ethaddr, 6);
+memcpy(bc-macaddr, client_ethaddr, ETH_ALEN);
} else if (preq_addr.s_addr != htonl(0L)) {
Re: [Qemu-devel] [PATCH V2 2/2] [SLIRP] Delayed IP packets
On 2011-07-29 18:25, Fabien Chouteau wrote:
In the current implementation, if Slirp tries to send an IP packet to a client
with an unknown hardware address, the packet is simply dropped and an ARP
request is sent (if_encap in slirp/slirp.c).
With this patch, Slirp will send the ARP request, re-queue the packet and try
to send it later. The packet is dropped after one second if the ARP reply is
not received.
Signed-off-by: Fabien Chouteau chout...@adacore.com
---
slirp/if.c| 28 ---
slirp/main.h |2 +-
slirp/mbuf.c |2 +
slirp/mbuf.h |2 +
slirp/slirp.c | 67 ++--
slirp/slirp.h | 15
6 files changed, 80 insertions(+), 36 deletions(-)
diff --git a/slirp/if.c b/slirp/if.c
index 0f04e13..80a5c4e 100644
--- a/slirp/if.c
+++ b/slirp/if.c
@@ -6,6 +6,7 @@
*/
#include slirp.h
+#include qemu-timer.h
#define ifs_init(ifm) ((ifm)-ifs_next = (ifm)-ifs_prev = (ifm))
@@ -105,6 +106,9 @@ if_output(struct socket *so, struct mbuf *ifm)
ifs_init(ifm);
insque(ifm, ifq);
+/* Expiration date = Now + 1 second */
+ifm-expiration_date = qemu_get_clock_ns(vm_clock) + 10ULL;
Slirp uses rt_clock for expiry, let's stick with that clock.
+
diddit:
slirp-if_queued++;
@@ -153,6 +157,9 @@ diddit:
void
if_start(Slirp *slirp)
{
+int requeued = 0;
+uint64_t now;
+
struct mbuf *ifm, *ifqt;
DEBUG_CALL(if_start);
@@ -165,6 +172,8 @@ if_start(Slirp *slirp)
if (!slirp_can_output(slirp-opaque))
return;
+now = qemu_get_clock_ns(vm_clock);
+
/*
* See which queue to get next packet from
* If there's something in the fastq, select it immediately
@@ -199,11 +208,22 @@ if_start(Slirp *slirp)
ifm-ifq_so-so_nqueued = 0;
}
- /* Encapsulate the packet for sending */
-if_encap(slirp, (uint8_t *)ifm-m_data, ifm-m_len);
-
-m_free(ifm);
+if (ifm-expiration_date now) {
+/* Expired */
+m_free(ifm);
+} else {
+/* Encapsulate the packet for sending */
+if (if_encap(slirp, ifm)) {
+m_free(ifm);
+} else {
+/* re-queue */
+insque(ifm, ifqt);
+requeued++;
+}
+}
if (slirp-if_queued)
goto again;
+
+slirp-if_queued = requeued;
}
diff --git a/slirp/main.h b/slirp/main.h
index 0dd8d81..028df4b 100644
--- a/slirp/main.h
+++ b/slirp/main.h
@@ -42,5 +42,5 @@ extern int tcp_keepintvl;
#define PROTO_PPP 0x2
#endif
-void if_encap(Slirp *slirp, const uint8_t *ip_data, int ip_data_len);
+int if_encap(Slirp *slirp, struct mbuf *ifm);
ssize_t slirp_send(struct socket *so, const void *buf, size_t len, int
flags);
diff --git a/slirp/mbuf.c b/slirp/mbuf.c
index ce2eb84..c699c75 100644
--- a/slirp/mbuf.c
+++ b/slirp/mbuf.c
@@ -70,6 +70,8 @@ m_get(Slirp *slirp)
m-m_len = 0;
m-m_nextpkt = NULL;
m-m_prevpkt = NULL;
+m-arp_requested = false;
+m-expiration_date = (uint64_t)-1;
end_error:
DEBUG_ARG(m = %lx, (long )m);
return m;
diff --git a/slirp/mbuf.h b/slirp/mbuf.h
index b74544b..55170e5 100644
--- a/slirp/mbuf.h
+++ b/slirp/mbuf.h
@@ -86,6 +86,8 @@ struct mbuf {
charm_dat_[1]; /* ANSI don't like 0 sized arrays */
char*m_ext_;
} M_dat;
+bool arp_requested;
+uint64_t expiration_date;
};
#define m_next m_hdr.mh_next
diff --git a/slirp/slirp.c b/slirp/slirp.c
index ba76757..b006620 100644
--- a/slirp/slirp.c
+++ b/slirp/slirp.c
@@ -237,6 +237,8 @@ Slirp *slirp_init(int restricted, struct in_addr vnetwork,
QTAILQ_INSERT_TAIL(slirp_instances, slirp, entry);
+slirp-delayed = NULL;
+
return slirp;
}
@@ -693,54 +695,57 @@ void slirp_input(Slirp *slirp, const uint8_t *pkt, int
pkt_len)
}
/* output the IP packet to the ethernet device */
-void if_encap(Slirp *slirp, const uint8_t *ip_data, int ip_data_len)
+int if_encap(Slirp *slirp, struct mbuf *ifm)
{
uint8_t buf[1600];
struct ethhdr *eh = (struct ethhdr *)buf;
uint8_t ethaddr[ETH_ALEN];
-const struct ip *iph = (const struct ip *)ip_data;
+const struct ip *iph = (const struct ip *)ifm-m_data;
-if (ip_data_len + ETH_HLEN sizeof(buf))
-return;
+if (ifm-m_len + ETH_HLEN sizeof(buf))
+return 1;
Even if the old cold lacked them as well: { }
if (!arp_table_search(slirp-arp_table, iph-ip_dst.s_addr, ethaddr)) {
uint8_t arp_req[ETH_HLEN + sizeof(struct arphdr)];
struct ethhdr *reh = (struct ethhdr *)arp_req;
struct arphdr *rah = (struct arphdr *)(arp_req + ETH_HLEN);
-/* If
Re: [Qemu-devel] [libvirt] How to connect to the running VM
Hi, Let me tell clearly , i'm trying to manage VMs using opennebula toolkit , I downloaded the ttylinux image from opennebula site , the Image I downloaded was already created from kvm by opennebula community , so I can use it to deploy on kvm. link for this is - http://opennebula.org/documentation:rel2.2:vmg Since this is very old version ,and I need new version of ttylinux , so I can download new version of ttylinux.iso disc file from ttylinx site . Hence I need to create image from KVM of dvd or iso disc file . Once I created in KVM then I can copy the image to opennebula tool kit and register it . Therefore I need to create a image out of ttylinux.iso disc file pls tell me how to do it..? regards Bala On Fri, Jul 29, 2011 at 10:46 AM, Dave Allan dal...@redhat.com wrote: On Fri, Jul 29, 2011 at 10:36:48AM -0700, bala suru wrote: Hi, Can you suggest any links /docs which explain the kvm image creation steps ..? Replying on list for the benefit of everyone. I don't know what you're referring to when you say kvm image. Are you asking how to install the OS in the guest? Dave rgds On Fri, Jul 29, 2011 at 9:17 AM, Dave Allan dal...@redhat.com wrote: On Fri, Jul 29, 2011 at 05:06:06PM +0530, bala suru wrote: Hi, I have deployed some VM on to the KVM-qemu and installed libvirtd .. I could see the VM running by command virsh list . but how to login to the VMs other than SSH ..? i tried virsh vncdisplay , but no output .. virt-viewer name of VM will give you the graphical console if you have one set up. virt-manager gives you both graphical console and a graphical interface to configure the VM. Dave regards bala -- libvir-list mailing list libvir-l...@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[Qemu-devel] [PATCH] Fix gcc-4.6 compiler error
Commit 3d3b8303c6f83b9b245bc774af530a6403cc4ce6
breaks builds with gcc-4.6:
hw/fw_cfg.c: In function ‘probe_splashfile’:
hw/fw_cfg.c:66:9: error: variable ‘fop_ret’ set but not used
[-Werror=unused-but-set-variable]
hw/fw_cfg.c: In function ‘fw_cfg_bootsplash’:
hw/fw_cfg.c:130:9: error: variable ‘fop_ret’ set but not used
[-Werror=unused-but-set-variable]
Remove fop_ret. Testing the result of fread() is normally
a good idea, but I don't think it is needed here.
Cc: Wayne Xia xiaw...@linux.vnet.ibm.com
Cc: Anthony Liguori aligu...@us.ibm.com
Signed-off-by: Stefan Weil w...@mail.berlios.de
---
hw/fw_cfg.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/hw/fw_cfg.c b/hw/fw_cfg.c
index a29db90..d906b83 100644
--- a/hw/fw_cfg.c
+++ b/hw/fw_cfg.c
@@ -63,7 +63,6 @@ struct FWCfgState {
static FILE *probe_splashfile(char *filename, int *file_sizep, int *file_typep)
{
FILE *fp = NULL;
-int fop_ret;
int file_size;
int file_type = -1;
unsigned char buf[2] = {0, 0};
@@ -86,7 +85,7 @@ static FILE *probe_splashfile(char *filename, int
*file_sizep, int *file_typep)
}
/* check magic ID */
fseek(fp, 0L, SEEK_SET);
-fop_ret = fread(buf, 1, 2, fp);
+(void)fread(buf, 1, 2, fp);
filehead_value = (buf[0] + (buf[1] 8)) 0x;
if (filehead_value == 0xd8ff) {
file_type = JPG_FILE;
@@ -105,7 +104,7 @@ static FILE *probe_splashfile(char *filename, int
*file_sizep, int *file_typep)
/* check BMP bpp */
if (file_type == BMP_FILE) {
fseek(fp, 28, SEEK_SET);
-fop_ret = fread(buf, 1, 2, fp);
+(void)fread(buf, 1, 2, fp);
bmp_bpp = (buf[0] + (buf[1] 8)) 0x;
if (bmp_bpp != 24) {
error_report(only 24bpp bmp file is supported.);
@@ -127,7 +126,6 @@ static void fw_cfg_bootsplash(FWCfgState *s)
char *p;
char *filename;
FILE *fp;
-int fop_ret;
int file_size;
int file_type = -1;
const char *temp;
@@ -180,7 +178,7 @@ static void fw_cfg_bootsplash(FWCfgState *s)
boot_splash_filedata = qemu_malloc(file_size);
boot_splash_filedata_size = file_size;
fseek(fp, 0L, SEEK_SET);
-fop_ret = fread(boot_splash_filedata, 1, file_size, fp);
+(void)fread(boot_splash_filedata, 1, file_size, fp);
fclose(fp);
/* insert data */
if (file_type == JPG_FILE) {
--
1.7.2.5
[Qemu-devel] [PATCH] tcg/arm: Fix compiler error caused by unused function
Function tcg_out_addi is obviously unused and causes a compiler
error (tested with cross compilation on x86 Debian Linux):
tcg/arm/tcg-target.c:1824: error: ‘tcg_out_addi’ defined but not used
Don't remove it because it might be useful in the future,
but declare it inline. This fixes the compiler error and
is similar to other tcg targets.
Cc: Andrzej Zaborowski balr...@gmail.com
Signed-off-by: Stefan Weil w...@mail.berlios.de
---
tcg/arm/tcg-target.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tcg/arm/tcg-target.c b/tcg/arm/tcg-target.c
index 93eb0f1..c94a354 100644
--- a/tcg/arm/tcg-target.c
+++ b/tcg/arm/tcg-target.c
@@ -1820,7 +1820,7 @@ static inline void tcg_out_st(TCGContext *s, TCGType
type, int arg,
tcg_out_st32(s, COND_AL, arg, arg1, arg2);
}
-static void tcg_out_addi(TCGContext *s, int reg, tcg_target_long val)
+static inline void tcg_out_addi(TCGContext *s, int reg, tcg_target_long val)
{
if (val 0)
if (val 0x100)
--
1.7.2.5
[Qemu-devel] [PATCH] configure: Fix bad shell expression for non-Linux hosts
With vhost_net= (most non-Linux hosts), configure prints an
error message:
test: 2551: =: unexpected operator
Fix this and similar code by adding the missing .
Cc: Wolfgang Mauerer wolfgang.maue...@siemens.com
Cc: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
Signed-off-by: Stefan Weil w...@mail.berlios.de
---
configure |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/configure b/configure
index b582f5e..001208d 100755
--- a/configure
+++ b/configure
@@ -2521,7 +2521,7 @@ fi
# __sync_fetch_and_and requires at least -march=i486. Many toolchains
# use i686 as default anyway, but for those that don't, an explicit
# specification is necessary
-if test $vhost_net = yes test $cpu = i386; then
+if test $vhost_net = yes test $cpu = i386; then
cat $TMPC EOF
int sfaa(unsigned *ptr)
{
@@ -2700,7 +2700,7 @@ echo nss used $smartcard_nss
echo usb net redir $usb_redir
echo OpenGL support$opengl
-if test $sdl_too_old = yes; then
+if test $sdl_too_old = yes; then
echo - Your SDL version is too old - please upgrade to have SDL support
fi
@@ -2788,7 +2788,7 @@ fi
if test $static = yes ; then
echo CONFIG_STATIC=y $config_host_mak
fi
-if test $profiler = yes ; then
+if test $profiler = yes ; then
echo CONFIG_PROFILER=y $config_host_mak
fi
if test $slirp = yes ; then
@@ -3342,7 +3342,7 @@ case $target_arch2 in
\( $target_arch2 = x86_64 -a $cpu = i386 \) -o \
\( $target_arch2 = i386 -a $cpu = x86_64 \) \) ; then
echo CONFIG_KVM=y $config_target_mak
- if test $vhost_net = yes ; then
+ if test $vhost_net = yes ; then
echo CONFIG_VHOST_NET=y $config_target_mak
fi
fi
--
1.7.2.5
[Qemu-devel] [RFC PATCH v2 0/3] separate thread for VM migration
Following patch deals with VCPU and iothread starvation during the migration of a guest. Currently the iothread is responsible for performing the guest migration. It holds qemu_mutex during the migration and doesn't allow VCPU to enter the qemu mode and delays its return to the guest. The guest migration, executed as an iohandler also delays the execution of other iohandlers. In the following patch series, The migration has been moved to a separate thread to reduce the qemu_mutex contention and iohandler starvation. Also current dirty bitmap is split into per memslot bitmap to reduce its size. Umesh Deshpande (3): separate thread for VM migration fine grained qemu_mutex locking for migration per memslot dirty bitmap arch_init.c | 14 ++-- buffered_file.c | 28 - buffered_file.h |4 +++ cpu-all.h | 40 ++-- exec.c | 38 +- migration.c | 60 -- migration.h |3 ++ savevm.c| 22 +--- savevm.h| 29 ++ xen-all.c |6 +--- 10 files changed, 173 insertions(+), 71 deletions(-) create mode 100644 savevm.h -- 1.7.4.1
[Qemu-devel] [RFC PATCH v2 1/3] separate thread for VM migration
This patch creates a separate thread for the guest migration on the source side.
Signed-off-by: Umesh Deshpande udesh...@redhat.com
---
buffered_file.c | 28 -
buffered_file.h |4 +++
migration.c | 59 +++---
migration.h |3 ++
savevm.c| 22 +---
savevm.h| 29 +++
6 files changed, 102 insertions(+), 43 deletions(-)
create mode 100644 savevm.h
diff --git a/buffered_file.c b/buffered_file.c
index 41b42c3..d4146bf 100644
--- a/buffered_file.c
+++ b/buffered_file.c
@@ -16,12 +16,16 @@
#include qemu-timer.h
#include qemu-char.h
#include buffered_file.h
+#include migration.h
+#include savevm.h
+#include qemu-thread.h
//#define DEBUG_BUFFERED_FILE
typedef struct QEMUFileBuffered
{
BufferedPutFunc *put_buffer;
+BufferedBeginFunc *begin;
BufferedPutReadyFunc *put_ready;
BufferedWaitForUnfreezeFunc *wait_for_unfreeze;
BufferedCloseFunc *close;
@@ -35,6 +39,7 @@ typedef struct QEMUFileBuffered
size_t buffer_size;
size_t buffer_capacity;
QEMUTimer *timer;
+QemuThread thread;
} QEMUFileBuffered;
#ifdef DEBUG_BUFFERED_FILE
@@ -181,8 +186,6 @@ static int buffered_close(void *opaque)
ret = s-close(s-opaque);
-qemu_del_timer(s-timer);
-qemu_free_timer(s-timer);
qemu_free(s-buffer);
qemu_free(s);
@@ -228,17 +231,15 @@ static int64_t buffered_get_rate_limit(void *opaque)
return s-xfer_limit;
}
-static void buffered_rate_tick(void *opaque)
+void buffered_rate_tick(QEMUFile *file)
{
-QEMUFileBuffered *s = opaque;
+QEMUFileBuffered *s = file-opaque;
if (s-has_error) {
buffered_close(s);
return;
}
-qemu_mod_timer(s-timer, qemu_get_clock_ms(rt_clock) + 100);
-
if (s-freeze_output)
return;
@@ -250,9 +251,17 @@ static void buffered_rate_tick(void *opaque)
s-put_ready(s-opaque);
}
+static void *migrate_vm(void *opaque)
+{
+QEMUFileBuffered *s = opaque;
+s-begin(s-opaque);
+return NULL;
+}
+
QEMUFile *qemu_fopen_ops_buffered(void *opaque,
size_t bytes_per_sec,
BufferedPutFunc *put_buffer,
+ BufferedBeginFunc *begin,
BufferedPutReadyFunc *put_ready,
BufferedWaitForUnfreezeFunc
*wait_for_unfreeze,
BufferedCloseFunc *close)
@@ -264,6 +273,7 @@ QEMUFile *qemu_fopen_ops_buffered(void *opaque,
s-opaque = opaque;
s-xfer_limit = bytes_per_sec / 10;
s-put_buffer = put_buffer;
+s-begin = begin;
s-put_ready = put_ready;
s-wait_for_unfreeze = wait_for_unfreeze;
s-close = close;
@@ -271,11 +281,9 @@ QEMUFile *qemu_fopen_ops_buffered(void *opaque,
s-file = qemu_fopen_ops(s, buffered_put_buffer, NULL,
buffered_close, buffered_rate_limit,
buffered_set_rate_limit,
-buffered_get_rate_limit);
-
-s-timer = qemu_new_timer_ms(rt_clock, buffered_rate_tick, s);
+ buffered_get_rate_limit);
-qemu_mod_timer(s-timer, qemu_get_clock_ms(rt_clock) + 100);
+qemu_thread_create(s-thread, migrate_vm, s);
return s-file;
}
diff --git a/buffered_file.h b/buffered_file.h
index 98d358b..cfe2833 100644
--- a/buffered_file.h
+++ b/buffered_file.h
@@ -17,12 +17,16 @@
#include hw/hw.h
typedef ssize_t (BufferedPutFunc)(void *opaque, const void *data, size_t size);
+typedef void (BufferedBeginFunc)(void *opaque);
typedef void (BufferedPutReadyFunc)(void *opaque);
typedef void (BufferedWaitForUnfreezeFunc)(void *opaque);
typedef int (BufferedCloseFunc)(void *opaque);
+void buffered_rate_tick(QEMUFile *file);
+
QEMUFile *qemu_fopen_ops_buffered(void *opaque, size_t xfer_limit,
BufferedPutFunc *put_buffer,
+ BufferedBeginFunc *begin,
BufferedPutReadyFunc *put_ready,
BufferedWaitForUnfreezeFunc
*wait_for_unfreeze,
BufferedCloseFunc *close);
diff --git a/migration.c b/migration.c
index af3a1f2..bf86067 100644
--- a/migration.c
+++ b/migration.c
@@ -31,6 +31,8 @@
do { } while (0)
#endif
+static int64_t expire_time;
+
/* Migration speed throttling */
static int64_t max_throttle = (32 20);
@@ -284,8 +286,6 @@ int migrate_fd_cleanup(FdMigrationState *s)
{
int ret = 0;
-qemu_set_fd_handler2(s-fd, NULL, NULL, NULL, NULL);
-
if (s-file) {
DPRINTF(closing file\n);
if (qemu_fclose(s-file) != 0) {
@@ -310,8 +310,7 @@ int migrate_fd_cleanup(FdMigrationState *s)
void migrate_fd_put_notify(void *opaque)
{
FdMigrationState *s = opaque;
-
-
[Qemu-devel] [RFC PATCH v2 2/3] fine grained qemu_mutex locking for migration
In the migration thread, qemu_mutex is released during the most time consuming
part. i.e. during is_dup_page which identifies the uniform data pages and during
the put_buffer. qemu_mutex is also released while blocking on select to wait for
the descriptor to become ready for writes.
Signed-off-by: Umesh Deshpande udesh...@redhat.com
---
arch_init.c | 14 +++---
migration.c | 11 +++
2 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index 484b39d..cd545bc 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -110,7 +110,7 @@ static int is_dup_page(uint8_t *page, uint8_t ch)
static RAMBlock *last_block;
static ram_addr_t last_offset;
-static int ram_save_block(QEMUFile *f)
+static int ram_save_block(QEMUFile *f, int stage)
{
RAMBlock *block = last_block;
ram_addr_t offset = last_offset;
@@ -131,6 +131,10 @@ static int ram_save_block(QEMUFile *f)
current_addr + TARGET_PAGE_SIZE,
MIGRATION_DIRTY_FLAG);
+if (stage != 3) {
+qemu_mutex_unlock_iothread();
+}
+
p = block-host + offset;
if (is_dup_page(p, *p)) {
@@ -153,6 +157,10 @@ static int ram_save_block(QEMUFile *f)
bytes_sent = TARGET_PAGE_SIZE;
}
+if (stage != 3) {
+qemu_mutex_lock_iothread();
+}
+
break;
}
@@ -301,7 +309,7 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int stage,
void *opaque)
while (!qemu_file_rate_limit(f)) {
int bytes_sent;
-bytes_sent = ram_save_block(f);
+bytes_sent = ram_save_block(f, stage);
bytes_transferred += bytes_sent;
if (bytes_sent == 0) { /* no more blocks */
break;
@@ -322,7 +330,7 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int stage,
void *opaque)
int bytes_sent;
/* flush all remaining blocks regardless of rate limiting */
-while ((bytes_sent = ram_save_block(f)) != 0) {
+while ((bytes_sent = ram_save_block(f, stage)) != 0) {
bytes_transferred += bytes_sent;
}
cpu_physical_memory_set_dirty_tracking(0);
diff --git a/migration.c b/migration.c
index bf86067..992fef5 100644
--- a/migration.c
+++ b/migration.c
@@ -375,15 +375,19 @@ void migrate_fd_begin(void *arg)
if (ret 0) {
DPRINTF(failed, %d\n, ret);
migrate_fd_error(s);
-goto out;
+qemu_mutex_unlock_iothread();
+return;
}
expire_time = qemu_get_clock_ms(rt_clock) + 100;
migrate_fd_put_ready(s);
+qemu_mutex_unlock_iothread();
while (s-state == MIG_STATE_ACTIVE) {
if (migrate_fd_check_expire()) {
+qemu_mutex_lock_iothread();
buffered_rate_tick(s-file);
+qemu_mutex_unlock_iothread();
}
if (s-state != MIG_STATE_ACTIVE) {
@@ -392,12 +396,11 @@ void migrate_fd_begin(void *arg)
if (s-callback) {
migrate_fd_wait_for_unfreeze(s);
+qemu_mutex_lock_iothread();
s-callback(s);
+qemu_mutex_unlock_iothread();
}
}
-
-out:
-qemu_mutex_unlock_iothread();
}
--
1.7.4.1
[Qemu-devel] [RFC PATCH v2 3/3] Per memslot dirty bitmap
This patch creates a separate dirty bitmap for each slot. Currently dirty bitmap
is created for addresses ranging from 0 to the end address of the last memory
slot. Since the memslots are not necessarily contiguous, current bitmap might
contain empty region or holes that doesn't represent any VM pages. This patch
reduces the size of the dirty bitmap by allocating per memslot dirty bitmaps.
Signed-off-by: Umesh Deshpande udesh...@redhat.com
---
cpu-all.h | 40 +---
exec.c| 38 +++---
xen-all.c |6 ++
3 files changed, 58 insertions(+), 26 deletions(-)
diff --git a/cpu-all.h b/cpu-all.h
index e839100..9517a9b 100644
--- a/cpu-all.h
+++ b/cpu-all.h
@@ -920,6 +920,7 @@ extern ram_addr_t ram_size;
typedef struct RAMBlock {
uint8_t *host;
+uint8_t *phys_dirty;
ram_addr_t offset;
ram_addr_t length;
uint32_t flags;
@@ -931,7 +932,6 @@ typedef struct RAMBlock {
} RAMBlock;
typedef struct RAMList {
-uint8_t *phys_dirty;
QLIST_HEAD(ram, RAMBlock) blocks;
} RAMList;
extern RAMList ram_list;
@@ -961,32 +961,55 @@ extern int mem_prealloc;
#define CODE_DIRTY_FLAG 0x02
#define MIGRATION_DIRTY_FLAG 0x08
+RAMBlock *qemu_addr_to_ramblock(ram_addr_t);
+
+static inline int get_page_nr(ram_addr_t addr, RAMBlock **block)
+{
+int page_nr;
+*block = qemu_addr_to_ramblock(addr);
+
+page_nr = addr - (*block)-offset;
+page_nr = page_nr TARGET_PAGE_BITS;
+
+return page_nr;
+}
+
/* read dirty bit (return 0 or 1) */
static inline int cpu_physical_memory_is_dirty(ram_addr_t addr)
{
-return ram_list.phys_dirty[addr TARGET_PAGE_BITS] == 0xff;
+RAMBlock *block;
+int page_nr = get_page_nr(addr, block);
+return block-phys_dirty[page_nr] == 0xff;
}
static inline int cpu_physical_memory_get_dirty_flags(ram_addr_t addr)
{
-return ram_list.phys_dirty[addr TARGET_PAGE_BITS];
+RAMBlock *block;
+int page_nr = get_page_nr(addr, block);
+return block-phys_dirty[page_nr];
}
static inline int cpu_physical_memory_get_dirty(ram_addr_t addr,
int dirty_flags)
{
-return ram_list.phys_dirty[addr TARGET_PAGE_BITS] dirty_flags;
+RAMBlock *block;
+int page_nr = get_page_nr(addr, block);
+return block-phys_dirty[page_nr] dirty_flags;
}
static inline void cpu_physical_memory_set_dirty(ram_addr_t addr)
{
-ram_list.phys_dirty[addr TARGET_PAGE_BITS] = 0xff;
+RAMBlock *block;
+int page_nr = get_page_nr(addr, block);
+block-phys_dirty[page_nr] = 0xff;
}
static inline int cpu_physical_memory_set_dirty_flags(ram_addr_t addr,
int dirty_flags)
{
-return ram_list.phys_dirty[addr TARGET_PAGE_BITS] |= dirty_flags;
+RAMBlock *block;
+int page_nr = get_page_nr(addr, block);
+return block-phys_dirty[page_nr] |= dirty_flags;
}
static inline void cpu_physical_memory_mask_dirty_range(ram_addr_t start,
@@ -995,10 +1018,13 @@ static inline void
cpu_physical_memory_mask_dirty_range(ram_addr_t start,
{
int i, mask, len;
uint8_t *p;
+RAMBlock *block;
+int page_nr = get_page_nr(start, block);
len = length TARGET_PAGE_BITS;
mask = ~dirty_flags;
-p = ram_list.phys_dirty + (start TARGET_PAGE_BITS);
+
+p = block-phys_dirty + page_nr;
for (i = 0; i len; i++) {
p[i] = mask;
}
diff --git a/exec.c b/exec.c
index 0e2ce57..6312550 100644
--- a/exec.c
+++ b/exec.c
@@ -2106,6 +2106,10 @@ void cpu_physical_memory_reset_dirty(ram_addr_t start,
ram_addr_t end,
abort();
}
+if (kvm_enabled()) {
+return;
+}
+
for(env = first_cpu; env != NULL; env = env-next_cpu) {
int mmu_idx;
for (mmu_idx = 0; mmu_idx NB_MMU_MODES; mmu_idx++) {
@@ -2894,17 +2898,6 @@ static ram_addr_t find_ram_offset(ram_addr_t size)
return offset;
}
-static ram_addr_t last_ram_offset(void)
-{
-RAMBlock *block;
-ram_addr_t last = 0;
-
-QLIST_FOREACH(block, ram_list.blocks, next)
-last = MAX(last, block-offset + block-length);
-
-return last;
-}
-
ram_addr_t qemu_ram_alloc_from_ptr(DeviceState *dev, const char *name,
ram_addr_t size, void *host)
{
@@ -2974,10 +2967,8 @@ ram_addr_t qemu_ram_alloc_from_ptr(DeviceState *dev,
const char *name,
QLIST_INSERT_HEAD(ram_list.blocks, new_block, next);
-ram_list.phys_dirty = qemu_realloc(ram_list.phys_dirty,
- last_ram_offset() TARGET_PAGE_BITS);
-memset(ram_list.phys_dirty + (new_block-offset TARGET_PAGE_BITS),
- 0xff, size TARGET_PAGE_BITS);
+new_block-phys_dirty = qemu_mallocz(new_block-length
TARGET_PAGE_BITS);
+memset(new_block-phys_dirty, 0xff, new_block-length TARGET_PAGE_BITS);
if (kvm_enabled())
kvm_setup_guest_memory(new_block-host, size);
Re: [Qemu-devel] [RFC PATCH 0/4] Fix subsection ambiguity in the migration format
On 07/29/2011 10:18 AM, Kevin Wolf wrote: Am 29.07.2011 16:28, schrieb Anthony Liguori: The one change for backends is that if we migrate a device in way so that it can say I need the block backend with the ID 'foo', then we can at least make sure that the backend actually exists and is usable. Yup. So with QOM, this could work in a couple ways. You could dump the full graph including the backends, and then recreate it but not realize any objects. This would give you a chance to make changes to things like the block device filenames. It could be as simple as just changing the filename of a device, or deleting a complex block device chain (from backing files) and replacing it with something totally different. I think the common case is that the backends are much the same so I think an interface centered around recreating the backends verbatim but allowing tweaks would probably be the friendliest. We could also require that the backends are created before we migrate the device model. In QOM, while you would be allowed to create a virtio-blk device, when you tried to set the drive property to 'foo', you'd get an error unless the 'foo' backend existed and was of the appropriate type. Since it's pretty easy to enumerate the required backends, it's really not so bad for the management tools to do this work. My only concern is that this all has to happen in the migration downtime window in order for hotplug to work robustly. The result is that introspecting what's there and recreating it is insanely complex today. That's the motivation behind QOM. plug_list lists *everything*. All objects, whether they are created as part of the PIIX3 or whether it's a backing file, can be directly addressed and manipulated. If you look at qsh, there's an import command. The export command is trivial and I don't remember if I've already added it. But the point is that you should be able to 'qsh export' everything and then 'qsh import' everything to create the exact same device model in another QEMU instance. And yeah, this should end up becoming part of the migration protocol. If all you're saying is that we can't get it tomorrow, that's fine for me. Good to know that we agree on the goal anyway. Yup :-) 5) Once we're here, we can implement the next 5-year format. That could be ASN.1 and be bidirectional or whatever makes the most sense. We could support 50 formats if we wanted to. As long as the transport is distinct from the serialization and compat routines, it really doesn't matter. This means finishing the VMState support, once there, only thing needs to change is copy the savevm, and change the visitors to whatever else that we need/want. There's no need to finish VMState to convert to visitors. It's just sed -e 's:qemu_put_be32:visit_type_int32:g' Actually I think the real question is whether we want to have VMState or not. VMState doesn't give me what I want by itself. I want to be able to marshal the device tree to an in-memory representation that can be manipulated. One approach to doing that is first completing VMState, and then writing something that can walk the VMState descriptions. The VMState descriptions are fairly complicated but it's doable. Another approach, which I'm arguing is much simpler, the imperative nature of our current serialization and use visitors. There may be other advantages of a declarative description of VMState that would justify completing the conversions. But I don't think we need it to start improving the migration protocol. Yeah, I somehow read it as there's no reason to continue with converting to VMState, which isn't what you were saying. No, not at all. Just that converting everything to VMState isn't a prerequisite for building a more robust migration protocol. Regards, Anthony Liguori Kevin
[Qemu-devel] [PATCH] Fix forcing multicast msgs to loopback on OpenBSD.
Fix forcing multicast msgs to loopback on OpenBSD.
e.g.
$ sudo qemu -m 128 -no-fd-bootchk \
-hda virtual.img -boot n -nographic \
-net nic,vlan=0,model=rtl8139,macaddr=52:54:00:12:34:03 \
-net user -tftp /usr/src/sys/arch/i386/compile/TEST -bootp pxeboot \
-net nic,vlan=1,model=rtl8139,macaddr=52:54:00:23:03:01 \
-net tap,vlan=1,script=no \
-net nic,vlan=3,model=rtl8139,macaddr=52:54:00:23:03:03 \
-net socket,vlan=3,mcast=230.0.0.1:10003
setsockopt(SOL_IP, IP_MULTICAST_LOOP): Invalid argument
qemu: -net socket,vlan=3,mcast=230.0.0.1:10003: Device 'socket' could not be
initialized
Signed-off-by: Brad Smith b...@comstyle.com
---
net/socket.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/net/socket.c b/net/socket.c
index 11fe5f3..4c27097 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -154,6 +154,12 @@ static int net_socket_mcast_create(struct sockaddr_in
*mcastaddr, struct in_addr
struct ip_mreq imr;
int fd;
int val, ret;
+#ifdef __OpenBSD__
+u_char loop;
+#else
+int loop;
+#endif
+
if (!IN_MULTICAST(ntohl(mcastaddr-sin_addr.s_addr))) {
fprintf(stderr, qemu: error: specified mcastaddr \%s\ (0x%08x) does
not contain a multicast address\n,
inet_ntoa(mcastaddr-sin_addr),
@@ -197,9 +203,9 @@ static int net_socket_mcast_create(struct sockaddr_in
*mcastaddr, struct in_addr
}
/* Force mcast msgs to loopback (eg. several QEMUs in same host */
-val = 1;
+loop = 1;
ret=setsockopt(fd, IPPROTO_IP, IP_MULTICAST_LOOP,
- (const char *)val, sizeof(val));
+ (const char *)loop, sizeof(loop));
if (ret 0) {
perror(setsockopt(SOL_IP, IP_MULTICAST_LOOP));
goto fail;
--
1.7.6
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: [Qemu-devel] [PATCH] Fix gcc-4.6 compiler error
On 29 July 2011 20:30, Stefan Weil w...@mail.berlios.de wrote: Commit 3d3b8303c6f83b9b245bc774af530a6403cc4ce6 breaks builds with gcc-4.6: hw/fw_cfg.c: In function ‘probe_splashfile’: hw/fw_cfg.c:66:9: error: variable ‘fop_ret’ set but not used [-Werror=unused-but-set-variable] hw/fw_cfg.c: In function ‘fw_cfg_bootsplash’: hw/fw_cfg.c:130:9: error: variable ‘fop_ret’ set but not used [-Werror=unused-but-set-variable] Remove fop_ret. Testing the result of fread() is normally a good idea, but I don't think it is needed here. @@ -86,7 +85,7 @@ static FILE *probe_splashfile(char *filename, int *file_sizep, int *file_typep) } /* check magic ID */ fseek(fp, 0L, SEEK_SET); - fop_ret = fread(buf, 1, 2, fp); + (void)fread(buf, 1, 2, fp); Usually this kind of thing is added in order to stop gcc complaining about you ignoring the return value of a function which has been marked (by libc) as 'don't-ignore-return-value'. In such cases a (void) is not sufficient to suppress the return value ignored warning. At least some of these cases really should be checking fread return values; I see we also don't check fseek() return values either in all places. So the easiest fix is just to check all the fread() calls. Alternative suggestion: it would be easier to just slurp the whole file into memory (which is what we do once we've figured out it's an image) and then check the magic numbers in the memory buffer, which removes a lot of these unchecked function calls altogether. Since we're linking against glib anyway it looks like g_file_get_contents() would do 95% of the work for us. [disclaimer: I haven't used that API myself but it looks the right shape...g_malloc vs qemu_malloc issues, maybe?] Failing that, fopen/fstat/fread/fclose/check magic numbers. -- PMM
[Qemu-devel] [ANNOUNCE] QEMU 0.15.0-rc1 Release
Hi, On behalf of the entire QEMU team, I'm please to announce the release of QEMU 0.15.0-rc1. This is the second release candidate for the 0.15.0 release. There are numerous ways you can help participate in the 0.15.0 release. There is a testing coordination wiki page located at: http://wiki.qemu.org/Planning/0.15/Testing You can also help improve the ChangeLog documentation at: http://wiki.qemu.org/ChangeLog/0.15 And of course, you can download the 0.15.0-rc1 release at: http://wiki.qemu.org/download/qemu-0.15.0-rc1.tar.gz Below are the changes since the 0.15.0-rc0 release. I'd like to thank everyone who's participated in this release! - virtio-balloon: Unregister savevm section on device unplug (Amit Shah) - virtio-balloon: Add exit handler, fix memleaks (Amit Shah) - balloon: Reject negative balloon values (Amit Shah) - virtio-balloon: Check if balloon registration failed (Amit Shah) - balloon: Don't allow multiple balloon handler registrations (Amit Shah) - target-arm: UNDEF on a VCVTT/VCVTB UNPREDICTABLE to avoid TCG assert (Peter M - target-arm: Handle UNDEF and UNPREDICTABLE cases for VLDM, VSTM (Peter Maydel - target-arm: Support v6 barriers in linux-user mode (Peter Maydell) - target-arm: Mark 1136r1 as a v6K core (Peter Maydell) - virtio-balloon: Fix header comment; add Copyright (Amit Shah) - balloon: Fix header comment; add Copyright (Amit Shah) - balloon: Separate out stat and balloon handling (Amit Shah) - virtio-balloon: Separate status handling into separate function (Amit Shah) - balloon: Simplify code flow (Amit Shah) - balloon: Add braces around if statements (Amit Shah) - balloon: Make functions, local vars static (Amit Shah) - Let users select their pythons (Blue Swirl) - simpletrace: suppress a warning from unused variable (Blue Swirl) - Wrap recv to avoid warnings (Blue Swirl) - Fix chrdev return value conversion (Blue Swirl) - qemu-ga: remove dependency on gio and gthread (Anthony Liguori) - guest-agent: only enable FSFREEZE when it's supported by the kernel (Anthony Liguori) Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH 44/55] spitz tosa: Simplify drive is suitable for microdrive test
On 20 July 2011 18:24, Markus Armbruster arm...@redhat.com wrote: We try the drive defined with -drive if=ide,index=0 (or equivalent sugar). We use it only if (dinfo bdrv_is_inserted(dinfo-bdrv) !bdrv_is_removable(dinfo-bdrv)). This is a convoluted way to test for drive media can't be removed. The only way to create such a drive with -drive if=ide is media=cdrom. And that sets dinfo-media_cd, so just test that. This is a less generic test and more prone to be broken inadvertently, so it seems like a step back. What's the argument against the convoluted and explicit test? Cheers
Re: [Qemu-devel] [PATCH 1/6] VMDK: enable twoGbMaxExtentFlat
Enable the createType 'twoGbMaxExtentFlat'. The supporting code is
already in.
Signed-off-by: Fam Zheng famc...@gmail.com
---
block/vmdk.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/block/vmdk.c b/block/vmdk.c
index 37478d2..e22a893 100644
--- a/block/vmdk.c
+++ b/block/vmdk.c
@@ -551,7 +551,8 @@ static int vmdk_open_desc_file(BlockDriverState *bs, int
flags)
if (vmdk_parse_description(buf, createType, ct, sizeof(ct))) {
return -EINVAL;
}
-if (strcmp(ct, monolithicFlat)) {
+if (strcmp(ct, monolithicFlat)
+strcmp(ct, twoGbMaxExtentFlat)) {
fprintf(stderr,
VMDK: Not supported image type \%s\.\n, ct);
return -ENOTSUP;
@@ -672,6 +673,7 @@ static int get_cluster_offset(BlockDriverState *bs,
return 0;
}
+offset -= (extent-end_sector - extent-sectors) * SECTOR_SIZE;
l1_index = (offset 9) / extent-l1_entry_sectors;
if (l1_index = extent-l1_size) {
return -1;
Re: [Qemu-devel] [PATCH v5] Add support for Zipit Z2 machine
On 6 July 2011 15:52, Vasily Khoruzhick anars...@gmail.com wrote: Zipit Z2 is small PXA270 based handheld. Thanks, I pushed this version. Cheers
Re: [Qemu-devel] [PATCH 15/15] hw/onenand: program actions can only clear bits
On 29 July 2011 17:35, Peter Maydell peter.mayd...@linaro.org wrote:
From: Juha Riihimäki juha.riihim...@nokia.com
The program actions onenand_prog_main() and onenand_prog_spare()
can only set bits.
This implies a rewrite of onenand_erase() to not use the program
functions, since erase does need to set bits.
Signed-off-by: Juha Riihimäki juha.riihim...@nokia.com
[Riku Voipio: Fixes and restructuring patchset]
Signed-off-by: Riku Voipio riku.voi...@iki.fi
[Peter Maydell: More fixes and cleanups for upstream submission]
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
hw/onenand.c | 135 +
1 files changed, 106 insertions(+), 29 deletions(-)
diff --git a/hw/onenand.c b/hw/onenand.c
...
static inline int onenand_erase(OneNANDState *s, int sec, int num)
{
- /* TODO: optimise */
- uint8_t buf[512];
-
- memset(buf, 0xff, sizeof(buf));
- for (; num 0; num --, sec ++) {
- if (onenand_prog_main(s, sec, 1, buf))
- return 1;
- if (onenand_prog_spare(s, sec, 1, buf))
- return 1;
+ uint8_t *blankbuf, *tmpbuf;
+ blankbuf = qemu_malloc(512);
+ if (!blankbuf) {
+ return 1;
+ }
+ tmpbuf = qemu_malloc(512);
+ if (!tmpbuf) {
+ qemu_free(blankbuf);
+ return 1;
+ }
+ memset(blankbuf, 0xff, 512);
+ for (; num 0; num--, sec++) {
+ if (s-bdrv_cur) {
+ int erasesec = s-secs_cur + (sec 5);
+ if (bdrv_write(s-bdrv_cur, sec, blankbuf, 1)) {
+ goto fail;
+ }
+ if (bdrv_read(s-bdrv_cur, erasesec, tmpbuf, 1) 0) {
+ goto fail;
+ }
+ memcpy(tmpbuf + ((sec 31) 4), blankbuf, 1 4);
+ if (bdrv_write(s-bdrv_cur, erasesec, tmpbuf, 1) 0) {
+ goto fail;
+ }
By the way it seems that this can be optimised to require just one
read for the entire erase.
Cheers
[Qemu-devel] [PATCH] Add support for finding libpng via pkg-config
Add support for finding libpng via pkg-config.
Signed-off-by: Brad Smith b...@comstyle.com
---
configure |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/configure b/configure
index 4012d15..25aa75f 100755
--- a/configure
+++ b/configure
@@ -1519,11 +1519,17 @@ int main(void) {
return 0;
}
EOF
+ if $pkg_config libpng --modversion /dev/null 21; then
+vnc_png_cflags=`$pkg_config libpng --cflags 2 /dev/null`
+vnc_png_libs=`$pkg_config libpng --libs 2 /dev/null`
+ else
vnc_png_cflags=
vnc_png_libs=-lpng
+ fi
if compile_prog $vnc_png_cflags $vnc_png_libs ; then
vnc_png=yes
libs_softmmu=$vnc_png_libs $libs_softmmu
+QEMU_CFLAGS=$QEMU_CFLAGS $vnc_png_cflags
else
if test $vnc_png = yes ; then
feature_not_found vnc-png
--
1.7.6
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: [Qemu-devel] [PATCH 2/7] sd: fix card size checking on R/W accesses
Hi Vincent,
On 26 July 2011 01:19, Vincent Palatin vpala...@chromium.org wrote:
We need to check that we are not crossing the boundaries of the card for
the current access not for the next one which might not happen.
Signed-off-by: Vincent Palatin vpala...@chromium.org
---
hw/sd.c | 22 --
1 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/hw/sd.c b/hw/sd.c
index f48d589..de477fe 100644
--- a/hw/sd.c
+++ b/hw/sd.c
@@ -1451,11 +1451,6 @@ void sd_write_data(SDState *sd, uint8_t value)
sd-data[sd-data_offset ++] = value;
if (sd-data_offset = sd-blk_len) {
/* TODO: Check CRC before committing */
- sd-state = sd_programming_state;
- BLK_WRITE_BLOCK(sd-data_start, sd-data_offset);
- sd-blk_written ++;
- sd-data_start += sd-blk_len;
- sd-data_offset = 0;
if (sd-data_start + sd-blk_len sd-size) {
sd-card_status |= ADDRESS_ERROR;
break;
@@ -1464,6 +1459,11 @@ void sd_write_data(SDState *sd, uint8_t value)
sd-card_status |= WP_VIOLATION;
break;
}
+ sd-state = sd_programming_state;
+ BLK_WRITE_BLOCK(sd-data_start, sd-data_offset);
+ sd-blk_written ++;
+ sd-data_start += sd-blk_len;
+ sd-data_offset = 0;
sd-csd[14] |= 0x40;
/* Bzzztt Operation complete. */
@@ -1606,17 +1606,19 @@ uint8_t sd_read_data(SDState *sd)
break;
case 18: /* CMD18: READ_MULTIPLE_BLOCK */
- if (sd-data_offset == 0)
+ if (sd-data_offset == 0) {
+ if (sd-data_start + io_len sd-size) {
+ sd-card_status |= ADDRESS_ERROR;
+ ret = 0;
+ break;
+ }
BLK_READ_BLOCK(sd-data_start, io_len);
+ }
ret = sd-data[sd-data_offset ++];
if (sd-data_offset = io_len) {
sd-data_start += io_len;
sd-data_offset = 0;
- if (sd-data_start + io_len sd-size) {
- sd-card_status |= ADDRESS_ERROR;
- break;
- }
}
break;
I have to look more closely at the spec but it looks like
ADDRESS_ERROR might not even be the right error code for when we
read/write outside of the memory, because the spec says it's for
incorrect alignment. Also the first chunk of this patch is
unnecessary now because I committed a patch from Peter Maydell that
did the same thing.
I pushed your patch 01 in the series, thanks.
Cheers
Re: [Qemu-devel] [PATCH v2] usb-hid: Fix 0/0 position for Windows in tablet mode
On 13 July 2011 23:05, Andreas Färber andreas.faer...@web.de wrote:
Am 12.07.2011 um 09:47 schrieb Jan Kiszka:
On 2011-07-04 20:15, andrzej zaborowski wrote:
On 26 June 2011 11:11, Jan Kiszka jan.kis...@web.de wrote:
On 2011-06-25 15:10, Andreas Färber wrote:
Am 25.06.2011 um 14:55 schrieb Jan Kiszka:
On 2011-06-25 14:37, Andreas Färber wrote:
Am 24.06.2011 um 16:27 schrieb Jan Kiszka:
For unknown reasons, Windows drivers (tested with XP and Win7)
ignore
usb-tablet events that move the pointer to 0/0. So always set bit 0
of
the coordinates.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/usb-hid.c | 6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/hw/usb-hid.c b/hw/usb-hid.c
index d711b5c..2b9a451 100644
--- a/hw/usb-hid.c
+++ b/hw/usb-hid.c
@@ -457,8 +457,10 @@ static void
usb_pointer_event_combine(USBPointerEvent *e, int xyrel,
e-xdx += x1;
e-ydy += y1;
} else {
- e-xdx = x1;
- e-ydy = y1;
+ /* Windows drivers do not like the 0/0 position and ignore
such
+ * events. */
+ e-xdx = x1 | 1;
+ e-ydy = y1 | 1;
Doesn't this change mean we can't access any other even pixel either?
Only on 32767x32767 screens (that's the resolution of the tablet).
Well, if it's just a fix for 0/0 I would've expected something like:
e-xdx = x1 ? x1 : 1;
e-ydy = y1 ? y1 : 1;
Works as well, my version is a little bit simpler. But I don't mind,
will post whatever is preferred to fix this.
Would it be enough to just do this for x or y, not both?
Yes, looks like. Is this one better?
I pushed this version, thanks.
Cheers
Re: [Qemu-devel] [PATCH] user: Restore debug usage message for '-d ?' in user mode emulation
On 18 July 2011 12:44, Peter Maydell peter.mayd...@linaro.org wrote: The code which prints the debug usage message on '-d ?' for *-user has to come before the check for not enough arguments, so that qemu-foo -d ? prints the list of possible debug log items rather than the generic usage message. (This was inadvertently broken in commit c235d73.) I pushed this patch, thanks. Cheers
