Re: [Qemu-devel] [PATCH RFC] virtio: put last seen used index into ring itself
On 05/23/2010 07:30 PM, Michael S. Tsirkin wrote:
Maybe we should use atomics on index then?
This should only be helpful if you access the cacheline several times in
a row. That's not the case in virtio (or here).
So why does it help?
We actually do access the cacheline several times in a row here (but not
in virtio?):
case SHARE:
while (count< MAX_BOUNCES) {
/* Spin waiting for other side to change it. */
while (counter->cacheline1 != count);
Broadcast a read request.
count++;
counter->cacheline1 = count;
Broadcast an invalidate request.
count++;
}
break;
case LOCKSHARE:
while (count< MAX_BOUNCES) {
/* Spin waiting for other side to change it. */
while
(__sync_val_compare_and_swap(&counter->cacheline1, count, count+1)
!= count);
Broadcast a 'read for ownership' request.
count += 2;
}
break;
So RMW should certainly by faster using single-instruction RMW
operations (or using prefetchw).
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
[Qemu-devel] Re: [PATCH] add support for protocol driver create_options
At Fri, 21 May 2010 18:57:36 +0200,
Kevin Wolf wrote:
>
> Am 20.05.2010 07:36, schrieb MORITA Kazutaka:
> > +
> > +/*
> > + * Append an option list (list) to an option list (dest).
> > + *
> > + * If dest is NULL, a new copy of list is created.
> > + *
> > + * Returns a pointer to the first element of dest (or the newly allocated
> > copy)
> > + */
> > +QEMUOptionParameter *append_option_parameters(QEMUOptionParameter *dest,
> > +QEMUOptionParameter *list)
> > +{
> > +size_t num_options, num_dest_options;
> > +
> > +num_options = count_option_parameters(dest);
> > +num_dest_options = num_options;
> > +
> > +num_options += count_option_parameters(list);
> > +
> > +dest = qemu_realloc(dest, (num_options + 1) *
> > sizeof(QEMUOptionParameter));
> > +
> > +while (list && list->name) {
> > +if (get_option_parameter(dest, list->name) == NULL) {
> > +dest[num_dest_options++] = *list;
>
> You need to add a dest[num_dest_options].name = NULL; here. Otherwise
> the next loop iteration works on uninitialized memory and possibly an
> unterminated list. I got a segfault for that reason.
>
I forgot to add it, sorry.
Fixed version is below.
Thanks,
Kazutaka
==
This patch enables protocol drivers to use their create options which
are not supported by the format. For example, protcol drivers can use
a backing_file option with raw format.
Signed-off-by: MORITA Kazutaka
---
block.c |7 +++
block.h |1 +
qemu-img.c| 49 ++---
qemu-option.c | 53 ++---
qemu-option.h |2 ++
5 files changed, 86 insertions(+), 26 deletions(-)
diff --git a/block.c b/block.c
index 202f895..3ed35ed 100644
--- a/block.c
+++ b/block.c
@@ -56,7 +56,6 @@ static int bdrv_read_em(BlockDriverState *bs, int64_t
sector_num,
uint8_t *buf, int nb_sectors);
static int bdrv_write_em(BlockDriverState *bs, int64_t sector_num,
const uint8_t *buf, int nb_sectors);
-static BlockDriver *find_protocol(const char *filename);
static QTAILQ_HEAD(, BlockDriverState) bdrv_states =
QTAILQ_HEAD_INITIALIZER(bdrv_states);
@@ -210,7 +209,7 @@ int bdrv_create_file(const char* filename,
QEMUOptionParameter *options)
{
BlockDriver *drv;
-drv = find_protocol(filename);
+drv = bdrv_find_protocol(filename);
if (drv == NULL) {
drv = bdrv_find_format("file");
}
@@ -283,7 +282,7 @@ static BlockDriver *find_hdev_driver(const char *filename)
return drv;
}
-static BlockDriver *find_protocol(const char *filename)
+BlockDriver *bdrv_find_protocol(const char *filename)
{
BlockDriver *drv1;
char protocol[128];
@@ -469,7 +468,7 @@ int bdrv_file_open(BlockDriverState **pbs, const char
*filename, int flags)
BlockDriver *drv;
int ret;
-drv = find_protocol(filename);
+drv = bdrv_find_protocol(filename);
if (!drv) {
return -ENOENT;
}
diff --git a/block.h b/block.h
index b95a9c0..bd11cc0 100644
--- a/block.h
+++ b/block.h
@@ -54,6 +54,7 @@ void bdrv_info_stats(Monitor *mon, QObject **ret_data);
void bdrv_init(void);
void bdrv_init_with_whitelist(void);
+BlockDriver *bdrv_find_protocol(const char *filename);
BlockDriver *bdrv_find_format(const char *format_name);
BlockDriver *bdrv_find_whitelisted_format(const char *format_name);
int bdrv_create(BlockDriver *drv, const char* filename,
diff --git a/qemu-img.c b/qemu-img.c
index d3c30a7..8ae7184 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -252,8 +252,8 @@ static int img_create(int argc, char **argv)
const char *base_fmt = NULL;
const char *filename;
const char *base_filename = NULL;
-BlockDriver *drv;
-QEMUOptionParameter *param = NULL;
+BlockDriver *drv, *proto_drv;
+QEMUOptionParameter *param = NULL, *create_options = NULL;
char *options = NULL;
flags = 0;
@@ -286,33 +286,42 @@ static int img_create(int argc, char **argv)
}
}
+/* Get the filename */
+if (optind >= argc)
+help();
+filename = argv[optind++];
+
/* Find driver and parse its options */
drv = bdrv_find_format(fmt);
if (!drv)
error("Unknown file format '%s'", fmt);
+proto_drv = bdrv_find_protocol(filename);
+if (!proto_drv)
+error("Unknown protocol '%s'", filename);
+
+create_options = append_option_parameters(create_options,
+ drv->create_options);
+create_options = append_option_parameters(create_options,
+ proto_drv->create_options);
+
if (options && !strcmp(options, "?")) {
-print_option_help(drv->create_options);
+print_option_help(create_options);
return 0;
}
/* Create parameter list with default values */
-param = parse_option_parameters("", drv->create_options, param);
+para
[Qemu-devel] Re: [PATCH] add support for protocol driver create_options
At Fri, 21 May 2010 13:40:31 +0200, Kevin Wolf wrote: > > Am 20.05.2010 07:36, schrieb MORITA Kazutaka: > > This patch enables protocol drivers to use their create options which > > are not supported by the format. For example, protcol drivers can use > > a backing_file option with raw format. > > > > Signed-off-by: MORITA Kazutaka > > Hm, this is not stackable, right? Though I do see that making it > stackable would require some bigger changes, so maybe we can get away > with claiming that this approach covers everything that happens in practice. > > If we accept that this is the desired behaviour, the code looks good to me. > As you say, this patch isn't stackable; we must specify a image name with at most 1 format and 1 protocol. I cannot think of a situation where we want to use more than one protocol to create qemu images, so this seems to be enough to me. Thanks, Kazutaka
[Qemu-devel] [PATCH RFC 1/2] Change phys_ram_dirty to phys_ram_status
The phys_ram_dirty array consists of 8-bit values for storing 3 dirty bits.
Change to more generic phys_ram_flags and use lower 4-bits for dirty status and
leave upper 4 for other uses of marking memory pages.
One potential use for upper bits is to mark certain device pages to not be
migrated.
Some functions such as cpu_physical_memory_get_dirty_flags() may need to be
renamed to cpu_physical_memory_get_flags(). But I wanted to solicite feedback
before making more widespread changes.
Cam
---
cpu-all.h | 16 +---
exec.c| 36 ++--
2 files changed, 27 insertions(+), 25 deletions(-)
diff --git a/cpu-all.h b/cpu-all.h
index 52a1817..a4bb4fb 100644
--- a/cpu-all.h
+++ b/cpu-all.h
@@ -856,7 +856,7 @@ target_phys_addr_t cpu_get_phys_page_debug(CPUState *env,
target_ulong addr);
/* memory API */
extern int phys_ram_fd;
-extern uint8_t *phys_ram_dirty;
+extern uint8_t *phys_ram_flags;
extern ram_addr_t ram_size;
extern ram_addr_t last_ram_offset;
@@ -885,32 +885,34 @@ extern int mem_prealloc;
#define CODE_DIRTY_FLAG 0x02
#define MIGRATION_DIRTY_FLAG 0x08
+#define DIRTY_ALL_FLAG (VGA_DIRTY_FLAG | CODE_DIRTY_FLAG |
MIGRATION_DIRTY_FLAG)
+
/* read dirty bit (return 0 or 1) */
static inline int cpu_physical_memory_is_dirty(ram_addr_t addr)
{
-return phys_ram_dirty[addr >> TARGET_PAGE_BITS] == 0xff;
+return phys_ram_flags[addr >> TARGET_PAGE_BITS] == DIRTY_ALL_FLAG;
}
static inline int cpu_physical_memory_get_dirty_flags(ram_addr_t addr)
{
-return phys_ram_dirty[addr >> TARGET_PAGE_BITS];
+return phys_ram_flags[addr >> TARGET_PAGE_BITS];
}
static inline int cpu_physical_memory_get_dirty(ram_addr_t addr,
int dirty_flags)
{
-return phys_ram_dirty[addr >> TARGET_PAGE_BITS] & dirty_flags;
+return phys_ram_flags[addr >> TARGET_PAGE_BITS] & dirty_flags;
}
static inline void cpu_physical_memory_set_dirty(ram_addr_t addr)
{
-phys_ram_dirty[addr >> TARGET_PAGE_BITS] = 0xff;
+phys_ram_flags[addr >> TARGET_PAGE_BITS] = DIRTY_ALL_FLAG;
}
static inline int cpu_physical_memory_set_dirty_flags(ram_addr_t addr,
int dirty_flags)
{
-return phys_ram_dirty[addr >> TARGET_PAGE_BITS] |= dirty_flags;
+return phys_ram_flags[addr >> TARGET_PAGE_BITS] |= dirty_flags;
}
static inline void cpu_physical_memory_mask_dirty_range(ram_addr_t start,
@@ -922,7 +924,7 @@ static inline void
cpu_physical_memory_mask_dirty_range(ram_addr_t start,
len = length >> TARGET_PAGE_BITS;
mask = ~dirty_flags;
-p = phys_ram_dirty + (start >> TARGET_PAGE_BITS);
+p = phys_ram_flags + (start >> TARGET_PAGE_BITS);
for (i = 0; i < len; i++) {
p[i] &= mask;
}
diff --git a/exec.c b/exec.c
index a72d681..07dc8b6 100644
--- a/exec.c
+++ b/exec.c
@@ -116,7 +116,7 @@ uint8_t *code_gen_ptr;
#if !defined(CONFIG_USER_ONLY)
int phys_ram_fd;
-uint8_t *phys_ram_dirty;
+uint8_t *phys_ram_flags;
static int in_migration;
typedef struct RAMBlock {
@@ -2796,10 +2796,10 @@ ram_addr_t qemu_ram_map(ram_addr_t size, void *host)
new_block->next = ram_blocks;
ram_blocks = new_block;
-phys_ram_dirty = qemu_realloc(phys_ram_dirty,
+phys_ram_flags = qemu_realloc(phys_ram_flags,
(last_ram_offset + size) >> TARGET_PAGE_BITS);
-memset(phys_ram_dirty + (last_ram_offset >> TARGET_PAGE_BITS),
- 0xff, size >> TARGET_PAGE_BITS);
+memset(phys_ram_flags + (last_ram_offset >> TARGET_PAGE_BITS),
+ DIRTY_ALL_FLAG, size >> TARGET_PAGE_BITS);
last_ram_offset += size;
@@ -2848,10 +2848,10 @@ ram_addr_t qemu_ram_alloc(ram_addr_t size)
new_block->next = ram_blocks;
ram_blocks = new_block;
-phys_ram_dirty = qemu_realloc(phys_ram_dirty,
+phys_ram_flags = qemu_realloc(phys_ram_flags,
(last_ram_offset + size) >> TARGET_PAGE_BITS);
-memset(phys_ram_dirty + (last_ram_offset >> TARGET_PAGE_BITS),
- 0xff, size >> TARGET_PAGE_BITS);
+memset(phys_ram_flags + (last_ram_offset >> TARGET_PAGE_BITS),
+ DIRTY_ALL_FLAG, size >> TARGET_PAGE_BITS);
last_ram_offset += size;
@@ -3019,11 +3019,11 @@ static void notdirty_mem_writeb(void *opaque,
target_phys_addr_t ram_addr,
#endif
}
stb_p(qemu_get_ram_ptr(ram_addr), val);
-dirty_flags |= (0xff & ~CODE_DIRTY_FLAG);
+dirty_flags |= (DIRTY_ALL_FLAG & ~CODE_DIRTY_FLAG);
cpu_physical_memory_set_dirty_flags(ram_addr, dirty_flags);
/* we remove the notdirty callback only if the code has been
flushed */
-if (dirty_flags == 0xff)
+if (dirty_flags == DIRTY_ALL_FLAG)
tlb_set_dirty(cpu_single_env, cpu_single_env->mem_io_vaddr);
}
@@ -3039,11 +3039,11 @@ static void notdirty_mem_writew(void *opaque,
target_phys_addr_t ram_addr,
#endif
}
stw_p(qemu_get_ram_ptr(ram_addr), val);
-dirty_flags |= (0xff & ~CODE_DI
[Qemu-devel] [PATCH RFC 2/2] Add support for marking memory to not be migrated
Non-migrated memory is useful for devices that do not want to take memory
region data with them on migration.
As suggested by Avi, an alternative approach could add a "flags" parameter to
cpu_register_physical_memory() rather than explicityly call
cpu_mark_pages_no_migrate(). However, having a separate function doesn't
require changes to existing call sites.
Cam
---
arch_init.c | 29 +
cpu-all.h|2 ++
cpu-common.h |2 ++
exec.c | 12
4 files changed, 33 insertions(+), 12 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index cfc03ea..c2fcad3 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -118,18 +118,22 @@ static int ram_save_block(QEMUFile *f)
current_addr + TARGET_PAGE_SIZE,
MIGRATION_DIRTY_FLAG);
-p = qemu_get_ram_ptr(current_addr);
-
-if (is_dup_page(p, *p)) {
-qemu_put_be64(f, current_addr | RAM_SAVE_FLAG_COMPRESS);
-qemu_put_byte(f, *p);
-} else {
-qemu_put_be64(f, current_addr | RAM_SAVE_FLAG_PAGE);
-qemu_put_buffer(f, p, TARGET_PAGE_SIZE);
-}
+if (!cpu_physical_memory_get_dirty(current_addr,
+NO_MIGRATION_FLAG)) {
+p = qemu_get_ram_ptr(current_addr);
+printf("migrating: %ld\n", (long)current_addr);
+
+if (is_dup_page(p, *p)) {
+qemu_put_be64(f, current_addr | RAM_SAVE_FLAG_COMPRESS);
+qemu_put_byte(f, *p);
+} else {
+qemu_put_be64(f, current_addr | RAM_SAVE_FLAG_PAGE);
+qemu_put_buffer(f, p, TARGET_PAGE_SIZE);
+}
-found = 1;
-break;
+found = 1;
+break;
+}
}
addr += TARGET_PAGE_SIZE;
current_addr = (saved_addr + addr) % last_ram_offset;
@@ -146,7 +150,8 @@ static ram_addr_t ram_save_remaining(void)
ram_addr_t count = 0;
for (addr = 0; addr < last_ram_offset; addr += TARGET_PAGE_SIZE) {
-if (cpu_physical_memory_get_dirty(addr, MIGRATION_DIRTY_FLAG)) {
+if (!cpu_physical_memory_get_dirty(addr, NO_MIGRATION_FLAG) &&
+cpu_physical_memory_get_dirty(addr, MIGRATION_DIRTY_FLAG)) {
count++;
}
}
diff --git a/cpu-all.h b/cpu-all.h
index a4bb4fb..8e2e8c4 100644
--- a/cpu-all.h
+++ b/cpu-all.h
@@ -885,6 +885,8 @@ extern int mem_prealloc;
#define CODE_DIRTY_FLAG 0x02
#define MIGRATION_DIRTY_FLAG 0x08
+#define NO_MIGRATION_FLAG 0x10
+
#define DIRTY_ALL_FLAG (VGA_DIRTY_FLAG | CODE_DIRTY_FLAG |
MIGRATION_DIRTY_FLAG)
/* read dirty bit (return 0 or 1) */
diff --git a/cpu-common.h b/cpu-common.h
index 4b0ba60..a1ebbbe 100644
--- a/cpu-common.h
+++ b/cpu-common.h
@@ -39,6 +39,8 @@ static inline void
cpu_register_physical_memory(target_phys_addr_t start_addr,
cpu_register_physical_memory_offset(start_addr, size, phys_offset, 0);
}
+void cpu_mark_pages_no_migrate(ram_addr_t start, uint64_t size);
+
ram_addr_t cpu_get_physical_page_desc(target_phys_addr_t addr);
ram_addr_t qemu_ram_map(ram_addr_t size, void *host);
ram_addr_t qemu_ram_alloc(ram_addr_t);
diff --git a/exec.c b/exec.c
index 07dc8b6..8c8053f 100644
--- a/exec.c
+++ b/exec.c
@@ -2781,6 +2781,18 @@ static void *file_ram_alloc(ram_addr_t memory, const
char *path)
}
#endif
+void cpu_mark_pages_no_migrate(ram_addr_t start, uint64_t length)
+{
+int i, len;
+uint8_t *p;
+
+len = length >> TARGET_PAGE_BITS;
+p = phys_ram_flags + (start >> TARGET_PAGE_BITS);
+for (i = 0; i < len; i++) {
+p[i] |= NO_MIGRATION_FLAG;
+}
+}
+
ram_addr_t qemu_ram_map(ram_addr_t size, void *host)
{
RAMBlock *new_block;
--
1.6.3.2.198.g6096d
Re: [Qemu-devel] [Bug 521994] Re: Windows 98 doesn't detect mouse on qemu and SeaBIOS.
On Wed, May 19, 2010 at 07:31:29PM -, Anthony Liguori wrote: > ** Changed in: qemu >Status: New => Confirmed > > -- > Windows 98 doesn't detect mouse on qemu and SeaBIOS. > https://bugs.launchpad.net/bugs/521994 > You received this bug notification because you are a member of qemu- > devel-ml, which is subscribed to QEMU. > > Status in QEMU: Confirmed [...] > Starting SeaBIOS (version 0.5.1-20100111_132716-squirrel.codemonkey.ws) A number of bug fixes for PS2 port were implemented back in March. The SeaBIOS v0.6.0 release has these bug fixes. I don't have Windows 98 to test. Could someone confirm if 0.6.0 fixes the problem? -Kevin
Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm
On Sun, May 23, 2010 at 12:59 AM, Blue Swirl wrote:
> On Thu, May 20, 2010 at 11:02 PM, Yehuda Sadeh Weinraub
> wrote:
>> On Thu, May 20, 2010 at 1:31 PM, Blue Swirl wrote:
>>> On Wed, May 19, 2010 at 7:22 PM, Christian Brunner wrote:
The attached patch is a block driver for the distributed file system
Ceph (http://ceph.newdream.net/). This driver uses librados (which
is part of the Ceph server) for direct access to the Ceph object
store and is running entirely in userspace. Therefore it is
called "rbd" - rados block device.
>> ...
>>>
>>> IIRC underscores here may conflict with system header use. Please use
>>> something like QEMU_BLOCK_RADOS_H.
>>
>> This header is shared between the linux kernel client and the ceph
>> userspace servers and client. We can actually get rid of it, as we
>> only need it to define CEPH_OSD_TMAP_SET. We can move this definition
>> to librados.h.
>>
diff --git a/block/rbd_types.h b/block/rbd_types.h
new file mode 100644
index 000..dfd5aa0
--- /dev/null
+++ b/block/rbd_types.h
@@ -0,0 +1,48 @@
+#ifndef _FS_CEPH_RBD
+#define _FS_CEPH_RBD
>>>
>>> QEMU_BLOCK_RBD?
>>
>> This header is shared between the ceph kernel client, between the qemu
>> rbd module (and between other ceph utilities). It'd be much easier
>> maintaining it without having to have a different implementation for
>> each. The same goes to the use of __le32/64 and __u32/64 within these
>> headers.
>
> This is user space, so identifiers must conform to C standards. The
> identifiers beginning with underscores are reserved.
>
> Doesn't __le32/64 also depend on some GCC extension? Or sparse magic?
It depends on gcc extension. If needed we can probably have a separate
header for the qemu block device that uses alternative types. Though
looking at the qemu code I see use of other gcc extensions so I'm not
sure this is a real issue.
>
>>
>>>
+
+#include
>>>
>>> Can you use standard includes, like or ? Are
>>> Ceph libraries used in other systems than Linux?
>>
>> Not at the moment. I guess that we can take this include out.
>>
>>>
+
+/*
+ * rbd image 'foo' consists of objects
+ * foo.rbd - image metadata
+ * foo.
+ * foo.0001
+ * ... - data
+ */
+
+#define RBD_SUFFIX ".rbd"
+#define RBD_DIRECTORY "rbd_directory"
+
+#define RBD_DEFAULT_OBJ_ORDER 22 /* 4MB */
+
+#define RBD_MAX_OBJ_NAME_SIZE 96
+#define RBD_MAX_SEG_NAME_SIZE 128
+
+#define RBD_COMP_NONE 0
+#define RBD_CRYPT_NONE 0
+
+static const char rbd_text[] = "<<< Rados Block Device Image >>>\n";
+static const char rbd_signature[] = "RBD";
+static const char rbd_version[] = "001.001";
+
+struct rbd_obj_snap_ondisk {
+ __le64 id;
+ __le64 image_size;
+} __attribute__((packed));
+
+struct rbd_obj_header_ondisk {
+ char text[64];
+ char signature[4];
+ char version[8];
+ __le64 image_size;
>>>
>>> Unaligned? Is the disk format fixed?
>>
>> This is a packed structure that represents the on disk format.
>> Operations on it are being done only to read from the disk header or
>> to write to the disk header.
>
> That's clear. But what exactly is the alignment of field 'image_size'?
> Could there be implicit padding to mod 8 between 'version' and
> 'image_size' with some compilers?
Obviously it's not 64 bit aligned. As it's an on-disk header, I don't
see alignment a real issue. As was said before, any operation on these
fields have to go through endianity conversion anyway, and this
structure should not be used directly. For such datastructures I'd
rather have the fields ordered in some logical order than maintaining
the alignment by ourselves. That's why we have that __attribute__
packed in the end to let the compiler deal with those issues. Other
compilers though have their own syntax for packed structures (but I do
see other uses of this packed syntax in the qemu code).
>
> If there were no other constraints, I'd either make the padding
> explicit, or rearrange/resize fields so that the field alignment is
> natural. Thus my question, can you change the disk format or are there
> already some deployments?
We can certainly make changes to the disk format at this point. I'm
not very happy with those 3 __u8 in the middle, and they can probably
be changed to a 32 bit flags field. We can get it 64 bit aligned too.
>
> Otherwise, I'd just add some warning comment so people don't try to
> use clever pointer tricks which will crash on machines with enforced
> alignment.
>
Any clever pointer tricks that'll work on one architecture will
probably be wrong on another (different word
size/alignment/endianity), so maybe crashing machines is a good
indicator to bad implementation. We shouldn't try to hide the
problems.
Than
[Qemu-devel] [PATCH] linux-user: display cpu list.
From: Laurent Vivier As it is done for qemu-system with "-cpu ?", when cpu_list_id() is missing for a target, call cpu_list() instead. Signed-off-by: Laurent Vivier --- linux-user/main.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/linux-user/main.c b/linux-user/main.c index b240f29..f6fd6e3 100644 --- a/linux-user/main.c +++ b/linux-user/main.c @@ -2797,6 +2797,8 @@ int main(int argc, char **argv, char **envp) /* XXX: implement xxx_cpu_list for targets that still miss it */ #if defined(cpu_list_id) cpu_list_id(stdout, &fprintf, ""); +#elif defined(cpu_list) +cpu_list(stdout, &fprintf); /* deprecated */ #endif exit(1); } -- 1.7.0.4
[Qemu-devel] [PATCH, RFC 4/4] apb: use IO_MEM_BSWAP with device registration
Signed-off-by: Blue Swirl
---
hw/apb_pci.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/apb_pci.c b/hw/apb_pci.c
index fb23397..cfa198c 100644
--- a/hw/apb_pci.c
+++ b/hw/apb_pci.c
@@ -323,7 +323,7 @@ static void apb_register_mem(void *opaque,
pcibus_t addr, pcibus_t size, int mm)
APB_DPRINTF("%s: addr %" FMT_PCIBUS " size %" FMT_PCIBUS "mm %x\n",
__func__, addr, size, mm);
-cpu_register_physical_memory(addr + d->mem_base, size, mm);
+cpu_register_physical_memory(addr + d->mem_base, size, mm | IO_MEM_BSWAP);
}
static void apb_unregister_mem(void *opaque, pcibus_t addr, pcibus_t size)
--
1.6.2.4
[Qemu-devel] [PATCH, RFC 2/4] Convert PCI devices to use pci_register_memory()
Signed-off-by: Blue Swirl
---
hw/cirrus_vga.c | 12 ++--
hw/e1000.c|2 +-
hw/eepro100.c |2 +-
hw/isa.h |1 +
hw/isa_mmio.c | 18 --
hw/lsi53c895a.c |4 ++--
hw/macio.c| 24
hw/msix.c |4 ++--
hw/openpic.c |6 +++---
hw/pcnet.c|3 ++-
hw/rtl8139.c |2 +-
hw/sun4u.c|7 +--
hw/usb-ohci.c |2 +-
hw/vga-pci.c |4 ++--
hw/vmware_vga.c |7 +++
hw/wdt_i6300esb.c |2 +-
16 files changed, 59 insertions(+), 41 deletions(-)
diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
index ba48289..52e51e0 100644
--- a/hw/cirrus_vga.c
+++ b/hw/cirrus_vga.c
@@ -3145,10 +3145,10 @@ static void cirrus_pci_lfb_map(PCIDevice *d,
int region_num,
CirrusVGAState *s = &DO_UPCAST(PCICirrusVGAState, dev, d)->cirrus_vga;
/* XXX: add byte swapping apertures */
-cpu_register_physical_memory(addr, s->vga.vram_size,
-s->cirrus_linear_io_addr);
-cpu_register_physical_memory(addr + 0x100, 0x40,
-s->cirrus_linear_bitblt_io_addr);
+pci_register_memory(d->bus, addr, s->vga.vram_size,
+s->cirrus_linear_io_addr);
+pci_register_memory(d->bus, addr + 0x100, 0x40,
+s->cirrus_linear_bitblt_io_addr);
s->vga.map_addr = s->vga.map_end = 0;
s->vga.lfb_addr = addr & TARGET_PAGE_MASK;
@@ -3165,8 +3165,8 @@ static void cirrus_pci_mmio_map(PCIDevice *d,
int region_num,
{
CirrusVGAState *s = &DO_UPCAST(PCICirrusVGAState, dev, d)->cirrus_vga;
-cpu_register_physical_memory(addr, CIRRUS_PNPMMIO_SIZE,
-s->cirrus_mmio_io_addr);
+pci_register_memory(d->bus, addr, CIRRUS_PNPMMIO_SIZE,
+s->cirrus_mmio_io_addr);
}
static void pci_cirrus_write_config(PCIDevice *d,
diff --git a/hw/e1000.c b/hw/e1000.c
index 96d045d..89b503a 100644
--- a/hw/e1000.c
+++ b/hw/e1000.c
@@ -1032,7 +1032,7 @@ e1000_mmio_map(PCIDevice *pci_dev, int region_num,
DBGOUT(MMIO, "e1000_mmio_map addr=0x%08"FMT_PCIBUS" 0x%08"FMT_PCIBUS"\n",
addr, size);
-cpu_register_physical_memory(addr, PNPMMIO_SIZE, d->mmio_index);
+pci_register_memory(pci_dev->bus, addr, PNPMMIO_SIZE, d->mmio_index);
qemu_register_coalesced_mmio(addr, excluded_regs[0]);
for (i = 0; excluded_regs[i] != PNPMMIO_SIZE; i++)
diff --git a/hw/eepro100.c b/hw/eepro100.c
index a74d834..9e64251 100644
--- a/hw/eepro100.c
+++ b/hw/eepro100.c
@@ -1623,7 +1623,7 @@ static void pci_mmio_map(PCIDevice * pci_dev,
int region_num,
assert(region_num == 0 || region_num == 2);
/* Map control / status registers and flash. */
-cpu_register_physical_memory(addr, size, s->mmio_index);
+pci_register_memory(pci_dev->bus, addr, size, s->mmio_index);
s->region[region_num] = addr;
}
diff --git a/hw/isa.h b/hw/isa.h
index aaf0272..e40a1d4 100644
--- a/hw/isa.h
+++ b/hw/isa.h
@@ -33,6 +33,7 @@ ISADevice *isa_create_simple(const char *name);
extern target_phys_addr_t isa_mem_base;
void isa_mmio_init(target_phys_addr_t base, target_phys_addr_t size, int be);
+int pci_isa_mmio_init(target_phys_addr_t base, target_phys_addr_t
size, int be);
/* dma.c */
int DMA_get_channel_mode (int nchan);
diff --git a/hw/isa_mmio.c b/hw/isa_mmio.c
index 66bdd2c..01dfab9 100644
--- a/hw/isa_mmio.c
+++ b/hw/isa_mmio.c
@@ -125,7 +125,8 @@ static CPUReadMemoryFunc * const isa_mmio_read_le[] = {
static int isa_mmio_iomemtype = 0;
-void isa_mmio_init(target_phys_addr_t base, target_phys_addr_t size, int be)
+static int isa_mmio_memtype(target_phys_addr_t base, target_phys_addr_t size,
+int be)
{
if (!isa_mmio_iomemtype) {
if (be) {
@@ -138,5 +139,18 @@ void isa_mmio_init(target_phys_addr_t base,
target_phys_addr_t size, int be)
NULL);
}
}
-cpu_register_physical_memory(base, size, isa_mmio_iomemtype);
+return isa_mmio_iomemtype;
+}
+
+void isa_mmio_init(target_phys_addr_t base, target_phys_addr_t size, int be)
+{
+int isa;
+
+isa = isa_mmio_memtype(base, size, be);
+cpu_register_physical_memory(base, size, isa);
+}
+
+int pci_isa_mmio_init(target_phys_addr_t base, target_phys_addr_t size, int be)
+{
+return isa_mmio_memtype(base, size, be);
}
diff --git a/hw/lsi53c895a.c b/hw/lsi53c895a.c
index f5a91ba..3386148 100644
--- a/hw/lsi53c895a.c
+++ b/hw/lsi53c895a.c
@@ -2015,7 +2015,7 @@ static void lsi_ram_mapfunc(PCIDevice *pci_dev,
int region_num,
DPRINTF("Mapping ram at %08"FMT_PCIBUS"\n", addr);
s->script_ram_base = addr;
-cpu_register_physical_memory(addr + 0, 0x2000, s->ram_io_addr);
+pci_register_memory(pci_dev->bus, addr + 0, 0x2000, s->ram_io_addr);
}
static void lsi_mmio_mapfunc(PCIDevice *pci_dev, int region_num,
@@ -2024,7 +2024
[Qemu-devel] [PATCH, RFC 3/4] Implement byte swapped MMIO type
BROKEN
Signed-off-by: Blue Swirl
---
cpu-common.h |3 +-
softmmu_template.h | 69 ++--
2 files changed, 63 insertions(+), 9 deletions(-)
diff --git a/cpu-common.h b/cpu-common.h
index b24cecc..f96cea0 100644
--- a/cpu-common.h
+++ b/cpu-common.h
@@ -123,8 +123,9 @@ void cpu_physical_memory_write_rom(target_phys_addr_t addr,
#define IO_MEM_NOTDIRTY(3 << IO_MEM_SHIFT)
/* Acts like a ROM when read and like a device when written. */
-#define IO_MEM_ROMD(1)
+#define IO_MEM_ROMD(4)
#define IO_MEM_SUBPAGE (2)
+#define IO_MEM_BSWAP (1)
#endif
diff --git a/softmmu_template.h b/softmmu_template.h
index c2df9ec..feb5d85 100644
--- a/softmmu_template.h
+++ b/softmmu_template.h
@@ -24,18 +24,22 @@
#define SUFFIX q
#define USUFFIX q
#define DATA_TYPE uint64_t
+#define SWAP(x) bswap64(x)
#elif DATA_SIZE == 4
#define SUFFIX l
#define USUFFIX l
#define DATA_TYPE uint32_t
+#define SWAP(x) bswap32(x)
#elif DATA_SIZE == 2
#define SUFFIX w
#define USUFFIX uw
#define DATA_TYPE uint16_t
+#define SWAP(x) bswap16(x)
#elif DATA_SIZE == 1
#define SUFFIX b
#define USUFFIX ub
#define DATA_TYPE uint8_t
+#define SWAP(x) (x)
#else
#error unsupported data size
#endif
@@ -68,14 +72,35 @@ static inline DATA_TYPE glue(io_read,
SUFFIX)(target_phys_addr_t physaddr,
env->mem_io_vaddr = addr;
#if SHIFT <= 2
res = io_mem_read[index][SHIFT](io_mem_opaque[index], physaddr);
+if (index & IO_MEM_BSWAP) {
+res = SWAP(res);
+}
#else
+{
+DATA_TYPE tmp;
#ifdef TARGET_WORDS_BIGENDIAN
-res = (uint64_t)io_mem_read[index][2](io_mem_opaque[index],
physaddr) << 32;
-res |= io_mem_read[index][2](io_mem_opaque[index], physaddr + 4);
+res = (uint64_t)io_mem_read[index][2](io_mem_opaque[index],
+ physaddr) << 32;
+if (index & IO_MEM_BSWAP) {
+res = bswap32(res);
+}
+tmp = io_mem_read[index][2](io_mem_opaque[index], physaddr + 4);
+if (index & IO_MEM_BSWAP) {
+tmp = bswap32(tmp);
+}
+res |= tmp;
#else
-res = io_mem_read[index][2](io_mem_opaque[index], physaddr);
-res |= (uint64_t)io_mem_read[index][2](io_mem_opaque[index],
physaddr + 4) << 32;
+res = io_mem_read[index][2](io_mem_opaque[index], physaddr);
+if (index & IO_MEM_BSWAP) {
+res = bswap32(res);
+}
+tmp = (uint64_t)io_mem_read[index][2](io_mem_opaque[index],
physaddr + 4) << 32;
+if (index & IO_MEM_BSWAP) {
+tmp = bswap32(tmp);
+}
+res |= tmp;
#endif
+}
#endif /* SHIFT > 2 */
return res;
}
@@ -174,6 +199,9 @@ static DATA_TYPE glue(glue(slow_ld, SUFFIX),
MMUSUFFIX)(target_ulong addr,
res = (res1 >> shift) | (res2 << ((DATA_SIZE * 8) - shift));
#endif
res = (DATA_TYPE)res;
+if (tlb_addr & IO_MEM_BSWAP) {
+res = SWAP(res);
+}
} else {
/* unaligned/aligned access in the same page */
addend = env->tlb_table[mmu_idx][index].addend;
@@ -209,16 +237,37 @@ static inline void glue(io_write,
SUFFIX)(target_phys_addr_t physaddr,
env->mem_io_vaddr = addr;
env->mem_io_pc = (unsigned long)retaddr;
+if (index & IO_MEM_BSWAP) {
+val = SWAP(val);
+}
#if SHIFT <= 2
io_mem_write[index][SHIFT](io_mem_opaque[index], physaddr, val);
+if (index & IO_MEM_BSWAP) {
+val = SWAP(val);
+}
#else
+{
+DATA_TYPE tmp;
#ifdef TARGET_WORDS_BIGENDIAN
-io_mem_write[index][2](io_mem_opaque[index], physaddr, val >> 32);
-io_mem_write[index][2](io_mem_opaque[index], physaddr + 4, val);
+if (index & IO_MEM_BSWAP) {
+tmp = bswap32(val >> 32);
+}
+io_mem_write[index][2](io_mem_opaque[index], physaddr, tmp);
+if (index & IO_MEM_BSWAP) {
+tmp = bswap32(val);
+}
+io_mem_write[index][2](io_mem_opaque[index], physaddr + 4, tmp);
#else
-io_mem_write[index][2](io_mem_opaque[index], physaddr, val);
-io_mem_write[index][2](io_mem_opaque[index], physaddr + 4, val >> 32);
+if (index & IO_MEM_BSWAP) {
+tmp = bswap32(val);
+}
+io_mem_write[index][2](io_mem_opaque[index], physaddr, tmp);
+if (index & IO_MEM_BSWAP) {
+tmp = bswap32(val >> 32);
+}
+io_mem_write[index][2](io_mem_opaque[index], physaddr + 4, tmp);
#endif
+}
#endif /* SHIFT > 2 */
}
@@ -297,6 +346,9 @@ static void glue(glue(slow_st, SUFFIX),
MMUSUFFIX)(target_ulong addr,
glue(io_write, SUFFIX)(ioaddr, val, addr, retaddr);
} else if (((addr & ~TARGET_PAGE_MASK) + DATA_SIZE - 1) >=
TARGET_PAGE_SIZE) {
do_unaligned_access:
+if (tlb_addr & IO_MEM_BSWAP) {
+val = SWAP(val);
+}
/* XXX: not efficient, but simple
[Qemu-devel] [PATCH, RFC 1/4] pci: add I/O registration functions
Convert also APB to use the registration so that
we can remove mem_base.
Signed-off-by: Blue Swirl
---
hw/apb_pci.c | 23 -
hw/pci.c | 64 ++---
hw/pci.h |9 +++-
3 files changed, 68 insertions(+), 28 deletions(-)
diff --git a/hw/apb_pci.c b/hw/apb_pci.c
index 65d8ba6..fb23397 100644
--- a/hw/apb_pci.c
+++ b/hw/apb_pci.c
@@ -74,6 +74,7 @@ typedef struct APBState {
qemu_irq pci_irqs[32];
uint32_t reset_control;
unsigned int nr_resets;
+target_phys_addr_t mem_base;
} APBState;
static void apb_config_writel (void *opaque, target_phys_addr_t addr,
@@ -316,6 +317,24 @@ static void apb_pci_bridge_init(PCIBus *b)
PCI_HEADER_TYPE_MULTI_FUNCTION);
}
+static void apb_register_mem(void *opaque, pcibus_t addr, pcibus_t
size, int mm)
+{
+APBState *d = opaque;
+
+APB_DPRINTF("%s: addr %" FMT_PCIBUS " size %" FMT_PCIBUS "mm %x\n",
+__func__, addr, size, mm);
+cpu_register_physical_memory(addr + d->mem_base, size, mm);
+}
+
+static void apb_unregister_mem(void *opaque, pcibus_t addr, pcibus_t size)
+{
+APBState *d = opaque;
+
+APB_DPRINTF("%s: addr %" FMT_PCIBUS " size %" FMT_PCIBUS "\n",
+__func__, addr, size);
+cpu_register_physical_memory(addr + d->mem_base, size, IO_MEM_UNASSIGNED);
+}
+
PCIBus *pci_apb_init(target_phys_addr_t special_base,
target_phys_addr_t mem_base,
qemu_irq *pic, PCIBus **bus2, PCIBus **bus3)
@@ -338,10 +357,12 @@ PCIBus *pci_apb_init(target_phys_addr_t special_base,
/* mem_data */
sysbus_mmio_map(s, 3, mem_base);
d = FROM_SYSBUS(APBState, s);
+d->mem_base = mem_base;
d->host_state.bus = pci_register_bus(&d->busdev.qdev, "pci",
pci_apb_set_irq, pci_pbm_map_irq, d,
0, 32);
-pci_bus_set_mem_base(d->host_state.bus, mem_base);
+pci_bus_set_register_mem_fn(d->host_state.bus, apb_register_mem,
+apb_unregister_mem, d);
for (i = 0; i < 32; i++) {
sysbus_connect_irq(s, i, pic[i]);
diff --git a/hw/pci.c b/hw/pci.c
index 8d84651..ffd6dc3 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -46,7 +46,9 @@ struct PCIBus {
void *irq_opaque;
PCIDevice *devices[256];
PCIDevice *parent_dev;
-target_phys_addr_t mem_base;
+pci_register_mem_fn register_mem;
+pci_unregister_mem_fn unregister_mem;
+void *register_fn_opaque;
QLIST_HEAD(, PCIBus) child; /* this will be replaced by qdev later */
QLIST_ENTRY(PCIBus) sibling;/* this will be replaced by qdev later */
@@ -163,6 +165,18 @@ static void pci_device_reset(PCIDevice *dev)
pci_update_mappings(dev);
}
+static void pci_bus_default_register_mem(void *opaque, pcibus_t addr,
+ pcibus_t size, int mm)
+{
+cpu_register_physical_memory(addr, size, mm);
+}
+
+static void pci_bus_default_unregister_mem(void *opaque, pcibus_t addr,
+ pcibus_t size)
+{
+cpu_register_physical_memory(addr, size, IO_MEM_UNASSIGNED);
+}
+
static void pci_bus_reset(void *opaque)
{
PCIBus *bus = opaque;
@@ -205,6 +219,8 @@ void pci_bus_new_inplace(PCIBus *bus, DeviceState *parent,
{
qbus_create_inplace(&bus->qbus, &pci_bus_info, parent, name);
bus->devfn_min = devfn_min;
+bus->register_mem = pci_bus_default_register_mem;
+bus->unregister_mem = pci_bus_default_unregister_mem;
/* host bridge */
QLIST_INIT(&bus->child);
@@ -241,11 +257,6 @@ void pci_bus_hotplug(PCIBus *bus, pci_hotplug_fn
hotplug, DeviceState *qdev)
bus->hotplug_qdev = qdev;
}
-void pci_bus_set_mem_base(PCIBus *bus, target_phys_addr_t base)
-{
-bus->mem_base = base;
-}
-
PCIBus *pci_register_bus(DeviceState *parent, const char *name,
pci_set_irq_fn set_irq, pci_map_irq_fn map_irq,
void *irq_opaque, int devfn_min, int nirq)
@@ -651,12 +662,6 @@ PCIDevice *pci_register_device(PCIBus *bus, const
char *name,
return pci_dev;
}
-static target_phys_addr_t pci_to_cpu_addr(PCIBus *bus,
- target_phys_addr_t addr)
-{
-return addr + bus->mem_base;
-}
-
static void pci_unregister_io_regions(PCIDevice *pci_dev)
{
PCIIORegion *r;
@@ -669,10 +674,9 @@ static void pci_unregister_io_regions(PCIDevice *pci_dev)
if (r->type == PCI_BASE_ADDRESS_SPACE_IO) {
isa_unassign_ioport(r->addr, r->filtered_size);
} else {
-cpu_register_physical_memory(pci_to_cpu_addr(pci_dev->bus,
- r->addr),
- r->filtered_size,
- IO_MEM_UNASSIGNED);
+pci_dev->bus->unregister_mem(pci_dev->bus->register_fn_opaque,
+
[Qemu-devel] [PATCH, RFC 0/4] Byte swapping I/O memory, preview
Hi, The overall plan is to add a new flag, IO_MEM_BSWAP, which triggers byte swapping inside CPU load/store functions. Convert all PCI devices to register their memory areas via the PCI host. Then the big endian PCI hosts enable IO_MEM_BSWAP for all registered regions, simultaneously all PCI devices stop swapping bytes. Some more PCI devices can probably be compiled once, though since this is not Generic DMA, there won't be too many. The patches are not acceptable yet, APB part should be moved from 1/4 to 2/4 even though it means a bit of extra work, this breaks bisection. Instead of PCIBus, the registration functions should take a PCIDevice parameter. 3/4 breaks several architectures. 4/4 should remove byte swapping from devices. VGA is a problem because the byte swaps are in common functions. Sparc64 almost works, other architectures show blank screen. Anyway, I thought I'll send the patches for comments. Especially, is the idea of using IO_MEM_BSWAP viable? Blue Swirl (4): pci: add I/O registration functions Convert PCI devices to use pci_register_memory() Implement byte swapped MMIO type apb: use IO_MEM_BSWAP with device registration cpu-common.h |3 +- hw/apb_pci.c | 23 - hw/cirrus_vga.c| 12 hw/e1000.c |2 +- hw/eepro100.c |2 +- hw/isa.h |1 + hw/isa_mmio.c | 18 - hw/lsi53c895a.c|4 +- hw/macio.c | 24 +- hw/msix.c |4 +- hw/openpic.c |6 ++-- hw/pci.c | 64 --- hw/pci.h |9 ++- hw/pcnet.c |3 +- hw/rtl8139.c |2 +- hw/sun4u.c |7 - hw/usb-ohci.c |2 +- hw/vga-pci.c |4 +- hw/vmware_vga.c|7 ++--- hw/wdt_i6300esb.c |2 +- softmmu_template.h | 69 ++-- 21 files changed, 190 insertions(+), 78 deletions(-)
Re: [Qemu-devel] [PATCH RFC] virtio: put last seen used index into ring itself
On Sun, May 23, 2010 at 07:03:10PM +0300, Avi Kivity wrote: > On 05/23/2010 06:51 PM, Michael S. Tsirkin wrote: >>> So locked version seems to be faster than unlocked, and share/unshare not to matter? >>> May be due to the processor using the LOCK operation as a hint to >>> reserve the cacheline for a bit. >>> >> Maybe we should use atomics on index then? >> > > This should only be helpful if you access the cacheline several times in > a row. That's not the case in virtio (or here). > > I think the problem is that LOCKSHARE and SHARE are not symmetric, so > they can't be directly compared. > >> OK, after adding mb in code patch will be sent separately, >> the test works for my workstation. locked is still fastest, >> unshared sometimes shows wins and sometimes loses over shared. >> >> [r...@qus19 ~]# ./cachebounce share 0 1 >> CPU 0: share cacheline: 6638521 usec >> CPU 1: share cacheline: 6638478 usec >> > > 66 ns? nice. > >> [r...@qus19 ~]# ./cachebounce share 0 2 >> CPU 0: share cacheline: 14529198 usec >> CPU 2: share cacheline: 14529156 usec >> > > 140 ns, not too bad. I hope I'm not misinterpreting the results. > > -- > error compiling committee.c: too many arguments to function Here's another box: here the fastest option is shared, slowest unshared, lock is in the middle. [r...@virtlab16 testring]# sh run 0 2 CPU 2: share cacheline: 3304728 usec CPU 0: share cacheline: 3304784 usec CPU 0: unshare cacheline: 6283248 usec CPU 2: unshare cacheline: 6283224 usec CPU 2: lockshare cacheline: 4018567 usec CPU 0: lockshare cacheline: 4018609 usec CPU 2: lockunshare cacheline: 4041791 usec CPU 0: lockunshare cacheline: 4041832 usec [r...@virtlab16 testring]# [r...@virtlab16 testring]# [r...@virtlab16 testring]# [r...@virtlab16 testring]# sh run 0 1 CPU 1: share cacheline: 8306326 usec CPU 0: share cacheline: 8306324 usec CPU 0: unshare cacheline: 19571697 usec CPU 1: unshare cacheline: 19571578 usec CPU 0: lockshare cacheline: 11281566 usec CPU 1: lockshare cacheline: 11281424 usec CPU 0: lockunshare cacheline: 11276093 usec CPU 1: lockunshare cacheline: 11275957 usec [r...@virtlab16 testring]# sh run 0 3 CPU 0: share cacheline: 8288335 usec CPU 3: share cacheline: 8288334 usec CPU 0: unshare cacheline: 19107202 usec CPU 3: unshare cacheline: 19107139 usec CPU 0: lockshare cacheline: 11238915 usec CPU 3: lockshare cacheline: 11238848 usec CPU 3: lockunshare cacheline: 11132134 usec CPU 0: lockunshare cacheline: 11132249 usec
Re: [Qemu-devel] [PATCH RFC] virtio: put last seen used index into ring itself
On Sun, May 23, 2010 at 07:03:10PM +0300, Avi Kivity wrote: > On 05/23/2010 06:51 PM, Michael S. Tsirkin wrote: >>> So locked version seems to be faster than unlocked, and share/unshare not to matter? >>> May be due to the processor using the LOCK operation as a hint to >>> reserve the cacheline for a bit. >>> >> Maybe we should use atomics on index then? >> > > This should only be helpful if you access the cacheline several times in > a row. That's not the case in virtio (or here). So why does it help? > I think the problem is that LOCKSHARE and SHARE are not symmetric, so > they can't be directly compared. In what sense are they not symmetric? >> OK, after adding mb in code patch will be sent separately, >> the test works for my workstation. locked is still fastest, >> unshared sometimes shows wins and sometimes loses over shared. >> >> [r...@qus19 ~]# ./cachebounce share 0 1 >> CPU 0: share cacheline: 6638521 usec >> CPU 1: share cacheline: 6638478 usec >> > > 66 ns? nice. > >> [r...@qus19 ~]# ./cachebounce share 0 2 >> CPU 0: share cacheline: 14529198 usec >> CPU 2: share cacheline: 14529156 usec >> > > 140 ns, not too bad. I hope I'm not misinterpreting the results. > > -- > error compiling committee.c: too many arguments to function
[Qemu-devel] Re: [PATCH, RFC 2/4] hpet: don't use any static state
On Sun, May 23, 2010 at 3:40 PM, Jan Kiszka wrote:
> Blue Swirl wrote:
>> Signed-off-by: Blue Swirl
>> ---
>> hw/hpet.c | 68
>> +--
>> hw/hpet_emul.h | 4 +-
>> hw/pc.c | 8 --
>> hw/pc.h | 3 +-
>> hw/pc_piix.c | 3 +-
>> 5 files changed, 47 insertions(+), 39 deletions(-)
>>
>> diff --git a/hw/hpet.c b/hw/hpet.c
>> index 8729fb2..f24e054 100644
>> --- a/hw/hpet.c
>> +++ b/hw/hpet.c
>> @@ -37,14 +37,11 @@
>> #define DPRINTF(...)
>> #endif
>>
>> -static HPETState *hpet_statep;
>> -
>> -uint32_t hpet_in_legacy_mode(void)
>> +uint32_t hpet_in_legacy_mode(void *opaque)
>
> uint32_t hpet_in_legacy_mode(HPETState *s)
>
> please (will become DeviceState with my patches, but it should not be
> void in any case).
I tried that, but HPTState is not available for all cases where pc.h
is #included. DeviceState or ISADeviceState would be much better, the
callers have no need to access HPETState fields.
>> {
>> - if (hpet_statep)
>> - return hpet_statep->config & HPET_CFG_LEGACY;
>> - else
>> - return 0;
>> + HPETState *s = opaque;
>> +
>> + return s->config & HPET_CFG_LEGACY;
>> }
>>
>> static uint32_t timer_int_route(struct HPETTimer *timer)
>> @@ -54,9 +51,9 @@ static uint32_t timer_int_route(struct HPETTimer *timer)
>> return route;
>> }
>>
>> -static uint32_t hpet_enabled(void)
>> +static uint32_t hpet_enabled(HPETState *s)
>> {
>> - return hpet_statep->config & HPET_CFG_ENABLE;
>> + return s->config & HPET_CFG_ENABLE;
>> }
>>
>> static uint32_t timer_is_periodic(HPETTimer *t)
>> @@ -106,10 +103,10 @@ static int deactivating_bit(uint64_t old,
>> uint64_t new, uint64_t mask)
>> return ((old & mask) && !(new & mask));
>> }
>>
>> -static uint64_t hpet_get_ticks(void)
>> +static uint64_t hpet_get_ticks(HPETState *s)
>> {
>> uint64_t ticks;
>> - ticks = ns_to_ticks(qemu_get_clock(vm_clock) +
>> hpet_statep->hpet_offset);
>> + ticks = ns_to_ticks(qemu_get_clock(vm_clock) + s->hpet_offset);
>> return ticks;
>> }
>>
>> @@ -139,7 +136,7 @@ static void update_irq(struct HPETTimer *timer)
>> qemu_irq irq;
>> int route;
>>
>> - if (timer->tn <= 1 && hpet_in_legacy_mode()) {
>> + if (timer->tn <= 1 && hpet_in_legacy_mode(timer->state)) {
>> /* if LegacyReplacementRoute bit is set, HPET specification requires
>> * timer0 be routed to IRQ0 in NON-APIC or IRQ2 in the I/O APIC,
>> * timer1 be routed to IRQ8 in NON-APIC or IRQ8 in the I/O APIC.
>> @@ -152,7 +149,7 @@ static void update_irq(struct HPETTimer *timer)
>> route=timer_int_route(timer);
>> irq=timer->state->irqs[route];
>> }
>> - if (timer_enabled(timer) && hpet_enabled()) {
>> + if (timer_enabled(timer) && hpet_enabled(timer->state)) {
>> qemu_irq_pulse(irq);
>> }
>> }
>> @@ -161,7 +158,7 @@ static void hpet_pre_save(void *opaque)
>> {
>> HPETState *s = opaque;
>> /* save current counter value */
>> - s->hpet_counter = hpet_get_ticks();
>> + s->hpet_counter = hpet_get_ticks(s);
>> }
>>
>> static int hpet_post_load(void *opaque, int version_id)
>> @@ -216,7 +213,7 @@ static void hpet_timer(void *opaque)
>> uint64_t diff;
>>
>> uint64_t period = t->period;
>> - uint64_t cur_tick = hpet_get_ticks();
>> + uint64_t cur_tick = hpet_get_ticks(t->state);
>>
>> if (timer_is_periodic(t) && period != 0) {
>> if (t->config & HPET_TN_32BIT) {
>> @@ -244,7 +241,7 @@ static void hpet_set_timer(HPETTimer *t)
>> {
>> uint64_t diff;
>> uint32_t wrap_diff; /* how many ticks until we wrap? */
>> - uint64_t cur_tick = hpet_get_ticks();
>> + uint64_t cur_tick = hpet_get_ticks(t->state);
>>
>> /* whenever new timer is being set up, make sure wrap_flag is 0 */
>> t->wrap_flag = 0;
>> @@ -326,17 +323,19 @@ static uint32_t hpet_ram_readl(void *opaque,
>> target_phys_addr_t addr)
>> DPRINTF("qemu: invalid HPET_CFG + 4 hpet_ram_readl \n");
>> return 0;
>> case HPET_COUNTER:
>> - if (hpet_enabled())
>> - cur_tick = hpet_get_ticks();
>> - else
>> + if (hpet_enabled(s)) {
>> + cur_tick = hpet_get_ticks(s);
>> + } else {
>> cur_tick = s->hpet_counter;
>> + }
>> DPRINTF("qemu: reading counter = %" PRIx64 "\n", cur_tick);
>> return cur_tick;
>> case HPET_COUNTER + 4:
>> - if (hpet_enabled())
>> - cur_tick = hpet_get_ticks();
>> - else
>> + if (hpet_enabled(s)) {
>> + cur_tick = hpet_get_ticks(s);
>> + } else {
>> cur_tick = s->hpet_counter;
>> + }
>> DPRINTF("qemu: reading counter + 4 = %" PRIx64 "\n",
>
Re: [Qemu-devel] [PATCH RFC] virtio: put last seen used index into ring itself
On 05/23/2010 06:51 PM, Michael S. Tsirkin wrote: So locked version seems to be faster than unlocked, and share/unshare not to matter? May be due to the processor using the LOCK operation as a hint to reserve the cacheline for a bit. Maybe we should use atomics on index then? This should only be helpful if you access the cacheline several times in a row. That's not the case in virtio (or here). I think the problem is that LOCKSHARE and SHARE are not symmetric, so they can't be directly compared. OK, after adding mb in code patch will be sent separately, the test works for my workstation. locked is still fastest, unshared sometimes shows wins and sometimes loses over shared. [r...@qus19 ~]# ./cachebounce share 0 1 CPU 0: share cacheline: 6638521 usec CPU 1: share cacheline: 6638478 usec 66 ns? nice. [r...@qus19 ~]# ./cachebounce share 0 2 CPU 0: share cacheline: 14529198 usec CPU 2: share cacheline: 14529156 usec 140 ns, not too bad. I hope I'm not misinterpreting the results. -- error compiling committee.c: too many arguments to function
[Qemu-devel] Re: [PATCH, RFC 1/4] mc146818: move hpet handling to pc.c
On Sun, May 23, 2010 at 3:40 PM, Jan Kiszka wrote:
> Blue Swirl wrote:
>> Move hpet_in_legacy_mode check from mc146818.c to pc.c. Remove
>> the optimization where the periodic timer is disabled if
>> hpet is in legacy mode.
>>
>> Signed-off-by: Blue Swirl
>> ---
>> hw/mc146818rtc.c | 37 +++--
>> hw/mc146818rtc.h | 2 ++
>> hw/pc.c | 32 +++-
>> 3 files changed, 36 insertions(+), 35 deletions(-)
>>
>> diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
>> index 571c593..e0c33c5 100644
>> --- a/hw/mc146818rtc.c
>> +++ b/hw/mc146818rtc.c
>> @@ -27,7 +27,6 @@
>> #include "pc.h"
>> #include "apic.h"
>> #include "isa.h"
>> -#include "hpet_emul.h"
>> #include "mc146818rtc.h"
>>
>> //#define DEBUG_CMOS
>> @@ -94,19 +93,6 @@ typedef struct RTCState {
>> QEMUTimer *second_timer2;
>> } RTCState;
>>
>> -static void rtc_irq_raise(qemu_irq irq)
>> -{
>> - /* When HPET is operating in legacy mode, RTC interrupts are disabled
>> - * We block qemu_irq_raise, but not qemu_irq_lower, in case legacy
>> - * mode is established while interrupt is raised. We want it to
>> - * be lowered in any case
>> - */
>> -#if defined TARGET_I386
>> - if (!hpet_in_legacy_mode())
>> -#endif
>> - qemu_irq_raise(irq);
>> -}
>> -
>> static void rtc_set_time(RTCState *s);
>> static void rtc_copy_date(RTCState *s);
>>
>> @@ -131,7 +117,7 @@ static void rtc_coalesced_timer(void *opaque)
>> if (s->irq_coalesced != 0) {
>> apic_reset_irq_delivered();
>> s->cmos_data[RTC_REG_C] |= 0xc0;
>> - rtc_irq_raise(s->irq);
>> + qemu_irq_raise(s->irq);
>> if (apic_get_irq_delivered()) {
>> s->irq_coalesced--;
>> }
>> @@ -145,19 +131,10 @@ static void rtc_timer_update(RTCState *s,
>> int64_t current_time)
>> {
>> int period_code, period;
>> int64_t cur_clock, next_irq_clock;
>> - int enable_pie;
>>
>> period_code = s->cmos_data[RTC_REG_A] & 0x0f;
>> -#if defined TARGET_I386
>> - /* disable periodic timer if hpet is in legacy mode, since interrupts
>> are
>> - * disabled anyway.
>> - */
>
> Does some dumb OS we care about (specifically in KVM mode) first enable
> the periodic RTC, then discovers the HPET, switches over, forgetting
> about the RTC? Otherwise: the guest will get what it deserves (degraded
> performance).
No idea. The performance penalty also depends on the trigger frequency.
>> - enable_pie = !hpet_in_legacy_mode();
>> -#else
>> - enable_pie = 1;
>> -#endif
>> if (period_code != 0
>> - && (((s->cmos_data[RTC_REG_B] & REG_B_PIE) && enable_pie)
>> + && ((s->cmos_data[RTC_REG_B] & REG_B_PIE)
>> || ((s->cmos_data[RTC_REG_B] & REG_B_SQWE) && s->sqw_irq))) {
>> if (period_code <= 2)
>> period_code += 7;
>> @@ -194,14 +171,14 @@ static void rtc_periodic_timer(void *opaque)
>> if (s->irq_reinject_on_ack_count >= RTC_REINJECT_ON_ACK_COUNT)
>> s->irq_reinject_on_ack_count = 0;
>> apic_reset_irq_delivered();
>> - rtc_irq_raise(s->irq);
>> + qemu_irq_raise(s->irq);
>> if (!apic_get_irq_delivered()) {
>> s->irq_coalesced++;
>> rtc_coalesced_timer_update(s);
>> }
>> } else
>> #endif
>> - rtc_irq_raise(s->irq);
>> + qemu_irq_raise(s->irq);
>> }
>> if (s->cmos_data[RTC_REG_B] & REG_B_SQWE) {
>> /* Not square wave at all but we don't want 2048Hz interrupts!
>> @@ -430,7 +407,7 @@ static void rtc_update_second2(void *opaque)
>> s->cmos_data[RTC_HOURS_ALARM] == s->current_tm.tm_hour)) {
>>
>> s->cmos_data[RTC_REG_C] |= 0xa0;
>> - rtc_irq_raise(s->irq);
>> + qemu_irq_raise(s->irq);
>> }
>> }
>>
>> @@ -438,7 +415,7 @@ static void rtc_update_second2(void *opaque)
>> s->cmos_data[RTC_REG_C] |= REG_C_UF;
>> if (s->cmos_data[RTC_REG_B] & REG_B_UIE) {
>> s->cmos_data[RTC_REG_C] |= REG_C_IRQF;
>> - rtc_irq_raise(s->irq);
>> + qemu_irq_raise(s->irq);
>> }
>>
>> /* clear update in progress bit */
>> @@ -588,7 +565,7 @@ static int rtc_initfn(ISADevice *dev)
>> {
>> RTCState *s = DO_UPCAST(RTCState, dev, dev);
>> int base = 0x70;
>> - int isairq = 8;
>> + int isairq = RTC_ISA_IRQ;
>>
>> isa_init_irq(dev, &s->irq, isairq);
>>
>> diff --git a/hw/mc146818rtc.h b/hw/mc146818rtc.h
>> index 6f46a68..d630485 100644
>> --- a/hw/mc146818rtc.h
>> +++ b/hw/mc146818rtc.h
>> @@ -7,4 +7,6 @@ ISADevice *rtc_init(int base_year);
>> void rtc_set_memory(ISADevice *dev, int addr, int val);
>> void rtc_set_date(ISADevice *dev, const struct tm *tm);
>>
>> +#define RTC_ISA_IRQ 8
>> +
>> #endif /* !MC146818RTC_H */
>> diff --git a/hw/pc.c b/hw/pc.c
>> index e7f31d3..5a703e1 100644
>> --- a/hw/pc.c
>> +++ b/hw/pc.c
>> @@ -66,16 +66,38 @@ st
Re: [Qemu-devel] [PATCH RFC] virtio: put last seen used index into ring itself
On Thu, May 20, 2010 at 02:38:16PM +0930, Rusty Russell wrote:
> On Thu, 20 May 2010 02:31:50 pm Rusty Russell wrote:
> > On Wed, 19 May 2010 05:36:42 pm Avi Kivity wrote:
> > > > Note that this is a exclusive->shared->exclusive bounce only, too.
> > > >
> > >
> > > A bounce is a bounce.
> >
> > I tried to measure this to show that you were wrong, but I was only able
> > to show that you're right. How annoying. Test code below.
>
> This time for sure!
The share option does not work on some
boxes unless I apply the following:
essentially, this adds mb() after each write
and before read. It seems to make sense to
me: we must update our counter before we
wanit for another side.
diff --git a/cachebounce.c b/cachebounce.c
index 0387027..ebe5a37 100644
--- a/cachebounce.c
+++ b/cachebounce.c
@@ -77,6 +77,7 @@ int main(int argc, char *argv[])
count++;
counter->cacheline1 = count;
count++;
+ __sync_synchronize();
}
break;
case UNSHARE:
@@ -86,6 +87,7 @@ int main(int argc, char *argv[])
count++;
counter->cacheline2 = count;
count++;
+ __sync_synchronize();
}
break;
case LOCKSHARE:
@@ -98,6 +100,7 @@ int main(int argc, char *argv[])
break;
case LOCKUNSHARE:
while (count < MAX_BOUNCES) {
+ __sync_synchronize();
/* Spin waiting for other side to change it. */
while (counter->cacheline1 != count);
__sync_val_compare_and_swap(&counter->cacheline2, count, count+1);
@@ -115,6 +118,7 @@ int main(int argc, char *argv[])
count++;
counter->cacheline1 = count;
count++;
+ __sync_synchronize();
}
break;
case UNSHARE:
@@ -124,6 +128,7 @@ int main(int argc, char *argv[])
count++;
counter->cacheline1 = count;
count++;
+ __sync_synchronize();
}
break;
case LOCKSHARE:
Re: [Qemu-devel] [PATCH RFC] virtio: put last seen used index into ring itself
On Sun, May 23, 2010 at 06:41:33PM +0300, Avi Kivity wrote: > On 05/23/2010 06:31 PM, Michael S. Tsirkin wrote: >> On Thu, May 20, 2010 at 02:38:16PM +0930, Rusty Russell wrote: >> >>> On Thu, 20 May 2010 02:31:50 pm Rusty Russell wrote: >>> On Wed, 19 May 2010 05:36:42 pm Avi Kivity wrote: >> Note that this is a exclusive->shared->exclusive bounce only, too. >> >> > A bounce is a bounce. > I tried to measure this to show that you were wrong, but I was only able to show that you're right. How annoying. Test code below. >>> This time for sure! >>> >> >> What do you see? >> On my laptop: >> [...@tuck testring]$ ./rusty1 share 0 1 >> CPU 1: share cacheline: 2820410 usec >> CPU 0: share cacheline: 2823441 usec >> [...@tuck testring]$ ./rusty1 unshare 0 1 >> CPU 0: unshare cacheline: 2783014 usec >> CPU 1: unshare cacheline: 2782951 usec >> [...@tuck testring]$ ./rusty1 lockshare 0 1 >> CPU 1: lockshare cacheline: 1888495 usec >> CPU 0: lockshare cacheline: 1888544 usec >> [...@tuck testring]$ ./rusty1 lockunshare 0 1 >> CPU 0: lockunshare cacheline: 1889854 usec >> CPU 1: lockunshare cacheline: 1889804 usec >> > > Ugh, can the timing be normalized per operation? This is unreadable. > >> So locked version seems to be faster than unlocked, >> and share/unshare not to matter? >> > > May be due to the processor using the LOCK operation as a hint to > reserve the cacheline for a bit. Maybe we should use atomics on index then? >> same on a workstation: >> [r...@qus19 ~]# ./rusty1 unshare 0 1 >> CPU 0: unshare cacheline: 6037002 usec >> CPU 1: unshare cacheline: 6036977 usec >> [r...@qus19 ~]# ./rusty1 lockunshare 0 1 >> CPU 1: lockunshare cacheline: 5734362 usec >> CPU 0: lockunshare cacheline: 5734389 usec >> [r...@qus19 ~]# ./rusty1 lockshare 0 1 >> CPU 1: lockshare cacheline: 5733537 usec >> CPU 0: lockshare cacheline: 5733564 usec >> >> using another pair of CPUs gives a more drastic >> results: >> >> [r...@qus19 ~]# ./rusty1 lockshare 0 2 >> CPU 2: lockshare cacheline: 4226990 usec >> CPU 0: lockshare cacheline: 4227038 usec >> [r...@qus19 ~]# ./rusty1 lockunshare 0 2 >> CPU 0: lockunshare cacheline: 4226707 usec >> CPU 2: lockunshare cacheline: 4226662 usec >> [r...@qus19 ~]# ./rusty1 unshare 0 2 >> CPU 0: unshare cacheline: 14815048 usec >> CPU 2: unshare cacheline: 14815006 usec >> >> > > That's expected. Hyperthread will be fastest (shared L1), shared L2/L3 > will be slower, cross-socket will suck. OK, after adding mb in code patch will be sent separately, the test works for my workstation. locked is still fastest, unshared sometimes shows wins and sometimes loses over shared. [r...@qus19 ~]# ./cachebounce share 0 1 CPU 0: share cacheline: 6638521 usec CPU 1: share cacheline: 6638478 usec [r...@qus19 ~]# ./cachebounce unshare 0 1 CPU 0: unshare cacheline: 6037415 usec CPU 1: unshare cacheline: 6037374 usec [r...@qus19 ~]# ./cachebounce lockshare 0 1 CPU 0: lockshare cacheline: 5734017 usec CPU 1: lockshare cacheline: 5733978 usec [r...@qus19 ~]# ./cachebounce lockunshare 0 1 CPU 1: lockunshare cacheline: 5733260 usec CPU 0: lockunshare cacheline: 5733307 usec [r...@qus19 ~]# ./cachebounce share 0 2 CPU 0: share cacheline: 14529198 usec CPU 2: share cacheline: 14529156 usec [r...@qus19 ~]# ./cachebounce unshare 0 2 CPU 2: unshare cacheline: 14815328 usec CPU 0: unshare cacheline: 14815374 usec [r...@qus19 ~]# ./cachebounce lockshare 0 2 CPU 0: lockshare cacheline: 4226878 usec CPU 2: lockshare cacheline: 4226842 usec [r...@qus19 ~]# ./cachebounce locknushare 0 2 cachebounce: Usage: cachebounce share|unshare|lockshare|lockunshare [r...@qus19 ~]# ./cachebounce lockunshare 0 2 CPU 0: lockunshare cacheline: 4227432 usec CPU 2: lockunshare cacheline: 4227375 usec
[Qemu-devel] Re: [PATCH 3/5] trace: Add LTTng Userspace Tracer backend
Stefan Hajnoczi wrote:
> This patch adds LTTng Userspace Tracer (UST) backend support. The UST
> system requires no kernel support but libust and liburcu must be
> installed.
>
> $ ./configure --trace-backend ust
> $ make
>
> Start the UST daemon:
> $ ustd &
>
> List available tracepoints and enable some:
> $ ustctl --list-markers $(pgrep qemu)
> [...]
> {PID: 5458, channel/marker: ust/paio_submit, state: 0, fmt: "acb %p
> opaque %p sector_num %lu nb_sectors %lu type %lu" 0x4b32ba}
> $ ustctl --enable-marker "ust/paio_submit" $(pgrep qemu)
>
> Run the trace:
> $ ustctl --create-trace $(pgrep qemu)
> $ ustctl --start-trace $(pgrep qemu)
> [...]
> $ ustctl --stop-trace $(pgrep qemu)
> $ ustctl --destroy-trace $(pgrep qemu)
>
> Trace results can be viewed using lttv-gui.
>
> More information about UST:
> http://lttng.org/ust
>
> Signed-off-by: Stefan Hajnoczi
> ---
> I wrote this as part of trying out UST. Although UST is promising, the
> usability is poor at the moment.
I was hoping it would be better, but I'm not really surprised.
>
> The dependencies include the lttv trace viewer which I had to build from
> source
> (and it required a makefile tweak to build). Luckily libust, liburcu, and
> ust-bin are packaged on my distro.
>
> Error messages are periodically printed by the UST code when running QEMU. I
> haven't investigated but this is may be due to signals interrupting UST's
> thread in poll().
>
> Finally, the UST header files include some userspace ported kernel
> infrastructure and pollute the namespace. I had to add some #undefs to get
> QEMU to build after including UST headers.
>
> I don't see LTTng UST as a default option at the moment. Hopefully this will
> change in the future.
Unless you already did, please report this to LTTng. I bet they will be
interested in your feedback and maybe also in the fact that they gained
another use/test case.
Jan
signature.asc
Description: OpenPGP digital signature
[Qemu-devel] Re: [RFC 0/5] Tracing backends
Stefan Hajnoczi wrote:
> The following patches against qemu.git allow static trace events to be
> declared
> in QEMU. Trace events use a lightweight syntax and are independent of the
> backend tracing system (e.g. LTTng UST).
>
> Supported backends are:
> * my trivial tracer ("simple")
> * LTTng Userspace Tracer ("ust")
> * no tracer ("nop", the default)
>
> The ./configure option to choose a backend is --trace-backend=.
>
> Main point of this patchset: adding new trace events is easy and we can switch
> between backends without modifying the code.
>
> Prerna: Would you like to add your tracing system as a backend? This would be
> similar to my patches to add "simple" and "ust" backend support.
>
> Jan: Adding kernel marker backend support should be straightforward if you are
> interested.
>
> These patches are also available at:
> http://repo.or.cz/w/qemu/stefanha.git/shortlog/refs/heads/tracing
>
Nice! Will have a closer look once timer permits, specifically to check
how ftrace can be added to this. Looks indeed straightforward on first
sight.
Jan
signature.asc
Description: OpenPGP digital signature
[Qemu-devel] Re: [PATCH, RFC 2/4] hpet: don't use any static state
Blue Swirl wrote:
> Signed-off-by: Blue Swirl
> ---
> hw/hpet.c | 68 +--
> hw/hpet_emul.h |4 +-
> hw/pc.c|8 --
> hw/pc.h|3 +-
> hw/pc_piix.c |3 +-
> 5 files changed, 47 insertions(+), 39 deletions(-)
>
> diff --git a/hw/hpet.c b/hw/hpet.c
> index 8729fb2..f24e054 100644
> --- a/hw/hpet.c
> +++ b/hw/hpet.c
> @@ -37,14 +37,11 @@
> #define DPRINTF(...)
> #endif
>
> -static HPETState *hpet_statep;
> -
> -uint32_t hpet_in_legacy_mode(void)
> +uint32_t hpet_in_legacy_mode(void *opaque)
uint32_t hpet_in_legacy_mode(HPETState *s)
please (will become DeviceState with my patches, but it should not be
void in any case).
> {
> -if (hpet_statep)
> -return hpet_statep->config & HPET_CFG_LEGACY;
> -else
> -return 0;
> +HPETState *s = opaque;
> +
> +return s->config & HPET_CFG_LEGACY;
> }
>
> static uint32_t timer_int_route(struct HPETTimer *timer)
> @@ -54,9 +51,9 @@ static uint32_t timer_int_route(struct HPETTimer *timer)
> return route;
> }
>
> -static uint32_t hpet_enabled(void)
> +static uint32_t hpet_enabled(HPETState *s)
> {
> -return hpet_statep->config & HPET_CFG_ENABLE;
> +return s->config & HPET_CFG_ENABLE;
> }
>
> static uint32_t timer_is_periodic(HPETTimer *t)
> @@ -106,10 +103,10 @@ static int deactivating_bit(uint64_t old,
> uint64_t new, uint64_t mask)
> return ((old & mask) && !(new & mask));
> }
>
> -static uint64_t hpet_get_ticks(void)
> +static uint64_t hpet_get_ticks(HPETState *s)
> {
> uint64_t ticks;
> -ticks = ns_to_ticks(qemu_get_clock(vm_clock) + hpet_statep->hpet_offset);
> +ticks = ns_to_ticks(qemu_get_clock(vm_clock) + s->hpet_offset);
> return ticks;
> }
>
> @@ -139,7 +136,7 @@ static void update_irq(struct HPETTimer *timer)
> qemu_irq irq;
> int route;
>
> -if (timer->tn <= 1 && hpet_in_legacy_mode()) {
> +if (timer->tn <= 1 && hpet_in_legacy_mode(timer->state)) {
> /* if LegacyReplacementRoute bit is set, HPET specification requires
> * timer0 be routed to IRQ0 in NON-APIC or IRQ2 in the I/O APIC,
> * timer1 be routed to IRQ8 in NON-APIC or IRQ8 in the I/O APIC.
> @@ -152,7 +149,7 @@ static void update_irq(struct HPETTimer *timer)
> route=timer_int_route(timer);
> irq=timer->state->irqs[route];
> }
> -if (timer_enabled(timer) && hpet_enabled()) {
> +if (timer_enabled(timer) && hpet_enabled(timer->state)) {
> qemu_irq_pulse(irq);
> }
> }
> @@ -161,7 +158,7 @@ static void hpet_pre_save(void *opaque)
> {
> HPETState *s = opaque;
> /* save current counter value */
> -s->hpet_counter = hpet_get_ticks();
> +s->hpet_counter = hpet_get_ticks(s);
> }
>
> static int hpet_post_load(void *opaque, int version_id)
> @@ -216,7 +213,7 @@ static void hpet_timer(void *opaque)
> uint64_t diff;
>
> uint64_t period = t->period;
> -uint64_t cur_tick = hpet_get_ticks();
> +uint64_t cur_tick = hpet_get_ticks(t->state);
>
> if (timer_is_periodic(t) && period != 0) {
> if (t->config & HPET_TN_32BIT) {
> @@ -244,7 +241,7 @@ static void hpet_set_timer(HPETTimer *t)
> {
> uint64_t diff;
> uint32_t wrap_diff; /* how many ticks until we wrap? */
> -uint64_t cur_tick = hpet_get_ticks();
> +uint64_t cur_tick = hpet_get_ticks(t->state);
>
> /* whenever new timer is being set up, make sure wrap_flag is 0 */
> t->wrap_flag = 0;
> @@ -326,17 +323,19 @@ static uint32_t hpet_ram_readl(void *opaque,
> target_phys_addr_t addr)
> DPRINTF("qemu: invalid HPET_CFG + 4 hpet_ram_readl \n");
> return 0;
> case HPET_COUNTER:
> -if (hpet_enabled())
> -cur_tick = hpet_get_ticks();
> -else
> +if (hpet_enabled(s)) {
> +cur_tick = hpet_get_ticks(s);
> +} else {
> cur_tick = s->hpet_counter;
> +}
> DPRINTF("qemu: reading counter = %" PRIx64 "\n", cur_tick);
> return cur_tick;
> case HPET_COUNTER + 4:
> -if (hpet_enabled())
> -cur_tick = hpet_get_ticks();
> -else
> +if (hpet_enabled(s)) {
> +cur_tick = hpet_get_ticks(s);
> +} else {
> cur_tick = s->hpet_counter;
> +}
> DPRINTF("qemu: reading counter + 4 = %" PRIx64 "\n",
> cur_tick);
> return cur_tick >> 32;
> case HPET_STATUS:
> @@ -419,8 +418,9 @@ static void hpet_ram_writel(void *opaque,
> target_phys_addr_t addr,
> | new_val;
> }
> timer->config &= ~HPET_TN_SETVAL;
> -if (hpet_enabled())
> +if (hpet_enabl
Re: [Qemu-devel] [PATCH RFC] virtio: put last seen used index into ring itself
On 05/23/2010 06:31 PM, Michael S. Tsirkin wrote: On Thu, May 20, 2010 at 02:38:16PM +0930, Rusty Russell wrote: On Thu, 20 May 2010 02:31:50 pm Rusty Russell wrote: On Wed, 19 May 2010 05:36:42 pm Avi Kivity wrote: Note that this is a exclusive->shared->exclusive bounce only, too. A bounce is a bounce. I tried to measure this to show that you were wrong, but I was only able to show that you're right. How annoying. Test code below. This time for sure! What do you see? On my laptop: [...@tuck testring]$ ./rusty1 share 0 1 CPU 1: share cacheline: 2820410 usec CPU 0: share cacheline: 2823441 usec [...@tuck testring]$ ./rusty1 unshare 0 1 CPU 0: unshare cacheline: 2783014 usec CPU 1: unshare cacheline: 2782951 usec [...@tuck testring]$ ./rusty1 lockshare 0 1 CPU 1: lockshare cacheline: 1888495 usec CPU 0: lockshare cacheline: 1888544 usec [...@tuck testring]$ ./rusty1 lockunshare 0 1 CPU 0: lockunshare cacheline: 1889854 usec CPU 1: lockunshare cacheline: 1889804 usec Ugh, can the timing be normalized per operation? This is unreadable. So locked version seems to be faster than unlocked, and share/unshare not to matter? May be due to the processor using the LOCK operation as a hint to reserve the cacheline for a bit. same on a workstation: [r...@qus19 ~]# ./rusty1 unshare 0 1 CPU 0: unshare cacheline: 6037002 usec CPU 1: unshare cacheline: 6036977 usec [r...@qus19 ~]# ./rusty1 lockunshare 0 1 CPU 1: lockunshare cacheline: 5734362 usec CPU 0: lockunshare cacheline: 5734389 usec [r...@qus19 ~]# ./rusty1 lockshare 0 1 CPU 1: lockshare cacheline: 5733537 usec CPU 0: lockshare cacheline: 5733564 usec using another pair of CPUs gives a more drastic results: [r...@qus19 ~]# ./rusty1 lockshare 0 2 CPU 2: lockshare cacheline: 4226990 usec CPU 0: lockshare cacheline: 4227038 usec [r...@qus19 ~]# ./rusty1 lockunshare 0 2 CPU 0: lockunshare cacheline: 4226707 usec CPU 2: lockunshare cacheline: 4226662 usec [r...@qus19 ~]# ./rusty1 unshare 0 2 CPU 0: unshare cacheline: 14815048 usec CPU 2: unshare cacheline: 14815006 usec That's expected. Hyperthread will be fastest (shared L1), shared L2/L3 will be slower, cross-socket will suck. -- error compiling committee.c: too many arguments to function
[Qemu-devel] Re: [PATCH, RFC 1/4] mc146818: move hpet handling to pc.c
Blue Swirl wrote:
> Move hpet_in_legacy_mode check from mc146818.c to pc.c. Remove
> the optimization where the periodic timer is disabled if
> hpet is in legacy mode.
>
> Signed-off-by: Blue Swirl
> ---
> hw/mc146818rtc.c | 37 +++--
> hw/mc146818rtc.h |2 ++
> hw/pc.c | 32 +++-
> 3 files changed, 36 insertions(+), 35 deletions(-)
>
> diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
> index 571c593..e0c33c5 100644
> --- a/hw/mc146818rtc.c
> +++ b/hw/mc146818rtc.c
> @@ -27,7 +27,6 @@
> #include "pc.h"
> #include "apic.h"
> #include "isa.h"
> -#include "hpet_emul.h"
> #include "mc146818rtc.h"
>
> //#define DEBUG_CMOS
> @@ -94,19 +93,6 @@ typedef struct RTCState {
> QEMUTimer *second_timer2;
> } RTCState;
>
> -static void rtc_irq_raise(qemu_irq irq)
> -{
> -/* When HPET is operating in legacy mode, RTC interrupts are disabled
> - * We block qemu_irq_raise, but not qemu_irq_lower, in case legacy
> - * mode is established while interrupt is raised. We want it to
> - * be lowered in any case
> - */
> -#if defined TARGET_I386
> -if (!hpet_in_legacy_mode())
> -#endif
> -qemu_irq_raise(irq);
> -}
> -
> static void rtc_set_time(RTCState *s);
> static void rtc_copy_date(RTCState *s);
>
> @@ -131,7 +117,7 @@ static void rtc_coalesced_timer(void *opaque)
> if (s->irq_coalesced != 0) {
> apic_reset_irq_delivered();
> s->cmos_data[RTC_REG_C] |= 0xc0;
> -rtc_irq_raise(s->irq);
> +qemu_irq_raise(s->irq);
> if (apic_get_irq_delivered()) {
> s->irq_coalesced--;
> }
> @@ -145,19 +131,10 @@ static void rtc_timer_update(RTCState *s,
> int64_t current_time)
> {
> int period_code, period;
> int64_t cur_clock, next_irq_clock;
> -int enable_pie;
>
> period_code = s->cmos_data[RTC_REG_A] & 0x0f;
> -#if defined TARGET_I386
> -/* disable periodic timer if hpet is in legacy mode, since interrupts are
> - * disabled anyway.
> - */
Does some dumb OS we care about (specifically in KVM mode) first enable
the periodic RTC, then discovers the HPET, switches over, forgetting
about the RTC? Otherwise: the guest will get what it deserves (degraded
performance).
> -enable_pie = !hpet_in_legacy_mode();
> -#else
> -enable_pie = 1;
> -#endif
> if (period_code != 0
> -&& (((s->cmos_data[RTC_REG_B] & REG_B_PIE) && enable_pie)
> +&& ((s->cmos_data[RTC_REG_B] & REG_B_PIE)
> || ((s->cmos_data[RTC_REG_B] & REG_B_SQWE) && s->sqw_irq))) {
> if (period_code <= 2)
> period_code += 7;
> @@ -194,14 +171,14 @@ static void rtc_periodic_timer(void *opaque)
> if (s->irq_reinject_on_ack_count >= RTC_REINJECT_ON_ACK_COUNT)
> s->irq_reinject_on_ack_count = 0;
> apic_reset_irq_delivered();
> -rtc_irq_raise(s->irq);
> +qemu_irq_raise(s->irq);
> if (!apic_get_irq_delivered()) {
> s->irq_coalesced++;
> rtc_coalesced_timer_update(s);
> }
> } else
> #endif
> -rtc_irq_raise(s->irq);
> +qemu_irq_raise(s->irq);
> }
> if (s->cmos_data[RTC_REG_B] & REG_B_SQWE) {
> /* Not square wave at all but we don't want 2048Hz interrupts!
> @@ -430,7 +407,7 @@ static void rtc_update_second2(void *opaque)
> s->cmos_data[RTC_HOURS_ALARM] == s->current_tm.tm_hour)) {
>
> s->cmos_data[RTC_REG_C] |= 0xa0;
> -rtc_irq_raise(s->irq);
> +qemu_irq_raise(s->irq);
> }
> }
>
> @@ -438,7 +415,7 @@ static void rtc_update_second2(void *opaque)
> s->cmos_data[RTC_REG_C] |= REG_C_UF;
> if (s->cmos_data[RTC_REG_B] & REG_B_UIE) {
>s->cmos_data[RTC_REG_C] |= REG_C_IRQF;
> - rtc_irq_raise(s->irq);
> + qemu_irq_raise(s->irq);
> }
>
> /* clear update in progress bit */
> @@ -588,7 +565,7 @@ static int rtc_initfn(ISADevice *dev)
> {
> RTCState *s = DO_UPCAST(RTCState, dev, dev);
> int base = 0x70;
> -int isairq = 8;
> +int isairq = RTC_ISA_IRQ;
>
> isa_init_irq(dev, &s->irq, isairq);
>
> diff --git a/hw/mc146818rtc.h b/hw/mc146818rtc.h
> index 6f46a68..d630485 100644
> --- a/hw/mc146818rtc.h
> +++ b/hw/mc146818rtc.h
> @@ -7,4 +7,6 @@ ISADevice *rtc_init(int base_year);
> void rtc_set_memory(ISADevice *dev, int addr, int val);
> void rtc_set_date(ISADevice *dev, const struct tm *tm);
>
> +#define RTC_ISA_IRQ 8
> +
> #endif /* !MC146818RTC_H */
> diff --git a/hw/pc.c b/hw/pc.c
> index e7f31d3..5a703e1 100644
> --- a/hw/pc.c
> +++ b/hw/pc.c
> @@ -66,16 +66,38 @@ struct e820_table {
>
> static struct e820_table e820_table;
>
> -void isa_irq_handler(void *opaque, int n, int level)
> +static void isa_set_irq(IsaIrqState *isa, int n, int level)
> {
> -IsaIrqState *isa = (IsaIrqState *)opaque;
> -
> if
Re: [Qemu-devel] [PATCH RFC] virtio: put last seen used index into ring itself
On Thu, May 20, 2010 at 02:38:16PM +0930, Rusty Russell wrote: > On Thu, 20 May 2010 02:31:50 pm Rusty Russell wrote: > > On Wed, 19 May 2010 05:36:42 pm Avi Kivity wrote: > > > > Note that this is a exclusive->shared->exclusive bounce only, too. > > > > > > > > > > A bounce is a bounce. > > > > I tried to measure this to show that you were wrong, but I was only able > > to show that you're right. How annoying. Test code below. > > This time for sure! What do you see? On my laptop: [...@tuck testring]$ ./rusty1 share 0 1 CPU 1: share cacheline: 2820410 usec CPU 0: share cacheline: 2823441 usec [...@tuck testring]$ ./rusty1 unshare 0 1 CPU 0: unshare cacheline: 2783014 usec CPU 1: unshare cacheline: 2782951 usec [...@tuck testring]$ ./rusty1 lockshare 0 1 CPU 1: lockshare cacheline: 1888495 usec CPU 0: lockshare cacheline: 1888544 usec [...@tuck testring]$ ./rusty1 lockunshare 0 1 CPU 0: lockunshare cacheline: 1889854 usec CPU 1: lockunshare cacheline: 1889804 usec So locked version seems to be faster than unlocked, and share/unshare not to matter? same on a workstation: [r...@qus19 ~]# ./rusty1 unshare 0 1 CPU 0: unshare cacheline: 6037002 usec CPU 1: unshare cacheline: 6036977 usec [r...@qus19 ~]# ./rusty1 lockunshare 0 1 CPU 1: lockunshare cacheline: 5734362 usec CPU 0: lockunshare cacheline: 5734389 usec [r...@qus19 ~]# ./rusty1 lockshare 0 1 CPU 1: lockshare cacheline: 5733537 usec CPU 0: lockshare cacheline: 5733564 usec using another pair of CPUs gives a more drastic results: [r...@qus19 ~]# ./rusty1 lockshare 0 2 CPU 2: lockshare cacheline: 4226990 usec CPU 0: lockshare cacheline: 4227038 usec [r...@qus19 ~]# ./rusty1 lockunshare 0 2 CPU 0: lockunshare cacheline: 4226707 usec CPU 2: lockunshare cacheline: 4226662 usec [r...@qus19 ~]# ./rusty1 unshare 0 2 CPU 0: unshare cacheline: 14815048 usec CPU 2: unshare cacheline: 14815006 usec The share test seems to never finish on the workstation. I am debugging this. -- MST
Re: [Qemu-devel] Inquiry about qemu for Motorola 68360
qemu-system-m68k -cpu ? El 23/05/2010, a las 08:47, hadi motamedi escribió: > > > > >>While QEMU does indeed works for x86 Windows, current QEMU's m68k > >>architecture does not included that specific Motorola chip. > Thank you for your reply. Can you please let me know which Motorola chips are > being currently supported? > >
[Qemu-devel] [PATCH, RFC 4/4] Compile mc146818 only once
8 compilations less for the full build. Signed-off-by: Blue Swirl --- Makefile.objs|1 + Makefile.target |7 +++ default-configs/i386-softmmu.mak |1 + default-configs/mips-softmmu.mak |1 + default-configs/mips64-softmmu.mak |1 + default-configs/mips64el-softmmu.mak |1 + default-configs/mipsel-softmmu.mak |1 + default-configs/ppc-softmmu.mak |1 + default-configs/ppc64-softmmu.mak|1 + default-configs/ppcemb-softmmu.mak |1 + default-configs/sparc64-softmmu.mak |1 + default-configs/x86_64-softmmu.mak |1 + hw/mc146818rtc.c | 33 - 13 files changed, 26 insertions(+), 25 deletions(-) diff --git a/Makefile.objs b/Makefile.objs index b1a6e01..7a234de 100644 --- a/Makefile.objs +++ b/Makefile.objs @@ -142,6 +142,7 @@ hw-obj-$(CONFIG_ECC) += ecc.o hw-obj-$(CONFIG_NAND) += nand.o hw-obj-$(CONFIG_PFLASH_CFI01) += pflash_cfi01.o hw-obj-$(CONFIG_PFLASH_CFI02) += pflash_cfi02.o +hw-obj-$(CONFIG_MC146818) += mc146818rtc.o hw-obj-$(CONFIG_M48T59) += m48t59.o hw-obj-$(CONFIG_ESCC) += escc.o diff --git a/Makefile.target b/Makefile.target index 00e140f..d4d2c7f 100644 --- a/Makefile.target +++ b/Makefile.target @@ -189,7 +189,7 @@ obj-y += e1000.o # Hardware support obj-i386-y += vga.o -obj-i386-y += mc146818rtc.o i8259.o pc.o +obj-i386-y += i8259.o pc.o obj-i386-y += cirrus_vga.o apic.o ioapic.o piix_pci.o obj-i386-y += vmmouse.o vmport.o hpet.o obj-i386-y += device-hotplug.o pci-hotplug.o smbios.o wdt_ib700.o @@ -200,7 +200,7 @@ obj-i386-y += pc_piix.o obj-ppc-y = ppc.o obj-ppc-y += vga.o # PREP target -obj-ppc-y += i8259.o mc146818rtc.o +obj-ppc-y += i8259.o obj-ppc-y += ppc_prep.o # OldWorld PowerMac obj-ppc-y += ppc_oldworld.o @@ -218,7 +218,7 @@ obj-mips-y = mips_r4k.o mips_jazz.o mips_malta.o mips_mipssim.o obj-mips-y += mips_addr.o mips_timer.o mips_int.o obj-mips-y += vga.o i8259.o obj-mips-y += g364fb.o jazz_led.o -obj-mips-y += gt64xxx.o mc146818rtc.o +obj-mips-y += gt64xxx.o obj-mips-y += piix4.o cirrus_vga.o obj-microblaze-y = petalogix_s3adsp1800_mmu.o @@ -244,7 +244,6 @@ obj-cris-y += etraxfs_ser.o ifeq ($(TARGET_ARCH), sparc64) obj-sparc-y = sun4u.o apb_pci.o obj-sparc-y += vga.o -obj-sparc-y += mc146818rtc.o obj-sparc-y += cirrus_vga.o else obj-sparc-y = sun4m.o lance.o tcx.o sun4m_iommu.o slavio_intctl.o diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak index ed00471..ac222e6 100644 --- a/default-configs/i386-softmmu.mak +++ b/default-configs/i386-softmmu.mak @@ -7,6 +7,7 @@ CONFIG_VMWARE_VGA=y CONFIG_SERIAL=y CONFIG_PARALLEL=y CONFIG_I8254=y +CONFIG_MC146818=y CONFIG_PCSPK=y CONFIG_PCKBD=y CONFIG_USB_UHCI=y diff --git a/default-configs/mips-softmmu.mak b/default-configs/mips-softmmu.mak index 29be52e..c8c7fd1 100644 --- a/default-configs/mips-softmmu.mak +++ b/default-configs/mips-softmmu.mak @@ -9,6 +9,7 @@ CONFIG_VMWARE_VGA=y CONFIG_SERIAL=y CONFIG_PARALLEL=y CONFIG_I8254=y +CONFIG_MC146818=y CONFIG_PCSPK=y CONFIG_PCKBD=y CONFIG_USB_UHCI=y diff --git a/default-configs/mips64-softmmu.mak b/default-configs/mips64-softmmu.mak index 9bae8a7..6582ca0 100644 --- a/default-configs/mips64-softmmu.mak +++ b/default-configs/mips64-softmmu.mak @@ -9,6 +9,7 @@ CONFIG_VMWARE_VGA=y CONFIG_SERIAL=y CONFIG_PARALLEL=y CONFIG_I8254=y +CONFIG_MC146818=y CONFIG_PCSPK=y CONFIG_PCKBD=y CONFIG_USB_UHCI=y diff --git a/default-configs/mips64el-softmmu.mak b/default-configs/mips64el-softmmu.mak index b372c1d..01901ee 100644 --- a/default-configs/mips64el-softmmu.mak +++ b/default-configs/mips64el-softmmu.mak @@ -9,6 +9,7 @@ CONFIG_VMWARE_VGA=y CONFIG_SERIAL=y CONFIG_PARALLEL=y CONFIG_I8254=y +CONFIG_MC146818=y CONFIG_PCSPK=y CONFIG_PCKBD=y CONFIG_USB_UHCI=y diff --git a/default-configs/mipsel-softmmu.mak b/default-configs/mipsel-softmmu.mak index 10ef483..e47ba6a 100644 --- a/default-configs/mipsel-softmmu.mak +++ b/default-configs/mipsel-softmmu.mak @@ -9,6 +9,7 @@ CONFIG_VMWARE_VGA=y CONFIG_SERIAL=y CONFIG_PARALLEL=y CONFIG_I8254=y +CONFIG_MC146818=y CONFIG_PCSPK=y CONFIG_PCKBD=y CONFIG_USB_UHCI=y diff --git a/default-configs/ppc-softmmu.mak b/default-configs/ppc-softmmu.mak index c026bbb..651a489 100644 --- a/default-configs/ppc-softmmu.mak +++ b/default-configs/ppc-softmmu.mak @@ -8,6 +8,7 @@ CONFIG_M48T59=y CONFIG_VGA_PCI=y CONFIG_SERIAL=y CONFIG_I8254=y +CONFIG_MC146818=y CONFIG_PCKBD=y CONFIG_FDC=y CONFIG_DMA=y diff --git a/default-configs/ppc64-softmmu.mak b/default-configs/ppc64-softmmu.mak index 0101a28..e9bb814 100644 --- a/default-configs/ppc64-softmmu.mak +++ b/default-configs/ppc64-softmmu.mak @@ -8,6 +8,7 @@ CONFIG_M48T59=y CONFIG_VGA_PCI=y CONFIG_SERIAL=y CONFIG_I8254=y +CONFIG_MC146818=y CONFIG_PCKBD=y CONFIG_FDC=y CONFIG_DMA=y diff --git a/default-configs/ppcemb-softmmu.mak b/default-configs/ppcemb-softmmu.mak index 8ba9ac1..
[Qemu-devel] [PATCH, RFC 3/4] mc146818: push apic dependencies to pc.c
A side effect is that coalesced irq handling is extended to seconds
alarm and irq reinjection.
Signed-off-by: Blue Swirl
---
hw/mc146818rtc.c | 20 ++--
hw/mc146818rtc.h |1 +
hw/pc.c |6 ++
hw/pc.h |1 +
4 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
index e0c33c5..93d72cc 100644
--- a/hw/mc146818rtc.c
+++ b/hw/mc146818rtc.c
@@ -25,7 +25,6 @@
#include "qemu-timer.h"
#include "sysemu.h"
#include "pc.h"
-#include "apic.h"
#include "isa.h"
#include "mc146818rtc.h"
@@ -115,16 +114,19 @@ static void rtc_coalesced_timer(void *opaque)
RTCState *s = opaque;
if (s->irq_coalesced != 0) {
-apic_reset_irq_delivered();
s->cmos_data[RTC_REG_C] |= 0xc0;
qemu_irq_raise(s->irq);
-if (apic_get_irq_delivered()) {
-s->irq_coalesced--;
-}
}
rtc_coalesced_timer_update(s);
}
+
+void rtc_dec_coalesced(ISADevice *dev)
+{
+RTCState *s = DO_UPCAST(RTCState, dev, dev);
+
+s->irq_coalesced--;
+}
#endif
static void rtc_timer_update(RTCState *s, int64_t current_time)
@@ -168,11 +170,12 @@ static void rtc_periodic_timer(void *opaque)
s->cmos_data[RTC_REG_C] |= 0xc0;
#ifdef TARGET_I386
if(rtc_td_hack) {
+uint32_t old_coalesced = s->irq_coalesced;
+
if (s->irq_reinject_on_ack_count >= RTC_REINJECT_ON_ACK_COUNT)
s->irq_reinject_on_ack_count = 0;
-apic_reset_irq_delivered();
qemu_irq_raise(s->irq);
-if (!apic_get_irq_delivered()) {
+if (s->irq_coalesced == old_coalesced) {
s->irq_coalesced++;
rtc_coalesced_timer_update(s);
}
@@ -452,10 +455,7 @@ static uint32_t cmos_ioport_read(void *opaque,
uint32_t addr)
if(s->irq_coalesced &&
s->irq_reinject_on_ack_count < RTC_REINJECT_ON_ACK_COUNT) {
s->irq_reinject_on_ack_count++;
-apic_reset_irq_delivered();
qemu_irq_raise(s->irq);
-if (apic_get_irq_delivered())
-s->irq_coalesced--;
break;
}
#endif
diff --git a/hw/mc146818rtc.h b/hw/mc146818rtc.h
index d630485..c496ecd 100644
--- a/hw/mc146818rtc.h
+++ b/hw/mc146818rtc.h
@@ -6,6 +6,7 @@
ISADevice *rtc_init(int base_year);
void rtc_set_memory(ISADevice *dev, int addr, int val);
void rtc_set_date(ISADevice *dev, const struct tm *tm);
+void rtc_dec_coalesced(ISADevice *dev);
#define RTC_ISA_IRQ 8
diff --git a/hw/pc.c b/hw/pc.c
index 9f1a9d6..c6f28e1 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -78,6 +78,8 @@ static void isa_set_irq(IsaIrqState *isa, int n, int level)
static void rtc_irq_handler(IsaIrqState *isa, int level)
{
+apic_reset_irq_delivered();
+
/* When HPET is operating in legacy mode, RTC interrupts are disabled.
* We block qemu_irq_raise, but not qemu_irq_lower, in case legacy
* mode is established while interrupt is raised. We want it to
@@ -85,6 +87,9 @@ static void rtc_irq_handler(IsaIrqState *isa, int level)
*/
if ((isa->hpet_state && !hpet_in_legacy_mode(isa->hpet_state)) || !level) {
isa_set_irq(isa, RTC_ISA_IRQ, level);
+if (apic_get_irq_delivered()) {
+rtc_dec_coalesced(isa->rtc_state);
+}
}
}
@@ -961,6 +966,7 @@ void pc_basic_device_init(qemu_irq *isa_irq,
IsaIrqState *isa,
register_ioport_write(0xf0, 1, 1, ioportF0_write, NULL);
*rtc_state = rtc_init(2000);
+isa->rtc_state = *rtc_state;
qemu_register_boot_set(pc_boot_set, *rtc_state);
diff --git a/hw/pc.h b/hw/pc.h
index 3e085b9..e19dfe9 100644
--- a/hw/pc.h
+++ b/hw/pc.h
@@ -42,6 +42,7 @@ void irq_info(Monitor *mon);
typedef struct isa_irq_state {
qemu_irq *i8259;
qemu_irq *ioapic;
+ISADevice *rtc_state;
void *hpet_state;
} IsaIrqState;
--
1.6.2.4
[Qemu-devel] [PATCH, RFC 2/4] hpet: don't use any static state
Signed-off-by: Blue Swirl
---
hw/hpet.c | 68 +--
hw/hpet_emul.h |4 +-
hw/pc.c|8 --
hw/pc.h|3 +-
hw/pc_piix.c |3 +-
5 files changed, 47 insertions(+), 39 deletions(-)
diff --git a/hw/hpet.c b/hw/hpet.c
index 8729fb2..f24e054 100644
--- a/hw/hpet.c
+++ b/hw/hpet.c
@@ -37,14 +37,11 @@
#define DPRINTF(...)
#endif
-static HPETState *hpet_statep;
-
-uint32_t hpet_in_legacy_mode(void)
+uint32_t hpet_in_legacy_mode(void *opaque)
{
-if (hpet_statep)
-return hpet_statep->config & HPET_CFG_LEGACY;
-else
-return 0;
+HPETState *s = opaque;
+
+return s->config & HPET_CFG_LEGACY;
}
static uint32_t timer_int_route(struct HPETTimer *timer)
@@ -54,9 +51,9 @@ static uint32_t timer_int_route(struct HPETTimer *timer)
return route;
}
-static uint32_t hpet_enabled(void)
+static uint32_t hpet_enabled(HPETState *s)
{
-return hpet_statep->config & HPET_CFG_ENABLE;
+return s->config & HPET_CFG_ENABLE;
}
static uint32_t timer_is_periodic(HPETTimer *t)
@@ -106,10 +103,10 @@ static int deactivating_bit(uint64_t old,
uint64_t new, uint64_t mask)
return ((old & mask) && !(new & mask));
}
-static uint64_t hpet_get_ticks(void)
+static uint64_t hpet_get_ticks(HPETState *s)
{
uint64_t ticks;
-ticks = ns_to_ticks(qemu_get_clock(vm_clock) + hpet_statep->hpet_offset);
+ticks = ns_to_ticks(qemu_get_clock(vm_clock) + s->hpet_offset);
return ticks;
}
@@ -139,7 +136,7 @@ static void update_irq(struct HPETTimer *timer)
qemu_irq irq;
int route;
-if (timer->tn <= 1 && hpet_in_legacy_mode()) {
+if (timer->tn <= 1 && hpet_in_legacy_mode(timer->state)) {
/* if LegacyReplacementRoute bit is set, HPET specification requires
* timer0 be routed to IRQ0 in NON-APIC or IRQ2 in the I/O APIC,
* timer1 be routed to IRQ8 in NON-APIC or IRQ8 in the I/O APIC.
@@ -152,7 +149,7 @@ static void update_irq(struct HPETTimer *timer)
route=timer_int_route(timer);
irq=timer->state->irqs[route];
}
-if (timer_enabled(timer) && hpet_enabled()) {
+if (timer_enabled(timer) && hpet_enabled(timer->state)) {
qemu_irq_pulse(irq);
}
}
@@ -161,7 +158,7 @@ static void hpet_pre_save(void *opaque)
{
HPETState *s = opaque;
/* save current counter value */
-s->hpet_counter = hpet_get_ticks();
+s->hpet_counter = hpet_get_ticks(s);
}
static int hpet_post_load(void *opaque, int version_id)
@@ -216,7 +213,7 @@ static void hpet_timer(void *opaque)
uint64_t diff;
uint64_t period = t->period;
-uint64_t cur_tick = hpet_get_ticks();
+uint64_t cur_tick = hpet_get_ticks(t->state);
if (timer_is_periodic(t) && period != 0) {
if (t->config & HPET_TN_32BIT) {
@@ -244,7 +241,7 @@ static void hpet_set_timer(HPETTimer *t)
{
uint64_t diff;
uint32_t wrap_diff; /* how many ticks until we wrap? */
-uint64_t cur_tick = hpet_get_ticks();
+uint64_t cur_tick = hpet_get_ticks(t->state);
/* whenever new timer is being set up, make sure wrap_flag is 0 */
t->wrap_flag = 0;
@@ -326,17 +323,19 @@ static uint32_t hpet_ram_readl(void *opaque,
target_phys_addr_t addr)
DPRINTF("qemu: invalid HPET_CFG + 4 hpet_ram_readl \n");
return 0;
case HPET_COUNTER:
-if (hpet_enabled())
-cur_tick = hpet_get_ticks();
-else
+if (hpet_enabled(s)) {
+cur_tick = hpet_get_ticks(s);
+} else {
cur_tick = s->hpet_counter;
+}
DPRINTF("qemu: reading counter = %" PRIx64 "\n", cur_tick);
return cur_tick;
case HPET_COUNTER + 4:
-if (hpet_enabled())
-cur_tick = hpet_get_ticks();
-else
+if (hpet_enabled(s)) {
+cur_tick = hpet_get_ticks(s);
+} else {
cur_tick = s->hpet_counter;
+}
DPRINTF("qemu: reading counter + 4 = %" PRIx64 "\n",
cur_tick);
return cur_tick >> 32;
case HPET_STATUS:
@@ -419,8 +418,9 @@ static void hpet_ram_writel(void *opaque,
target_phys_addr_t addr,
| new_val;
}
timer->config &= ~HPET_TN_SETVAL;
-if (hpet_enabled())
+if (hpet_enabled(s)) {
hpet_set_timer(timer);
+}
break;
case HPET_TN_CMP + 4: // comparator register high order
DPRINTF("qemu: hpet_ram_writel HPET_TN_CMP + 4\n");
@@ -439,8 +439,9 @@ static void hpet_ram_writel(void *opaque,
target_phys_addr_t addr,
| new_val << 32;
}
timer->config &=
[Qemu-devel] [PATCH, RFC 1/4] mc146818: move hpet handling to pc.c
Move hpet_in_legacy_mode check from mc146818.c to pc.c. Remove
the optimization where the periodic timer is disabled if
hpet is in legacy mode.
Signed-off-by: Blue Swirl
---
hw/mc146818rtc.c | 37 +++--
hw/mc146818rtc.h |2 ++
hw/pc.c | 32 +++-
3 files changed, 36 insertions(+), 35 deletions(-)
diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
index 571c593..e0c33c5 100644
--- a/hw/mc146818rtc.c
+++ b/hw/mc146818rtc.c
@@ -27,7 +27,6 @@
#include "pc.h"
#include "apic.h"
#include "isa.h"
-#include "hpet_emul.h"
#include "mc146818rtc.h"
//#define DEBUG_CMOS
@@ -94,19 +93,6 @@ typedef struct RTCState {
QEMUTimer *second_timer2;
} RTCState;
-static void rtc_irq_raise(qemu_irq irq)
-{
-/* When HPET is operating in legacy mode, RTC interrupts are disabled
- * We block qemu_irq_raise, but not qemu_irq_lower, in case legacy
- * mode is established while interrupt is raised. We want it to
- * be lowered in any case
- */
-#if defined TARGET_I386
-if (!hpet_in_legacy_mode())
-#endif
-qemu_irq_raise(irq);
-}
-
static void rtc_set_time(RTCState *s);
static void rtc_copy_date(RTCState *s);
@@ -131,7 +117,7 @@ static void rtc_coalesced_timer(void *opaque)
if (s->irq_coalesced != 0) {
apic_reset_irq_delivered();
s->cmos_data[RTC_REG_C] |= 0xc0;
-rtc_irq_raise(s->irq);
+qemu_irq_raise(s->irq);
if (apic_get_irq_delivered()) {
s->irq_coalesced--;
}
@@ -145,19 +131,10 @@ static void rtc_timer_update(RTCState *s,
int64_t current_time)
{
int period_code, period;
int64_t cur_clock, next_irq_clock;
-int enable_pie;
period_code = s->cmos_data[RTC_REG_A] & 0x0f;
-#if defined TARGET_I386
-/* disable periodic timer if hpet is in legacy mode, since interrupts are
- * disabled anyway.
- */
-enable_pie = !hpet_in_legacy_mode();
-#else
-enable_pie = 1;
-#endif
if (period_code != 0
-&& (((s->cmos_data[RTC_REG_B] & REG_B_PIE) && enable_pie)
+&& ((s->cmos_data[RTC_REG_B] & REG_B_PIE)
|| ((s->cmos_data[RTC_REG_B] & REG_B_SQWE) && s->sqw_irq))) {
if (period_code <= 2)
period_code += 7;
@@ -194,14 +171,14 @@ static void rtc_periodic_timer(void *opaque)
if (s->irq_reinject_on_ack_count >= RTC_REINJECT_ON_ACK_COUNT)
s->irq_reinject_on_ack_count = 0;
apic_reset_irq_delivered();
-rtc_irq_raise(s->irq);
+qemu_irq_raise(s->irq);
if (!apic_get_irq_delivered()) {
s->irq_coalesced++;
rtc_coalesced_timer_update(s);
}
} else
#endif
-rtc_irq_raise(s->irq);
+qemu_irq_raise(s->irq);
}
if (s->cmos_data[RTC_REG_B] & REG_B_SQWE) {
/* Not square wave at all but we don't want 2048Hz interrupts!
@@ -430,7 +407,7 @@ static void rtc_update_second2(void *opaque)
s->cmos_data[RTC_HOURS_ALARM] == s->current_tm.tm_hour)) {
s->cmos_data[RTC_REG_C] |= 0xa0;
-rtc_irq_raise(s->irq);
+qemu_irq_raise(s->irq);
}
}
@@ -438,7 +415,7 @@ static void rtc_update_second2(void *opaque)
s->cmos_data[RTC_REG_C] |= REG_C_UF;
if (s->cmos_data[RTC_REG_B] & REG_B_UIE) {
s->cmos_data[RTC_REG_C] |= REG_C_IRQF;
- rtc_irq_raise(s->irq);
+ qemu_irq_raise(s->irq);
}
/* clear update in progress bit */
@@ -588,7 +565,7 @@ static int rtc_initfn(ISADevice *dev)
{
RTCState *s = DO_UPCAST(RTCState, dev, dev);
int base = 0x70;
-int isairq = 8;
+int isairq = RTC_ISA_IRQ;
isa_init_irq(dev, &s->irq, isairq);
diff --git a/hw/mc146818rtc.h b/hw/mc146818rtc.h
index 6f46a68..d630485 100644
--- a/hw/mc146818rtc.h
+++ b/hw/mc146818rtc.h
@@ -7,4 +7,6 @@ ISADevice *rtc_init(int base_year);
void rtc_set_memory(ISADevice *dev, int addr, int val);
void rtc_set_date(ISADevice *dev, const struct tm *tm);
+#define RTC_ISA_IRQ 8
+
#endif /* !MC146818RTC_H */
diff --git a/hw/pc.c b/hw/pc.c
index e7f31d3..5a703e1 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -66,16 +66,38 @@ struct e820_table {
static struct e820_table e820_table;
-void isa_irq_handler(void *opaque, int n, int level)
+static void isa_set_irq(IsaIrqState *isa, int n, int level)
{
-IsaIrqState *isa = (IsaIrqState *)opaque;
-
if (n < 16) {
qemu_set_irq(isa->i8259[n], level);
}
-if (isa->ioapic)
+if (isa->ioapic) {
qemu_set_irq(isa->ioapic[n], level);
-};
+}
+}
+
+static void rtc_irq_handler(IsaIrqState *isa, int level)
+{
+/* When HPET is operating in legacy mode, RTC interrupts are disabled.
+ * We block qemu_irq_raise, but not qemu_irq_lower, in case legacy
+ * mode is established while interrupt is raised. We want it to
+ * be lowered in any case.
+ */
+if (!hpet_in_legacy_mode() || !leve
[Qemu-devel] [PATCH, RFC 0/4] HPET/RTC refactoring
Rearrange code so that in the end, mc146818 can be compiled once. The other patches should be safe, but I'm not so sure about coalesced irq handling changes in 3/4. Also, is the periodic timer optimization (removed in 1/4) very important? Blue Swirl (4): mc146818: move hpet handling to pc.c hpet: don't use any static state mc146818: push apic dependencies to pc.c Compile mc146818 only once Makefile.objs|1 + Makefile.target |7 +-- default-configs/i386-softmmu.mak |1 + default-configs/mips-softmmu.mak |1 + default-configs/mips64-softmmu.mak |1 + default-configs/mips64el-softmmu.mak |1 + default-configs/mipsel-softmmu.mak |1 + default-configs/ppc-softmmu.mak |1 + default-configs/ppc64-softmmu.mak|1 + default-configs/ppcemb-softmmu.mak |1 + default-configs/sparc64-softmmu.mak |1 + default-configs/x86_64-softmmu.mak |1 + hw/hpet.c| 68 ++ hw/hpet_emul.h |4 +- hw/mc146818rtc.c | 88 +++--- hw/mc146818rtc.h |3 + hw/pc.c | 44 ++--- hw/pc.h |4 +- hw/pc_piix.c |3 +- 19 files changed, 125 insertions(+), 107 deletions(-)
Re: [Qemu-devel] Inquiry about qemu for Motorola 68360
Le dimanche 23 mai 2010 à 08:47 +0100, hadi motamedi a écrit : > > > > > >>While QEMU does indeed works for x86 Windows, current QEMU's m68k > architecture does not included that specific Motorola chip. > Thank you for your reply. Can you please let me know which Motorola > chips are being currently supported? Only Coldfire, see target-m68k/helper.c: m5206 m5208 cfv4e If you want 68000, 68020, 68040, 68060, you can clone my repository: git clone http://git.gitorious.org/qemu-m68k/qemu-m68k.git Laurent -- - laur...@vivier.eu -- "Tout ce qui est impossible reste à accomplir"Jules Verne "Things are only impossible until they're not" Jean-Luc Picard
Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm
On 05/21/2010 12:29 AM, Anthony Liguori wrote: I'd be more interested in enabling people to build these types of storage systems without touching qemu. Both sheepdog and ceph ultimately transmit I/O over a socket to a central daemon, right? That incurs an extra copy. So could we not standardize a protocol for this that both sheepdog and ceph could implement? The protocol already exists, nbd. It doesn't support snapshotting etc. but we could extend it. But IMO what's needed is a plugin API for the block layer. -- error compiling committee.c: too many arguments to function
[Qemu-devel] [PATCH v3 11/17] Add QBuffer
From: Jan Kiszka
This introduces a buffer object for use with QMP. As a buffer is not
natively encodable in JSON, we encode it as a base64 string and
encapsulate the result in the new QMP object class "buffer".
The first use case for this is pushing the content of buffers that are
part of a device state into a qdict.
Signed-off-by: Jan Kiszka
---
Makefile |5 +-
Makefile.objs|2 +-
QMP/qmp-spec.txt | 10 +++-
check-qbuffer.c | 172 ++
configure|2 +-
qbuffer.c| 116
qbuffer.h| 33 ++
qjson.c | 15 +
qobject.h|1 +
9 files changed, 351 insertions(+), 5 deletions(-)
create mode 100644 check-qbuffer.c
create mode 100644 qbuffer.c
create mode 100644 qbuffer.h
diff --git a/Makefile b/Makefile
index 1514433..89dda9e 100644
--- a/Makefile
+++ b/Makefile
@@ -144,14 +144,15 @@ qemu-io$(EXESUF): qemu-io.o cmd.o qemu-tool.o
qemu-error.o $(block-obj-y) $(qobj
qemu-img-cmds.h: $(SRC_PATH)/qemu-img-cmds.hx
$(call quiet-command,sh $(SRC_PATH)/hxtool -h < $< > $@," GEN $@")
-check-qint.o check-qstring.o check-qdict.o check-qlist.o check-qfloat.o
check-qjson.o: $(GENERATED_HEADERS)
+check-qint.o check-qstring.o check-qdict.o check-qlist.o check-qfloat.o
check-qjson.o check-qbuffer: $(GENERATED_HEADERS)
check-qint: check-qint.o qint.o qemu-malloc.o
check-qstring: check-qstring.o qstring.o qemu-malloc.o
check-qdict: check-qdict.o qdict.o qfloat.o qint.o qstring.o qbool.o
qemu-malloc.o qlist.o
check-qlist: check-qlist.o qlist.o qint.o qemu-malloc.o
check-qfloat: check-qfloat.o qfloat.o qemu-malloc.o
-check-qjson: check-qjson.o qfloat.o qint.o qdict.o qstring.o qlist.o qbool.o
qjson.o json-streamer.o json-lexer.o json-parser.o qemu-malloc.o
+check-qjson: check-qjson.o qfloat.o qint.o qdict.o qstring.o qlist.o qbool.o
qbuffer.o base64.o qjson.o json-streamer.o json-lexer.o json-parser.o
qemu-malloc.o
+check-qbuffer: check-qbuffer.o qbuffer.o base64.o qstring.o qemu-malloc.o
clean:
# avoid old build problems by removing potentially incorrect old files
diff --git a/Makefile.objs b/Makefile.objs
index 81481c8..da55ec2 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -1,6 +1,6 @@
###
# QObject
-qobject-obj-y = qint.o qstring.o qdict.o qlist.o qfloat.o qbool.o
+qobject-obj-y = qint.o qstring.o qdict.o qlist.o qfloat.o qbool.o qbuffer.o
qobject-obj-y += qjson.o json-lexer.o json-streamer.o json-parser.o
qobject-obj-y += qerror.o base64.o
diff --git a/QMP/qmp-spec.txt b/QMP/qmp-spec.txt
index fa1dd62..820e39d 100644
--- a/QMP/qmp-spec.txt
+++ b/QMP/qmp-spec.txt
@@ -153,7 +153,15 @@ JSON objects that contain the key-value pair '"__class__":
json-string' are
reserved for QMP-specific complex object classes that. QMP specifies which
further keys each of these objects include and how they are encoded.
-So far, no complex object class is specified.
+2.6.1 Buffer class
+--
+
+This QMP object class allows to transport binary data. A buffer object
+consists of the following keys:
+
+{ "__class__": "buffer", "data": json-string }
+
+The data string is base64 encoded according to RFC 4648.
3. QMP Examples
===
diff --git a/check-qbuffer.c b/check-qbuffer.c
new file mode 100644
index 000..b490230
--- /dev/null
+++ b/check-qbuffer.c
@@ -0,0 +1,172 @@
+/*
+ * QBuffer unit-tests.
+ *
+ * Copyright (C) 2010 Siemens AG
+ *
+ * Authors:
+ * Jan Kiszka
+ *
+ * This work is licensed under the terms of the GNU GPL version 2.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+#include
+
+#include "qbuffer.h"
+#include "qemu-common.h"
+
+const char data[] = "some data";
+
+START_TEST(qbuffer_from_data_test)
+{
+QBuffer *qbuffer;
+
+qbuffer = qbuffer_from_data(data, sizeof(data));
+fail_unless(qbuffer != NULL);
+fail_unless(qbuffer->base.refcnt == 1);
+fail_unless(memcmp(data, qbuffer->data, sizeof(data)) == 0);
+fail_unless(qbuffer->size == sizeof(data));
+fail_unless(qobject_type(QOBJECT(qbuffer)) == QTYPE_QBUFFER);
+
+/* destroy doesn't exit yet */
+qemu_free(qbuffer->data);
+qemu_free(qbuffer);
+}
+END_TEST
+
+START_TEST(qbuffer_destroy_test)
+{
+QBuffer *qbuffer = qbuffer_from_data(data, sizeof(data));
+
+QDECREF(qbuffer);
+}
+END_TEST
+
+START_TEST(qbuffer_get_data_test)
+{
+QBuffer *qbuffer;
+const void *ret_data;
+
+qbuffer = qbuffer_from_data(data, sizeof(data));
+ret_data = qbuffer_get_data(qbuffer);
+fail_unless(memcmp(ret_data, data, sizeof(data)) == 0);
+
+QDECREF(qbuffer);
+}
+END_TEST
+
+START_TEST(qbuffer_get_size_test)
+{
+QBuffer *qbuffer;
+
+qbuffer = qbuffer_from_data(data, sizeof(data));
+fail_unless(qbuffer_get_size(qbuffer) == sizeof(data));
+
+QDECREF(qbuffer);
+}
+END_TEST
+
+START_TEST(qbuffer_from_qs
[Qemu-devel] Re: [PATCH] kvm: Switch kvm_update_guest_debug to run_on_cpu
On 05/20/2010 01:28 AM, Jan Kiszka wrote: From: Jan Kiszka Guest debugging under KVM is currently broken once io-threads are enabled. Easily fixable by switching the fake on_vcpu to the real run_on_cpu implementation. Applied uq/master, thanks. -- error compiling committee.c: too many arguments to function
[Qemu-devel] [PATCH v3 01/17] Add dependency of JSON unit tests on config-host.h
From: Jan Kiszka Signed-off-by: Jan Kiszka --- Makefile |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/Makefile b/Makefile index 3a8a311..1514433 100644 --- a/Makefile +++ b/Makefile @@ -144,6 +144,8 @@ qemu-io$(EXESUF): qemu-io.o cmd.o qemu-tool.o qemu-error.o $(block-obj-y) $(qobj qemu-img-cmds.h: $(SRC_PATH)/qemu-img-cmds.hx $(call quiet-command,sh $(SRC_PATH)/hxtool -h < $< > $@," GEN $@") +check-qint.o check-qstring.o check-qdict.o check-qlist.o check-qfloat.o check-qjson.o: $(GENERATED_HEADERS) + check-qint: check-qint.o qint.o qemu-malloc.o check-qstring: check-qstring.o qstring.o qemu-malloc.o check-qdict: check-qdict.o qdict.o qfloat.o qint.o qstring.o qbool.o qemu-malloc.o qlist.o -- 1.6.0.2
[Qemu-devel] [PATCH v3 14/17] monitor: Add basic device state visualization
From: Jan Kiszka
This introduces device_show, a monitor command that saves the vmstate of
a qdev device and visualizes it. Buffers are cut after 16 byte by
default, but the full content can be requested via '-f'. To pretty-print
sub-arrays, vmstate is extended to store the start index name. A new
qerror is introduced to signal a missing vmstate. QMP is not supported
as we cannot provide a stable interface, at least at this point.
Signed-off-by: Jan Kiszka
---
hw/hw.h |2 +
hw/qdev.c | 243 +++
hw/qdev.h |2 +
qemu-monitor.hx | 19 +
qerror.c|4 +
qerror.h|3 +
6 files changed, 273 insertions(+), 0 deletions(-)
diff --git a/hw/hw.h b/hw/hw.h
index fc2d184..cc4bd5f 100644
--- a/hw/hw.h
+++ b/hw/hw.h
@@ -299,6 +299,7 @@ enum VMStateFlags {
typedef struct {
const char *name;
+const char *start_index;
size_t offset;
size_t size;
size_t start;
@@ -413,6 +414,7 @@ extern const VMStateInfo vmstate_info_unused_buffer;
.size = sizeof(_type), \
.flags = VMS_ARRAY, \
.offset = vmstate_offset_sub_array(_state, _field, _type, _start), \
+.start_index = (stringify(_start)), \
}
#define VMSTATE_VARRAY_INT32(_field, _state, _field_num, _version, _info,
_type) {\
diff --git a/hw/qdev.c b/hw/qdev.c
index 6f7d745..b5bf72c 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -29,6 +29,9 @@
#include "qdev.h"
#include "sysemu.h"
#include "monitor.h"
+#include "qjson.h"
+#include "qint.h"
+#include "qbuffer.h"
static int qdev_hotplug = 0;
@@ -889,3 +892,243 @@ int do_device_del(Monitor *mon, const QDict *qdict,
QObject **ret_data)
}
return qdev_unplug(dev);
}
+
+#define NAME_COLUMN_WIDTH 23
+
+static void print_field(Monitor *mon, const QDict *qfield, int indent);
+
+static void print_elem(Monitor *mon, const QObject *qelem, size_t size,
+ int column_pos, int indent)
+{
+int64_t data_size;
+const void *data;
+int n;
+
+if (qobject_type(qelem) == QTYPE_QDICT) {
+if (column_pos >= 0) {
+monitor_printf(mon, ".\n");
+}
+} else {
+monitor_printf(mon, ":");
+column_pos++;
+if (column_pos < NAME_COLUMN_WIDTH) {
+monitor_printf(mon, "%*c", NAME_COLUMN_WIDTH - column_pos, ' ');
+}
+}
+
+switch (qobject_type(qelem)) {
+case QTYPE_QDICT:
+print_field(mon, qobject_to_qdict(qelem), indent + 2);
+break;
+case QTYPE_QBUFFER:
+data = qbuffer_get_data(qobject_to_qbuffer(qelem));
+data_size = qbuffer_get_size(qobject_to_qbuffer(qelem));
+for (n = 0; n < data_size; ) {
+monitor_printf(mon, " %02x", *((uint8_t *)data+n));
+if (++n < size) {
+if (n % 16 == 0) {
+monitor_printf(mon, "\n%*c", NAME_COLUMN_WIDTH, ' ');
+} else if (n % 8 == 0) {
+monitor_printf(mon, " -");
+}
+}
+}
+if (data_size < size) {
+monitor_printf(mon, " ...");
+}
+monitor_printf(mon, "\n");
+break;
+case QTYPE_QINT:
+monitor_printf(mon, " %0*" PRIx64 "\n", (int)size * 2,
+ qint_get_int(qobject_to_qint(qelem)));
+break;
+default:
+assert(0);
+}
+}
+
+static void print_field(Monitor *mon, const QDict *qfield, int indent)
+{
+const char *name = qdict_get_str(qfield, "name");
+const char *start = qdict_get_try_str(qfield, "start");
+int64_t size = qdict_get_int(qfield, "size");
+QList *qlist = qdict_get_qlist(qfield, "elems");
+QListEntry *entry, *sub_entry;
+QList *sub_list;
+int elem_no = 0;
+
+QLIST_FOREACH_ENTRY(qlist, entry) {
+QObject *qelem = qlist_entry_obj(entry);
+int pos = indent + strlen(name);
+
+if (qobject_type(qelem) == QTYPE_QLIST) {
+monitor_printf(mon, "%*c%s", indent, ' ', name);
+if (start) {
+pos += monitor_printf(mon, "[%s+%02x]", start, elem_no);
+} else {
+pos += monitor_printf(mon, "[%02x]", elem_no);
+}
+sub_list = qobject_to_qlist(qelem);
+QLIST_FOREACH_ENTRY(sub_list, sub_entry) {
+print_elem(mon, qlist_entry_obj(sub_entry), size, pos,
+ indent + 2);
+pos = -1;
+}
+} else {
+if (elem_no == 0) {
+monitor_printf(mon, "%*c%s", indent, ' ', name);
+} else {
+pos = -1;
+}
+print_elem(mon, qelem, size, pos, indent);
+}
+elem_no++;
+}
+}
+
+void device_user_print(Monitor *mon, const QObject *data)
+{
+QDict *qdict = qobject_to_qdict(data);
[Qemu-devel] [PATCH v3 16/17] QMP: Fix python helper /wrt long return strings
From: Jan Kiszka Remove the arbitrary limitation of 1024 characters per return string and read complete lines instead. Required for device_show. Signed-off-by: Jan Kiszka --- QMP/qmp.py |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/QMP/qmp.py b/QMP/qmp.py index d9da603..4062f84 100644 --- a/QMP/qmp.py +++ b/QMP/qmp.py @@ -63,10 +63,14 @@ class QEMUMonitorProtocol: def __json_read(self): try: -return json.loads(self.sock.recv(1024)) +while True: +line = json.loads(self.sockfile.readline()) +if not 'event' in line: +return line except ValueError: return def __init__(self, filename): self.filename = filename self.sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) +self.sockfile = self.sock.makefile() -- 1.6.0.2
[Qemu-devel] [PATCH v3 12/17] monitor: return length of printed string via monitor_[v]printf
From: Jan Kiszka
This simply forwards the result of the internal vsnprintf to the callers
of monitor_printf and monitor_vprintf. When invoked over a QMP session
or in absence of an active monitor, -1 is returned.
Signed-off-by: Jan Kiszka
---
monitor.c | 23 +++
monitor.h |4 ++--
qemu-tool.c |6 --
3 files changed, 21 insertions(+), 12 deletions(-)
diff --git a/monitor.c b/monitor.c
index 64de10a..6766e49 100644
--- a/monitor.c
+++ b/monitor.c
@@ -258,29 +258,36 @@ static void monitor_puts(Monitor *mon, const char *str)
}
}
-void monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
+int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
{
char buf[4096];
+int ret;
-if (!mon)
-return;
-
+if (!mon) {
+return -1;
+}
mon_print_count_inc(mon);
if (monitor_ctrl_mode(mon)) {
-return;
+return -1;
}
-vsnprintf(buf, sizeof(buf), fmt, ap);
+ret = vsnprintf(buf, sizeof(buf), fmt, ap);
monitor_puts(mon, buf);
+
+return ret;
}
-void monitor_printf(Monitor *mon, const char *fmt, ...)
+int monitor_printf(Monitor *mon, const char *fmt, ...)
{
va_list ap;
+int ret;
+
va_start(ap, fmt);
-monitor_vprintf(mon, fmt, ap);
+ret = monitor_vprintf(mon, fmt, ap);
va_end(ap);
+
+return ret;
}
void monitor_print_filename(Monitor *mon, const char *filename)
diff --git a/monitor.h b/monitor.h
index ea15469..32c0170 100644
--- a/monitor.h
+++ b/monitor.h
@@ -45,8 +45,8 @@ int monitor_read_bdrv_key_start(Monitor *mon,
BlockDriverState *bs,
int monitor_get_fd(Monitor *mon, const char *fdname);
-void monitor_vprintf(Monitor *mon, const char *fmt, va_list ap);
-void monitor_printf(Monitor *mon, const char *fmt, ...)
+int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap);
+int monitor_printf(Monitor *mon, const char *fmt, ...)
__attribute__ ((__format__ (__printf__, 2, 3)));
void monitor_print_filename(Monitor *mon, const char *filename);
void monitor_flush(Monitor *mon);
diff --git a/qemu-tool.c b/qemu-tool.c
index b39af86..f6ce6cd 100644
--- a/qemu-tool.c
+++ b/qemu-tool.c
@@ -43,12 +43,14 @@ void monitor_set_error(Monitor *mon, QError *qerror)
{
}
-void monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
+int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
{
+return -1;
}
-void monitor_printf(Monitor *mon, const char *fmt, ...)
+int monitor_printf(Monitor *mon, const char *fmt, ...)
{
+return -1;
}
void monitor_print_filename(Monitor *mon, const char *filename)
--
1.6.0.2
[Qemu-devel] [PATCH v3 15/17] QMP: Teach basic capability negotiation to python example
From: Jan Kiszka
As sending "qmp_capabilities" on session start became mandatory, both
python examples were broken.
Signed-off-by: Jan Kiszka
---
QMP/qmp-shell |1 +
QMP/vm-info |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/QMP/qmp-shell b/QMP/qmp-shell
index f89b9af..a5b72d1 100755
--- a/QMP/qmp-shell
+++ b/QMP/qmp-shell
@@ -42,6 +42,7 @@ def main():
qemu = qmp.QEMUMonitorProtocol(argv[1])
qemu.connect()
+qemu.send("qmp_capabilities")
print 'Connected!'
diff --git a/QMP/vm-info b/QMP/vm-info
index b150d82..d29e7f5 100755
--- a/QMP/vm-info
+++ b/QMP/vm-info
@@ -24,6 +24,7 @@ def main():
qemu = qmp.QEMUMonitorProtocol(argv[1])
qemu.connect()
+qemu.send("qmp_capabilities")
for cmd in [ 'version', 'hpet', 'kvm', 'status', 'uuid', 'balloon' ]:
print cmd + ': ' + str(qemu.send('query-' + cmd))
--
1.6.0.2
[Qemu-devel] [PATCH v3 09/17] Add base64 encoder/decoder
From: Jan Kiszka
Will be used by QBuffer.
Signed-off-by: Jan Kiszka
---
Makefile.objs |2 +-
base64.c | 202 +
base64.h | 19 ++
3 files changed, 222 insertions(+), 1 deletions(-)
create mode 100644 base64.c
create mode 100644 base64.h
diff --git a/Makefile.objs b/Makefile.objs
index 1585101..81481c8 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -2,7 +2,7 @@
# QObject
qobject-obj-y = qint.o qstring.o qdict.o qlist.o qfloat.o qbool.o
qobject-obj-y += qjson.o json-lexer.o json-streamer.o json-parser.o
-qobject-obj-y += qerror.o
+qobject-obj-y += qerror.o base64.o
###
# block-obj-y is code used by both qemu system emulation and qemu-img
diff --git a/base64.c b/base64.c
new file mode 100644
index 000..750d0fb
--- /dev/null
+++ b/base64.c
@@ -0,0 +1,202 @@
+/*
+ * Base64 encoder/decoder conforming to RFC 4648
+ * (based on Mozilla's nsprpub/lib/libc/src/base64.c)
+ *
+ * Copyright (C) 2010 Siemens AG
+ *
+ * Authors:
+ * Jan Kiszka
+ *
+ * This work is licensed under the terms of the GNU LGPL, version 2.1 or later.
+ * See the COPYING.LIB file in the top-level directory.
+ *
+ */
+
+#include
+#include "base64.h"
+
+static const char base[] =
+"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/";
+
+static void encode3to4(const uint8_t *src, char *dest)
+{
+uint32_t b32 = 0;
+int i, j = 18;
+
+for (i = 0; i < 3; i++) {
+b32 <<= 8;
+b32 |= src[i];
+}
+for (i = 0; i < 4; i++) {
+dest[i] = base[(b32 >> j) & 0x3F];
+j -= 6;
+}
+}
+
+static void encode2to4(const uint8_t *src, char *dest)
+{
+dest[0] = base[(src[0] >> 2) & 0x3F];
+dest[1] = base[((src[0] & 0x03) << 4) | ((src[1] >> 4) & 0x0F)];
+dest[2] = base[(src[1] & 0x0F) << 2];
+dest[3] = '=';
+}
+
+static void encode1to4(const uint8_t *src, char *dest)
+{
+dest[0] = base[(src[0] >> 2) & 0x3F];
+dest[1] = base[(src[0] & 0x03) << 4];
+dest[2] = '=';
+dest[3] = '=';
+}
+
+/*
+ * Encode data in 'src' of length 'srclen' to a base64 string, saving the
+ * null-terminated result in 'dest'. The size of the destition buffer must be
+ * at least ((srclen + 2) / 3) * 4 + 1.
+ */
+void base64_encode(const uint8_t *src, size_t srclen, char *dest)
+{
+while (srclen >= 3) {
+encode3to4(src, dest);
+src += 3;
+dest += 4;
+srclen -= 3;
+}
+switch (srclen) {
+case 2:
+encode2to4(src, dest);
+dest += 4;
+break;
+case 1:
+encode1to4(src, dest);
+dest += 4;
+break;
+case 0:
+break;
+}
+dest[0] = 0;
+}
+
+static int32_t codetovalue(char c)
+{
+if (c >= 'A' && c <= 'Z') {
+return c - 'A';
+} else if (c >= 'a' && c <= 'z') {
+return c - 'a' + 26;
+} else if (c >= '0' && c <= '9') {
+return c - '0' + 52;
+} else if (c == '+') {
+return 62;
+} else if ( c == '/') {
+return 63;
+} else {
+return -1;
+}
+}
+
+static int decode4to3 (const char *src, uint8_t *dest)
+{
+uint32_t b32 = 0;
+int32_t bits;
+int i;
+
+for (i = 0; i < 4; i++) {
+bits = codetovalue(src[i]);
+if (bits < 0) {
+return bits;
+}
+b32 <<= 6;
+b32 |= bits;
+}
+dest[0] = (b32 >> 16) & 0xFF;
+dest[1] = (b32 >> 8) & 0xFF;
+dest[2] = b32 & 0xFF;
+
+return 0;
+}
+
+static int decode3to2(const char *src, uint8_t *dest)
+{
+uint32_t b32 = 0;
+int32_t bits;
+
+bits = codetovalue(src[0]);
+if (bits < 0) {
+return bits;
+}
+b32 = (uint32_t)bits;
+b32 <<= 6;
+
+bits = codetovalue(src[1]);
+if (bits < 0) {
+return bits;
+}
+b32 |= (uint32_t)bits;
+b32 <<= 4;
+
+bits = codetovalue(src[2]);
+if (bits < 0) {
+return bits;
+}
+b32 |= ((uint32_t)bits) >> 2;
+
+dest[0] = (b32 >> 8) & 0xFF;
+dest[1] = b32 & 0xFF;
+
+return 0;
+}
+
+static int decode2to1(const char *src, uint8_t *dest)
+{
+uint32_t b32;
+int32_t bits;
+
+bits = codetovalue(src[0]);
+if (bits < 0) {
+return bits;
+}
+b32 = (uint32_t)bits << 2;
+
+bits = codetovalue(src[1]);
+if (bits < 0) {
+return bits;
+}
+b32 |= ((uint32_t)bits) >> 4;
+
+dest[0] = b32;
+
+return 0;
+}
+
+/*
+ * Convert string 'src' of length 'srclen' from base64 to binary form,
+ * saving the result in 'dest'. The size of the destination buffer must be at
+ * least srclen * 3 / 4.
+ *
+ * Returns 0 on success, -1 on conversion error.
+ */
+int base64_decode(const char *src, size_t srclen, uint8_t *dest)
+{
+int ret;
+
+while (srclen >= 4) {
+ret = decode4to3(src, dest);
+if (ret < 0) {
+return ret;
+}
+src += 4;
+dest += 3;
+srcl
[Qemu-devel] [PATCH v3 08/17] monitor: Add completion for qdev paths
From: Jan Kiszka
Implement monitor command line completion for device tree paths. The
first user is device_del.
Signed-off-by: Jan Kiszka
---
hw/qdev.c | 50 ++--
hw/qdev.h |2 +
monitor.c | 85 +++
qemu-monitor.hx |2 +-
4 files changed, 123 insertions(+), 16 deletions(-)
diff --git a/hw/qdev.c b/hw/qdev.c
index e07ec98..6f7d745 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -39,7 +39,7 @@ DeviceInfo *device_info_list;
static BusState *qbus_find_recursive(BusState *bus, const char *name,
const BusInfo *info);
-static BusState *qbus_find(const char *path);
+static BusState *qbus_find_internal(const char *path, bool report_errors);
/* Register a new device type. */
void qdev_register(DeviceInfo *info)
@@ -217,7 +217,7 @@ DeviceState *qdev_device_add(QemuOpts *opts)
/* find bus */
path = qemu_opt_get(opts, "bus");
if (path != NULL) {
-bus = qbus_find(path);
+bus = qbus_find_internal(path, true);
if (!bus) {
return NULL;
}
@@ -575,7 +575,7 @@ static DeviceState *qbus_find_dev(BusState *bus, const char
*elem)
return NULL;
}
-static BusState *qbus_find(const char *path)
+static BusState *qbus_find_internal(const char *path, bool report_errors)
{
DeviceState *dev, *next_dev;
BusState *bus;
@@ -593,7 +593,9 @@ static BusState *qbus_find(const char *path)
}
bus = qbus_find_recursive(main_system_bus, elem, NULL);
if (!bus) {
-qerror_report(QERR_BUS_NOT_FOUND, elem);
+if (report_errors) {
+qerror_report(QERR_BUS_NOT_FOUND, elem);
+}
return NULL;
}
pos = len;
@@ -616,8 +618,10 @@ static BusState *qbus_find(const char *path)
pos += len;
dev = qbus_find_dev(bus, elem);
if (!dev) {
-qerror_report(QERR_DEVICE_NOT_FOUND, elem);
-qbus_list_dev(bus);
+if (report_errors) {
+qerror_report(QERR_DEVICE_NOT_FOUND, elem);
+qbus_list_dev(bus);
+}
return NULL;
}
@@ -631,13 +635,17 @@ search_dev_bus:
* one child bus accept it nevertheless */
switch (dev->num_child_bus) {
case 0:
-qerror_report(QERR_DEVICE_NO_BUS, elem);
+if (report_errors) {
+qerror_report(QERR_DEVICE_NO_BUS, elem);
+}
return NULL;
case 1:
return QTAILQ_FIRST(&dev->child_bus);
default:
-qerror_report(QERR_DEVICE_MULTIPLE_BUSSES, elem);
-qbus_list_bus(dev);
+if (report_errors) {
+qerror_report(QERR_DEVICE_MULTIPLE_BUSSES, elem);
+qbus_list_bus(dev);
+}
return NULL;
}
}
@@ -659,14 +667,21 @@ search_dev_bus:
goto search_dev_bus;
}
}
-qerror_report(QERR_BUS_NOT_FOUND, elem);
-qbus_list_bus(dev);
+if (report_errors) {
+qerror_report(QERR_BUS_NOT_FOUND, elem);
+qbus_list_bus(dev);
+}
return NULL;
}
}
}
-static DeviceState *qdev_find(const char *path)
+BusState *qbus_find(const char *path)
+{
+return qbus_find_internal(path, false);
+}
+
+static DeviceState *qdev_find_internal(const char *path, bool report_errors)
{
const char *dev_name;
DeviceState *dev;
@@ -682,7 +697,7 @@ static DeviceState *qdev_find(const char *path)
bus_path = qemu_strdup(path);
bus_path[dev_name - path] = 0;
-bus = qbus_find(bus_path);
+bus = qbus_find_internal(bus_path, report_errors);
qemu_free(bus_path);
if (!bus) {
@@ -693,7 +708,7 @@ static DeviceState *qdev_find(const char *path)
dev = qbus_find_dev(bus, dev_name);
if (!dev) {
dev = qdev_find_id_recursive(main_system_bus, path);
-if (!dev) {
+if (!dev && report_errors) {
qerror_report(QERR_DEVICE_NOT_FOUND, dev_name);
qbus_list_dev(bus);
}
@@ -701,6 +716,11 @@ static DeviceState *qdev_find(const char *path)
return dev;
}
+DeviceState *qdev_find(const char *path)
+{
+return qdev_find_internal(path, false);
+}
+
void qbus_create_inplace(BusState *bus, BusInfo *info,
DeviceState *parent, const char *name)
{
@@ -862,7 +882,7 @@ int do_device_del(Monitor *mon, const QDict *qdict, QObject
**ret_data)
const char *path = qdict_get_str(qdict, "path");
DeviceState *dev;
-dev = qdev_find(path);
+dev = qdev_find_internal(path, true);
if (!dev) {
qerror_report(QERR_DEVICE_NOT_FOUND, path);
return -1;
d
[Qemu-devel] [PATCH v3 07/17] qdev: Push QMP mode checks into qbus_list_bus/dev
From: Jan Kiszka
Simplifies the usage.
Signed-off-by: Jan Kiszka
---
hw/qdev.c | 22 ++
1 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/hw/qdev.c b/hw/qdev.c
index df945ed..e07ec98 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -492,6 +492,9 @@ static void qbus_list_bus(DeviceState *dev)
BusState *child;
const char *sep = " ";
+if (monitor_cur_is_qmp()) {
+return;
+}
error_printf("child busses at \"%s\":",
dev->id ? dev->id : dev->info->name);
QTAILQ_FOREACH(child, &dev->child_bus, sibling) {
@@ -506,6 +509,9 @@ static void qbus_list_dev(BusState *bus)
DeviceState *dev;
const char *sep = " ";
+if (monitor_cur_is_qmp()) {
+return;
+}
error_printf("devices at \"%s\":", bus->name);
QTAILQ_FOREACH(dev, &bus->children, sibling) {
error_printf("%s\"%s\"", sep, dev->info->name);
@@ -611,9 +617,7 @@ static BusState *qbus_find(const char *path)
dev = qbus_find_dev(bus, elem);
if (!dev) {
qerror_report(QERR_DEVICE_NOT_FOUND, elem);
-if (!monitor_cur_is_qmp()) {
-qbus_list_dev(bus);
-}
+qbus_list_dev(bus);
return NULL;
}
@@ -633,9 +637,7 @@ search_dev_bus:
return QTAILQ_FIRST(&dev->child_bus);
default:
qerror_report(QERR_DEVICE_MULTIPLE_BUSSES, elem);
-if (!monitor_cur_is_qmp()) {
-qbus_list_bus(dev);
-}
+qbus_list_bus(dev);
return NULL;
}
}
@@ -658,9 +660,7 @@ search_dev_bus:
}
}
qerror_report(QERR_BUS_NOT_FOUND, elem);
-if (!monitor_cur_is_qmp()) {
-qbus_list_bus(dev);
-}
+qbus_list_bus(dev);
return NULL;
}
}
@@ -695,9 +695,7 @@ static DeviceState *qdev_find(const char *path)
dev = qdev_find_id_recursive(main_system_bus, path);
if (!dev) {
qerror_report(QERR_DEVICE_NOT_FOUND, dev_name);
-if (!monitor_cur_is_qmp()) {
-qbus_list_dev(bus);
-}
+qbus_list_dev(bus);
}
}
return dev;
--
1.6.0.2
[Qemu-devel] [PATCH v3 17/17] QMP: Add support for buffer class to qmp python helper
From: Jan Kiszka This demonstrates the conversion of QMP buffer objects and does some minimalistic pretty-printing. Signed-off-by: Jan Kiszka --- QMP/qmp.py | 25 +++-- 1 files changed, 23 insertions(+), 2 deletions(-) diff --git a/QMP/qmp.py b/QMP/qmp.py index 4062f84..4650918 100644 --- a/QMP/qmp.py +++ b/QMP/qmp.py @@ -8,7 +8,7 @@ # This work is licensed under the terms of the GNU GPL, version 2. See # the COPYING file in the top-level directory. -import socket, json +import socket, json, binascii class QMPError(Exception): pass @@ -16,6 +16,18 @@ class QMPError(Exception): class QMPConnectError(QMPError): pass +class QMPBuffer: +def __init__(self, data): +self.data = binascii.a2b_base64(data) + +def __repr__(self): +str = '' +for i in range(0, len(self.data)): +if i > 0: +str += ' ' +str += binascii.b2a_hex(self.data[i]) +return str + class QEMUMonitorProtocol: def connect(self): self.sock.connect(self.filename) @@ -61,10 +73,19 @@ class QEMUMonitorProtocol: # the Server won't read our input self.sock.send(json.dumps(cmd) + ' ') +def __json_obj_hook(self, dct): +if '__class__' in dct: +if dct['__class__'] == 'buffer': +return QMPBuffer(dct['data']) +else: +return +return dct + def __json_read(self): try: while True: -line = json.loads(self.sockfile.readline()) +line = json.loads(self.sockfile.readline(), + object_hook=self.__json_obj_hook) if not 'event' in line: return line except ValueError: -- 1.6.0.2
[Qemu-devel] [PATCH v3 04/17] qdev: Give qtree names precedence over user-assigned IDs
From: Jan Kiszka
As the user may specify ambiguous device IDs, let's search for their
official names first before considering the user-supplied identifiers.
Signed-off-by: Jan Kiszka
---
docs/qdev-device-use.txt |4 +++-
hw/qdev.c| 18 +-
2 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/docs/qdev-device-use.txt b/docs/qdev-device-use.txt
index 74d4960..0160191 100644
--- a/docs/qdev-device-use.txt
+++ b/docs/qdev-device-use.txt
@@ -25,7 +25,9 @@ omitted in the path. Example: /i440FX-pcihost/PIIX3
abbreviates
/i440FX-pcihost/pci.0/PIIX3/isa.0 as none of the buses has siblings.
Existing devices can be addressed either via a unique ID if it was
-assigned during creation or via the device tree path:
+assigned during creation or via the device tree path. In conflicts,
+the latter has precedence. A device tree path has the following
+structure:
/full_bus_address/driver_name[.instance_number]
or
diff --git a/hw/qdev.c b/hw/qdev.c
index 6b4a629..eeadf4a 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -535,16 +535,10 @@ static DeviceState *qbus_find_dev(BusState *bus, const
char *elem)
/*
* try to match in order:
- * (1) instance id, if present
- * (2) driver name [.instance]
- * (3) driver alias [.instance], if present
+ * (1) driver name [.instance]
+ * (2) driver alias [.instance], if present
+ * (3) instance id, if present
*/
-QLIST_FOREACH(dev, &bus->children, sibling) {
-if (dev->id && strcmp(dev->id, elem) == 0) {
-return dev;
-}
-}
-
if (sscanf(elem, "%127[^.].%u", buf, &instance) == 2) {
elem = buf;
} else {
@@ -565,6 +559,12 @@ static DeviceState *qbus_find_dev(BusState *bus, const
char *elem)
return dev;
}
}
+
+QLIST_FOREACH(dev, &bus->children, sibling) {
+if (dev->id && strcmp(dev->id, elem) == 0) {
+return dev;
+}
+}
return NULL;
}
--
1.6.0.2
[Qemu-devel] [PATCH v3 05/17] qdev: Convert device and bus lists to QTAILQ
From: Jan Kiszka
Cosmetic change to align the instance number assignment with bus
ordering. The current ordering due to QLIST_INSERT_HEAD is a bit
annoying when you dump the qtree or address devices via
'driver.instance'.
Signed-off-by: Jan Kiszka
---
hw/acpi_piix4.c |2 +-
hw/i2c.c |2 +-
hw/pci-hotplug.c |2 +-
hw/qdev.c| 43 ++-
hw/qdev.h|8
hw/ssi.c |6 +++---
6 files changed, 32 insertions(+), 31 deletions(-)
diff --git a/hw/acpi_piix4.c b/hw/acpi_piix4.c
index 0fce958..3cb3d11 100644
--- a/hw/acpi_piix4.c
+++ b/hw/acpi_piix4.c
@@ -536,7 +536,7 @@ static void pciej_write(void *opaque, uint32_t addr,
uint32_t val)
PCIDevice *dev;
int slot = ffs(val) - 1;
-QLIST_FOREACH_SAFE(qdev, &bus->children, sibling, next) {
+QTAILQ_FOREACH_SAFE(qdev, &bus->children, sibling, next) {
dev = DO_UPCAST(PCIDevice, qdev, qdev);
if (PCI_SLOT(dev->devfn) == slot) {
qdev_free(qdev);
diff --git a/hw/i2c.c b/hw/i2c.c
index bee8e88..61ab6fa 100644
--- a/hw/i2c.c
+++ b/hw/i2c.c
@@ -84,7 +84,7 @@ int i2c_start_transfer(i2c_bus *bus, uint8_t address, int
recv)
DeviceState *qdev;
i2c_slave *slave = NULL;
-QLIST_FOREACH(qdev, &bus->qbus.children, sibling) {
+QTAILQ_FOREACH(qdev, &bus->qbus.children, sibling) {
i2c_slave *candidate = I2C_SLAVE_FROM_QDEV(qdev);
if (candidate->address == address) {
slave = candidate;
diff --git a/hw/pci-hotplug.c b/hw/pci-hotplug.c
index cc45c50..a226d3c 100644
--- a/hw/pci-hotplug.c
+++ b/hw/pci-hotplug.c
@@ -77,7 +77,7 @@ static int scsi_hot_add(Monitor *mon, DeviceState *adapter,
SCSIBus *scsibus;
SCSIDevice *scsidev;
-scsibus = DO_UPCAST(SCSIBus, qbus, QLIST_FIRST(&adapter->child_bus));
+scsibus = DO_UPCAST(SCSIBus, qbus, QTAILQ_FIRST(&adapter->child_bus));
if (!scsibus || strcmp(scsibus->qbus.info->name, "SCSI") != 0) {
error_report("Device is not a SCSI adapter");
return -1;
diff --git a/hw/qdev.c b/hw/qdev.c
index eeadf4a..b3d375a 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -85,10 +85,11 @@ static DeviceState *qdev_create_from_info(BusState *bus,
DeviceInfo *info)
dev = qemu_mallocz(info->size);
dev->info = info;
dev->parent_bus = bus;
+QTAILQ_INIT(&dev->child_bus);
qdev_prop_set_defaults(dev, dev->info->props);
qdev_prop_set_defaults(dev, dev->parent_bus->info->props);
qdev_prop_set_globals(dev);
-QLIST_INSERT_HEAD(&bus->children, dev, sibling);
+QTAILQ_INSERT_TAIL(&bus->children, dev, sibling);
if (qdev_hotplug) {
assert(bus->allow_hotplug);
dev->hotplugged = 1;
@@ -337,7 +338,7 @@ void qdev_free(DeviceState *dev)
if (dev->state == DEV_STATE_INITIALIZED) {
while (dev->num_child_bus) {
-bus = QLIST_FIRST(&dev->child_bus);
+bus = QTAILQ_FIRST(&dev->child_bus);
qbus_free(bus);
}
if (dev->info->vmsd)
@@ -348,7 +349,7 @@ void qdev_free(DeviceState *dev)
qemu_opts_del(dev->opts);
}
qemu_unregister_reset(qdev_reset, dev);
-QLIST_REMOVE(dev, sibling);
+QTAILQ_REMOVE(&dev->parent_bus->children, dev, sibling);
qemu_free(dev);
}
@@ -432,7 +433,7 @@ BusState *qdev_get_child_bus(DeviceState *dev, const char
*name)
{
BusState *bus;
-QLIST_FOREACH(bus, &dev->child_bus, sibling) {
+QTAILQ_FOREACH(bus, &dev->child_bus, sibling) {
if (strcmp(name, bus->name) == 0) {
return bus;
}
@@ -457,8 +458,8 @@ static BusState *qbus_find_recursive(BusState *bus, const
char *name,
return bus;
}
-QLIST_FOREACH(dev, &bus->children, sibling) {
-QLIST_FOREACH(child, &dev->child_bus, sibling) {
+QTAILQ_FOREACH(dev, &bus->children, sibling) {
+QTAILQ_FOREACH(child, &dev->child_bus, sibling) {
ret = qbus_find_recursive(child, name, info);
if (ret) {
return ret;
@@ -473,10 +474,10 @@ static DeviceState *qdev_find_recursive(BusState *bus,
const char *id)
DeviceState *dev, *ret;
BusState *child;
-QLIST_FOREACH(dev, &bus->children, sibling) {
+QTAILQ_FOREACH(dev, &bus->children, sibling) {
if (dev->id && strcmp(dev->id, id) == 0)
return dev;
-QLIST_FOREACH(child, &dev->child_bus, sibling) {
+QTAILQ_FOREACH(child, &dev->child_bus, sibling) {
ret = qdev_find_recursive(child, id);
if (ret) {
return ret;
@@ -493,7 +494,7 @@ static void qbus_list_bus(DeviceState *dev)
error_printf("child busses at \"%s\":",
dev->id ? dev->id : dev->info->name);
-QLIST_FOREACH(child, &dev->child_bus, sibling) {
+QTAILQ_FOREACH(child, &dev->child_bus, sibling) {
error_printf("%s\"%s\"", sep, child->name);
sep = ", ";
}
@@ -506,7 +507,7 @@ static voi
[Qemu-devel] [PATCH v3 03/17] qdev: Allow device addressing via 'driver.instance'
From: Jan Kiszka
Extend qbus_find_dev to allow addressing of devices without an unique id
via an optional per-bus instance number. The new formats are
'driver.instance' and 'alias.instance'.
Signed-off-by: Jan Kiszka
---
docs/qdev-device-use.txt | 14 +-
hw/qdev.c| 23 ++-
2 files changed, 31 insertions(+), 6 deletions(-)
diff --git a/docs/qdev-device-use.txt b/docs/qdev-device-use.txt
index 9ac1fa1..74d4960 100644
--- a/docs/qdev-device-use.txt
+++ b/docs/qdev-device-use.txt
@@ -1,6 +1,6 @@
= How to convert to -device & friends =
-=== Specifying Bus and Address on Bus ===
+=== Specifying Bus, Address on Bus, and Devices ===
In qdev, each device has a parent bus. Some devices provide one or
more buses for children. You can specify a device's parent bus with
@@ -24,6 +24,18 @@ Furthermore, if a device only hosts a single bus, the bus
name can be
omitted in the path. Example: /i440FX-pcihost/PIIX3 abbreviates
/i440FX-pcihost/pci.0/PIIX3/isa.0 as none of the buses has siblings.
+Existing devices can be addressed either via a unique ID if it was
+assigned during creation or via the device tree path:
+
+/full_bus_address/driver_name[.instance_number]
+or
+abbreviated_bus_address/driver_name[.instance_number]
+
+The instance number is zero-based.
+
+Example: /i440FX-pcihost/pci.0/e1000.1 addresses the second e1000
+adapter on the bus 'pci.0'.
+
Note: the USB device address can't be controlled at this time.
=== Block Devices ===
diff --git a/hw/qdev.c b/hw/qdev.c
index 2e50531..6b4a629 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -527,28 +527,41 @@ static BusState *qbus_find_bus(DeviceState *dev, char
*elem)
return NULL;
}
-static DeviceState *qbus_find_dev(BusState *bus, char *elem)
+static DeviceState *qbus_find_dev(BusState *bus, const char *elem)
{
DeviceState *dev;
+int instance, n;
+char buf[128];
/*
* try to match in order:
* (1) instance id, if present
- * (2) driver name
- * (3) driver alias, if present
+ * (2) driver name [.instance]
+ * (3) driver alias [.instance], if present
*/
QLIST_FOREACH(dev, &bus->children, sibling) {
if (dev->id && strcmp(dev->id, elem) == 0) {
return dev;
}
}
+
+if (sscanf(elem, "%127[^.].%u", buf, &instance) == 2) {
+elem = buf;
+} else {
+instance = 0;
+}
+
+n = 0;
QLIST_FOREACH(dev, &bus->children, sibling) {
-if (strcmp(dev->info->name, elem) == 0) {
+if (strcmp(dev->info->name, elem) == 0 && n++ == instance) {
return dev;
}
}
+
+n = 0;
QLIST_FOREACH(dev, &bus->children, sibling) {
-if (dev->info->alias && strcmp(dev->info->alias, elem) == 0) {
+if (dev->info->alias && strcmp(dev->info->alias, elem) == 0 &&
+n++ == instance) {
return dev;
}
}
--
1.6.0.2
[Qemu-devel] [PATCH v3 10/17] QMP: Reserve namespace for complex object classes
From: Jan Kiszka
This reserves JSON objects that contain the key '__class__' for QMP-specific
complex objects. First user will be the buffer class.
Signed-off-by: Jan Kiszka
---
QMP/qmp-spec.txt | 16 +---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/QMP/qmp-spec.txt b/QMP/qmp-spec.txt
index 9d30a8c..fa1dd62 100644
--- a/QMP/qmp-spec.txt
+++ b/QMP/qmp-spec.txt
@@ -146,6 +146,15 @@ The format is:
For a listing of supported asynchronous events, please, refer to the
qmp-events.txt file.
+2.6 Complex object classes
+--
+
+JSON objects that contain the key-value pair '"__class__": json-string' are
+reserved for QMP-specific complex object classes that. QMP specifies which
+further keys each of these objects include and how they are encoded.
+
+So far, no complex object class is specified.
+
3. QMP Examples
===
@@ -229,9 +238,10 @@ avoid modifying QMP. Both upstream and downstream need to
take care to
preserve long-term compatibility and interoperability.
To help with that, QMP reserves JSON object member names beginning with
-'__' (double underscore) for downstream use ("downstream names"). This
-means upstream will never use any downstream names for its commands,
-arguments, errors, asynchronous events, and so forth.
+'__' (double underscore) for downstream use ("downstream names"). Downstream
+names MUST NOT end with '__' as this pattern is reserved for QMP-defined JSON
+object classes. Upstream will never use any downstream names for its
+commands, arguments, errors, asynchronous events, and so forth.
Any new names downstream wishes to add must begin with '__'. To
ensure compatibility with other downstreams, it is strongly
--
1.6.0.2
[Qemu-devel] [PATCH v3 06/17] qdev: Allow device specification by qtree path for device_del
From: Jan Kiszka
Allow to specify the device to be removed via device_del not only by ID
but also by its full or abbreviated qtree path. For this purpose,
qdev_find is introduced which combines walking the qtree with searching
for device IDs if required.
Signed-off-by: Jan Kiszka
---
hw/qdev.c | 49 +++--
qemu-monitor.hx | 10 +-
2 files changed, 48 insertions(+), 11 deletions(-)
diff --git a/hw/qdev.c b/hw/qdev.c
index b3d375a..df945ed 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -469,7 +469,7 @@ static BusState *qbus_find_recursive(BusState *bus, const
char *name,
return NULL;
}
-static DeviceState *qdev_find_recursive(BusState *bus, const char *id)
+static DeviceState *qdev_find_id_recursive(BusState *bus, const char *id)
{
DeviceState *dev, *ret;
BusState *child;
@@ -478,7 +478,7 @@ static DeviceState *qdev_find_recursive(BusState *bus,
const char *id)
if (dev->id && strcmp(dev->id, id) == 0)
return dev;
QTAILQ_FOREACH(child, &dev->child_bus, sibling) {
-ret = qdev_find_recursive(child, id);
+ret = qdev_find_id_recursive(child, id);
if (ret) {
return ret;
}
@@ -666,6 +666,43 @@ search_dev_bus:
}
}
+static DeviceState *qdev_find(const char *path)
+{
+const char *dev_name;
+DeviceState *dev;
+char *bus_path;
+BusState *bus;
+
+dev_name = strrchr(path, '/');
+if (!dev_name) {
+bus = main_system_bus;
+dev_name = path;
+} else {
+dev_name++;
+bus_path = qemu_strdup(path);
+bus_path[dev_name - path] = 0;
+
+bus = qbus_find(bus_path);
+qemu_free(bus_path);
+
+if (!bus) {
+/* qbus_find already reported the error */
+return NULL;
+}
+}
+dev = qbus_find_dev(bus, dev_name);
+if (!dev) {
+dev = qdev_find_id_recursive(main_system_bus, path);
+if (!dev) {
+qerror_report(QERR_DEVICE_NOT_FOUND, dev_name);
+if (!monitor_cur_is_qmp()) {
+qbus_list_dev(bus);
+}
+}
+}
+return dev;
+}
+
void qbus_create_inplace(BusState *bus, BusInfo *info,
DeviceState *parent, const char *name)
{
@@ -824,12 +861,12 @@ int do_device_add(Monitor *mon, const QDict *qdict,
QObject **ret_data)
int do_device_del(Monitor *mon, const QDict *qdict, QObject **ret_data)
{
-const char *id = qdict_get_str(qdict, "id");
+const char *path = qdict_get_str(qdict, "path");
DeviceState *dev;
-dev = qdev_find_recursive(main_system_bus, id);
-if (NULL == dev) {
-qerror_report(QERR_DEVICE_NOT_FOUND, id);
+dev = qdev_find(path);
+if (!dev) {
+qerror_report(QERR_DEVICE_NOT_FOUND, path);
return -1;
}
return qdev_unplug(dev);
diff --git a/qemu-monitor.hx b/qemu-monitor.hx
index c8f1789..754d71e 100644
--- a/qemu-monitor.hx
+++ b/qemu-monitor.hx
@@ -703,7 +703,7 @@ EQMP
{
.name = "device_del",
-.args_type = "id:s",
+.args_type = "path:s",
.params = "device",
.help = "remove device",
.user_print = monitor_user_noop,
@@ -711,10 +711,10 @@ EQMP
},
STEXI
-...@item device_del @var{id}
+...@item device_del @var{path}
@findex device_del
-Remove device @var{id}.
+Remove device @var{path}.
ETEXI
SQMP
device_del
@@ -724,11 +724,11 @@ Remove a device.
Arguments:
-- "id": the device's ID (json-string)
+- "path": the device's qtree path or unique ID (json-string)
Example:
--> { "execute": "device_del", "arguments": { "id": "net1" } }
+-> { "execute": "device_del", "arguments": { "path": "net1" } }
<- { "return": {} }
EQMP
--
1.6.0.2
[Qemu-devel] [PATCH v3 13/17] monitor: Allow to exclude commands from QMP
From: Jan Kiszka
Ported commands that are marked 'user_only' will not be considered for
QMP monitor sessions. This allows to implement new commands that do not
(yet) provide a sufficiently stable interface for QMP use (e.g.
device_show).
Signed-off-by: Jan Kiszka
---
monitor.c | 13 ++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/monitor.c b/monitor.c
index 6766e49..5768c6e 100644
--- a/monitor.c
+++ b/monitor.c
@@ -114,6 +114,7 @@ typedef struct mon_cmd_t {
MonitorCompletion *cb, void *opaque);
} mhandler;
int async;
+bool user_only;
} mon_cmd_t;
/* file descriptors passed via SCM_RIGHTS */
@@ -635,6 +636,11 @@ static int do_info(Monitor *mon, const QDict *qdict,
QObject **ret_data)
goto help;
}
+if (monitor_ctrl_mode(mon) && cmd->user_only) {
+qerror_report(QERR_COMMAND_NOT_FOUND, item);
+return -1;
+}
+
if (monitor_handler_is_async(cmd)) {
if (monitor_ctrl_mode(mon)) {
qmp_async_info_handler(mon, cmd);
@@ -732,13 +738,14 @@ static void do_info_commands(Monitor *mon, QObject
**ret_data)
cmd_list = qlist_new();
for (cmd = mon_cmds; cmd->name != NULL; cmd++) {
-if (monitor_handler_ported(cmd) && !compare_cmd(cmd->name, "info")) {
+if (monitor_handler_ported(cmd) && !cmd->user_only &&
+!compare_cmd(cmd->name, "info")) {
qlist_append_obj(cmd_list, get_cmd_dict(cmd->name));
}
}
for (cmd = info_cmds; cmd->name != NULL; cmd++) {
-if (monitor_handler_ported(cmd)) {
+if (monitor_handler_ported(cmd) && !cmd->user_only) {
char buf[128];
snprintf(buf, sizeof(buf), "query-%s", cmd->name);
qlist_append_obj(cmd_list, get_cmd_dict(buf));
@@ -4416,7 +4423,7 @@ static void handle_qmp_command(JSONMessageParser *parser,
QList *tokens)
qobject_from_jsonf("{ 'item': %s }", info_item));
} else {
cmd = monitor_find_command(cmd_name);
-if (!cmd || !monitor_handler_ported(cmd)) {
+if (!cmd || !monitor_handler_ported(cmd) || cmd->user_only) {
qerror_report(QERR_COMMAND_NOT_FOUND, cmd_name);
goto err_input;
}
--
1.6.0.2
[Qemu-devel] [PATCH v3 02/17] qdev: Fix scanning across single-bus devices
From: Jan Kiszka
As long as we allow /dev.1 as shortcut for /dev1/bus1, we also have to
make sure that /dev1/dev2 works for /dev1/bus1/dev2/bus2 - as long as
there is only one child bus per device.
Signed-off-by: Jan Kiszka
---
docs/qdev-device-use.txt |4
hw/qdev.c| 12 +++-
2 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/docs/qdev-device-use.txt b/docs/qdev-device-use.txt
index f252c8e..9ac1fa1 100644
--- a/docs/qdev-device-use.txt
+++ b/docs/qdev-device-use.txt
@@ -20,6 +20,10 @@ bus named pci.0. To put a FOO device into its slot 4, use
-device
FOO,bus=/i440FX-pcihost/pci.0,addr=4. The abbreviated form bus=pci.0
also works as long as the bus name is unique.
+Furthermore, if a device only hosts a single bus, the bus name can be
+omitted in the path. Example: /i440FX-pcihost/PIIX3 abbreviates
+/i440FX-pcihost/pci.0/PIIX3/isa.0 as none of the buses has siblings.
+
Note: the USB device address can't be controlled at this time.
=== Block Devices ===
diff --git a/hw/qdev.c b/hw/qdev.c
index aa2ce01..2e50531 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -557,7 +557,7 @@ static DeviceState *qbus_find_dev(BusState *bus, char *elem)
static BusState *qbus_find(const char *path)
{
-DeviceState *dev;
+DeviceState *dev, *next_dev;
BusState *bus;
char elem[128];
int pos, len;
@@ -603,6 +603,7 @@ static BusState *qbus_find(const char *path)
return NULL;
}
+search_dev_bus:
assert(path[pos] == '/' || !path[pos]);
while (path[pos] == '/') {
pos++;
@@ -633,6 +634,15 @@ static BusState *qbus_find(const char *path)
pos += len;
bus = qbus_find_bus(dev, elem);
if (!bus) {
+if (dev->num_child_bus == 1) {
+/* Last element might have been a short-cut to a device on
+ * the single child bus of the parent device. */
+next_dev = qbus_find_dev(QTAILQ_FIRST(&dev->child_bus), elem);
+if (next_dev) {
+dev = next_dev;
+goto search_dev_bus;
+}
+}
qerror_report(QERR_BUS_NOT_FOUND, elem);
if (!monitor_cur_is_qmp()) {
qbus_list_bus(dev);
--
1.6.0.2
[Qemu-devel] [PATCH v3 00/17] Basic device state visualization
And here is v3. Dependencies remained, the changes are: - disabled device_show for QMP use (due to protocol instability) - reordered device tree path search: user-assigned ID comes last now - added vmstate version-id to device_show output - base64 cleanups according to review comments - fixed an off-by-one in the qmp.py changes Git url remained the same: git://git.kiszka.org/qemu.git queues/device-show Thanks again for the comments. Jan Kiszka (17): Add dependency of JSON unit tests on config-host.h qdev: Fix scanning across single-bus devices qdev: Allow device addressing via 'driver.instance' qdev: Give qtree names precedence over user-assigned IDs qdev: Convert device and bus lists to QTAILQ qdev: Allow device specification by qtree path for device_del qdev: Push QMP mode checks into qbus_list_bus/dev monitor: Add completion for qdev paths Add base64 encoder/decoder QMP: Reserve namespace for complex object classes Add QBuffer monitor: return length of printed string via monitor_[v]printf monitor: Allow to exclude commands from QMP monitor: Add basic device state visualization QMP: Teach basic capability negotiation to python example QMP: Fix python helper /wrt long return strings QMP: Add support for buffer class to qmp python helper Makefile |5 +- Makefile.objs|4 +- QMP/qmp-shell|1 + QMP/qmp-spec.txt | 24 +++- QMP/qmp.py | 29 +++- QMP/vm-info |1 + base64.c | 202 ++ base64.h | 19 ++ check-qbuffer.c | 172 +++ configure|2 +- docs/qdev-device-use.txt | 20 ++- hw/acpi_piix4.c |2 +- hw/hw.h |2 + hw/i2c.c |2 +- hw/pci-hotplug.c |2 +- hw/qdev.c| 414 - hw/qdev.h| 12 +- hw/ssi.c |6 +- monitor.c| 121 -- monitor.h|4 +- qbuffer.c| 116 + qbuffer.h| 33 qemu-monitor.hx | 29 +++- qemu-tool.c |6 +- qerror.c |4 + qerror.h |3 + qjson.c | 15 ++ qobject.h|1 + 28 files changed, 1165 insertions(+), 86 deletions(-) create mode 100644 base64.c create mode 100644 base64.h create mode 100644 check-qbuffer.c create mode 100644 qbuffer.c create mode 100644 qbuffer.h
[Qemu-devel] [Bug 584516] [NEW] opensuse 11.2 guest hangs after live migration with clocksource=kvm-clock
Public bug reported: i would like to debug a problem that I encountered some time ago with opensuse 11.2 and also with Ubuntu (karmic/lucid). If I run an opensuse guest 64-bit and do not touch the clocksource settings the guest almost everytime hangs after live migration at: (gdb) thread apply all bt Thread 2 (Thread 0x7f846782a950 (LWP 27356)): #0 0x7f8467d24cd7 in ioctl () from /lib/libc.so.6 #1 0x0042b945 in kvm_run (env=0x2468170) at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:921 #2 0x0042cea2 in kvm_cpu_exec (env=0x2468170) at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1651 #3 0x0042d62c in kvm_main_loop_cpu (env=0x2468170) at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1893 #4 0x0042d76d in ap_main_loop (_env=0x2468170) at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1943 #5 0x7f8468caa3ba in start_thread () from /lib/libpthread.so.0 #6 0x7f8467d2cfcd in clone () from /lib/libc.so.6 #7 0x in ?? () Thread 1 (Thread 0x7f84692d96f0 (LWP 27353)): #0 0x7f8467d25742 in select () from /lib/libc.so.6 #1 0x0040c25a in main_loop_wait (timeout=1000) at /usr/src/qemu-kvm-0.12.4/vl.c:3994 #2 0x0042dcf1 in kvm_main_loop () at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:2126 #3 0x0040c98c in main_loop () at /usr/src/qemu-kvm-0.12.4/vl.c:4212 #4 0x0041054b in main (argc=31, argv=0x7fffa91351c8, envp=0x7fffa91352c8) at /usr/src/qemu-kvm-0.12.4/vl.c:6252 If I run the same guest with kernel parameter clocksource=acpi_pm, the migration succeeds reliably. The hosts runs: /kernel: /2.6.33.3, /bin: /qemu-kvm-0.12.4, /mod: /2.6.33.3 I invoke qemu-kvm with: /usr/bin/qemu-kvm-0.12.4 -net none -drive file=/dev/sdb,if=ide,boot=on,cache=none,aio=native -m 1024 -cpu qemu64,model_id='Intel(R) Xeon(R) CPU E5430 @ 2.66GHz' -monitor tcp:0:4001,server,nowait -vnc :1 -name 'test' -boot order=dc,menu=on -k de -pidfile /var/run/qemu/vm-149.pid -mem-path /hugepages -mem-prealloc -rtc base=utc,clock=vm -usb -usbdevice tablet The Guest is: OpenSuse 11.2 64-bit with Kernel 2.6.31.5-0.1-desktop #1 SMP PREEMPT 2009-10-26 15:49:03 +0100 x86_64 The clocksource automatically choosen is kvm-clock. Feedback appreciated. I have observed the same problem with 0.12.2 and also with old binaries provided by Ubuntu Karmic (kvm-88). ** Affects: qemu Importance: Undecided Status: New ** Tags: kvm-clock migration qemu-kvm -- opensuse 11.2 guest hangs after live migration with clocksource=kvm-clock https://bugs.launchpad.net/bugs/584516 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: i would like to debug a problem that I encountered some time ago with opensuse 11.2 and also with Ubuntu (karmic/lucid). If I run an opensuse guest 64-bit and do not touch the clocksource settings the guest almost everytime hangs after live migration at: (gdb) thread apply all bt Thread 2 (Thread 0x7f846782a950 (LWP 27356)): #0 0x7f8467d24cd7 in ioctl () from /lib/libc.so.6 #1 0x0042b945 in kvm_run (env=0x2468170) at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:921 #2 0x0042cea2 in kvm_cpu_exec (env=0x2468170) at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1651 #3 0x0042d62c in kvm_main_loop_cpu (env=0x2468170) at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1893 #4 0x0042d76d in ap_main_loop (_env=0x2468170) at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1943 #5 0x7f8468caa3ba in start_thread () from /lib/libpthread.so.0 #6 0x7f8467d2cfcd in clone () from /lib/libc.so.6 #7 0x in ?? () Thread 1 (Thread 0x7f84692d96f0 (LWP 27353)): #0 0x7f8467d25742 in select () from /lib/libc.so.6 #1 0x0040c25a in main_loop_wait (timeout=1000) at /usr/src/qemu-kvm-0.12.4/vl.c:3994 #2 0x0042dcf1 in kvm_main_loop () at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:2126 #3 0x0040c98c in main_loop () at /usr/src/qemu-kvm-0.12.4/vl.c:4212 #4 0x0041054b in main (argc=31, argv=0x7fffa91351c8, envp=0x7fffa91352c8) at /usr/src/qemu-kvm-0.12.4/vl.c:6252 If I run the same guest with kernel parameter clocksource=acpi_pm, the migration succeeds reliably. The hosts runs: /kernel: /2.6.33.3, /bin: /qemu-kvm-0.12.4, /mod: /2.6.33.3 I invoke qemu-kvm with: /usr/bin/qemu-kvm-0.12.4 -net none -drive file=/dev/sdb,if=ide,boot=on,cache=none,aio=native -m 1024 -cpu qemu64,model_id='Intel(R) Xeon(R) CPU E5430 @ 2.66GHz' -monitor tcp:0:4001,server,nowait -vnc :1 -name 'test' -boot order=dc,menu=on -k de -pidfile /var/run/qemu/vm-149.pid -mem-path /hugepages -mem-prealloc -rtc base=utc,clock=vm -usb -usbdevice tablet The Guest is: OpenSuse 11.2 64-bit with Kernel 2.6.31.5-0.1-desktop #1 SMP PREEMPT 2009-10-26 15:49:03 +0100 x86_64 The clocksource automatically choosen is kvm-clock. Feedback appreciated. I have observed the same problem with 0.12.2 and also with old bin
Re: [Qemu-devel] Re: irq problems after live migration with 0.12.4
Am 23.05.2010 um 12:38 schrieb Michael Tokarev: > 23.05.2010 13:55, Peter Lieven wrote: >> Hi, >> >> after live migrating ubuntu 9.10 server (2.6.31-14-server) and suse linux >> 10.1 (2.6.16.13-4-smp) >> it happens sometimes that the guest runs into irq problems. i mention these >> 2 guest oss >> since i have seen the error there. there are likely others around with the >> same problem. >> >> on the host i run 2.6.33.3 (kernel+mod) and qemu-kvm 0.12.4. >> >> i started a vm with: >> /usr/bin/qemu-kvm-0.12.4 -net >> tap,vlan=141,script=no,downscript=no,ifname=tap0 -net >> nic,vlan=141,model=e1000,macaddr=52:54:00:ff:00:72 -drive >> file=/dev/sdb,if=ide,boot=on,cache=none,aio=native -m 1024 -cpu >> qemu64,model_id='Intel(R) Xeon(R) CPU E5430 @ 2.66GHz' -monitor >> tcp:0:4001,server,nowait -vnc :1 -name 'migration-test-9-10' -boot >> order=dc,menu=on -k de -incoming tcp:172.21.55.22:5001 -pidfile >> /var/run/qemu/vm-155.pid -mem-path /hugepages -mem-prealloc -rtc >> base=utc,clock=host -usb -usbdevice tablet >> >> for testing i have a clean ubuntu 9.10 server 64-bit install and created a >> small script with fetches a dvd iso from a local server and checking md5sum >> in an endless loop. >> >> the download performance is approx. 50MB/s on that vm. >> >> to trigger the error i did several migrations of the vm throughout the last >> days. finally I ended up in the following oops in the guest: >> >> [64442.298521] irq 10: nobody cared (try booting with the "irqpoll" option) >> [64442.299175] Pid: 0, comm: swapper Not tainted 2.6.31-14-server #48-Ubuntu >> [64442.299179] Call Trace: >> [64442.299185] [] __report_bad_irq+0x26/0xa0 >> [64442.299227] [] note_interrupt+0x18c/0x1d0 >> [64442.299232] [] handle_fasteoi_irq+0xd5/0x100 >> [64442.299244] [] handle_irq+0x1d/0x30 >> [64442.299246] [] do_IRQ+0x67/0xe0 >> [64442.299249] [] ret_from_intr+0x0/0x11 >> [64442.299266] [] ? handle_IRQ_event+0x24/0x160 >> [64442.299269] [] ? handle_edge_irq+0xcf/0x170 >> [64442.299271] [] ? handle_irq+0x1d/0x30 >> [64442.299273] [] ? do_IRQ+0x67/0xe0 >> [64442.299275] [] ? ret_from_intr+0x0/0x11 >> [64442.299290] [] ? _spin_unlock_irqrestore+0x14/0x20 >> [64442.299302] [] ? scsi_dispatch_cmd+0x16c/0x2d0 >> [64442.299307] [] ? scsi_request_fn+0x3aa/0x500 >> [64442.299322] [] ? __blk_run_queue+0x6c/0x150 >> [64442.299324] [] ? blk_run_queue+0x2b/0x50 >> [64442.299327] [] ? scsi_run_queue+0xcf/0x2a0 >> [64442.299336] [] ? scsi_next_command+0x3d/0x60 >> [64442.299338] [] ? scsi_end_request+0xab/0xb0 >> [64442.299340] [] ? scsi_io_completion+0x9e/0x4d0 >> [64442.299348] [] ? default_spin_lock_flags+0x9/0x10 >> [64442.299351] [] ? scsi_finish_command+0xbd/0x130 >> [64442.299353] [] ? scsi_softirq_done+0x145/0x170 >> [64442.299356] [] ? blk_done_softirq+0x7d/0x90 >> [64442.299368] [] ? __do_softirq+0xbd/0x200 >> [64442.299370] [] ? call_softirq+0x1c/0x30 >> [64442.299372] [] ? do_softirq+0x55/0x90 >> [64442.299374] [] ? irq_exit+0x85/0x90 >> [64442.299376] [] ? do_IRQ+0x70/0xe0 >> [64442.299379] [] ? ret_from_intr+0x0/0x11 >> [64442.299380] [] ? native_safe_halt+0x6/0x10 >> [64442.299390] [] ? default_idle+0x4c/0xe0 >> [64442.299395] [] ? atomic_notifier_call_chain+0x15/0x20 >> [64442.299398] [] ? cpu_idle+0xb2/0x100 >> [64442.299406] [] ? rest_init+0x66/0x70 >> [64442.299424] [] ? start_kernel+0x352/0x35b >> [64442.299427] [] ? x86_64_start_reservations+0x125/0x129 >> [64442.299429] [] ? x86_64_start_kernel+0xfa/0x109 >> [64442.299433] handlers: >> [64442.299840] [] (e1000_intr+0x0/0x190 [e1000]) >> [64442.300046] Disabling IRQ #10 > > See also LP bug #584131 (https://bugs.launchpad.net/bugs/584131) > and original Debian bug#580649 (http://bugs.debian.org/580649) > > Not sure if they're related... > > /mjt > > hi, thanks for the pointer. i have seen them. the reporters of these bugs think that the bug is caused by the virtio subsystem. at least the debian bug reporter says it does not occur with virtio disabled. here is no virtio involved. but, of course the cause could be the same. i have a test platform here and i'm willing to make any modifications to kernel, kvm-kmod, qemu-kvm or guest kernel to debug the problem. peter
[Qemu-devel] Re: [PATCH v2 12/15] monitor: Add basic device state visualization
On 05/23/2010 01:03 PM, Jan Kiszka wrote: Can your elaborate what precisely is ambiguous? Can't the user choose the unique ID so that it aliases an unrelated qtree path? True. I'll swap the search order and document this. Qtree paths should always rule. Well, I guess the user could avoid ambiguity by avoiding /es. I prefer having mutually exclusive 'path' and 'ref' arguments. That would be unhandy. Don't really see why. I agree. This feature is very useful as a debugging aid, and as I don't think we'll have debugging GUIs any time soon, it's better to defer the problem until we really need to solve it. I introduced .user_only as a monitor command tag and applied it on device_show. But I also added the vmstate version to the device output, maybe already helpful for users. All this will come with v3. Thanks. -- error compiling committee.c: too many arguments to function
[Qemu-devel] [Bug 584514] [NEW] Qemu-KVM 0.12.4 Guest entered Paused State
Public bug reported: I recently had a 0.12.4 qemu-kvm with a debian lenny guest which occasionally paused. There was no memory exhaustion as suggested earlier. qemu-kvm send the following output:: VM internal error. Suberror: 1 rax 0100 rbx 880017585bc0 rcx 7f84c6d5b000 rdx 0001 rsi rdi 88001d322dec rsp 88001e133e88 rbp 88001e133e88 r8 01f25bc2 r9 0007 r10 7f84c6b4d97b r11 0206 r12 88001d322dec r13 88001d322de8 r14 0001 r15 rip 81039719 rflags 00010092 cs 0010 (/ p 1 dpl 0 db 0 s 1 type b l 1 g 1 avl 0) ds (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) es (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) ss 0018 (/ p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) fs (7f84c6d53700/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) gs (880001d0/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) tr 0040 (880001d13780/2087 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) ldt (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) gdt 880001d04000/7f idt 8195e000/fff cr0 80050033 cr2 7f84c6b38ec8 cr3 1db7d000 cr4 6e0 cr8 0 efer 501 emulation failure, check dmesg for details Unfortunately, I found nothing in syslog or dmesg ** Affects: qemu Importance: Undecided Status: New ** Tags: qemu-kvm -- Qemu-KVM 0.12.4 Guest entered Paused State https://bugs.launchpad.net/bugs/584514 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: I recently had a 0.12.4 qemu-kvm with a debian lenny guest which occasionally paused. There was no memory exhaustion as suggested earlier. qemu-kvm send the following output:: VM internal error. Suberror: 1 rax 0100 rbx 880017585bc0 rcx 7f84c6d5b000 rdx 0001 rsi rdi 88001d322dec rsp 88001e133e88 rbp 88001e133e88 r8 01f25bc2 r9 0007 r10 7f84c6b4d97b r11 0206 r12 88001d322dec r13 88001d322de8 r14 0001 r15 rip 81039719 rflags 00010092 cs 0010 (/ p 1 dpl 0 db 0 s 1 type b l 1 g 1 avl 0) ds (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) es (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) ss 0018 (/ p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) fs (7f84c6d53700/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) gs (880001d0/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) tr 0040 (880001d13780/2087 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) ldt (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) gdt 880001d04000/7f idt 8195e000/fff cr0 80050033 cr2 7f84c6b38ec8 cr3 1db7d000 cr4 6e0 cr8 0 efer 501 emulation failure, check dmesg for details Unfortunately, I found nothing in syslog or dmesg
[Qemu-devel] Re: irq problems after live migration with 0.12.4
23.05.2010 13:55, Peter Lieven wrote: Hi, after live migrating ubuntu 9.10 server (2.6.31-14-server) and suse linux 10.1 (2.6.16.13-4-smp) it happens sometimes that the guest runs into irq problems. i mention these 2 guest oss since i have seen the error there. there are likely others around with the same problem. on the host i run 2.6.33.3 (kernel+mod) and qemu-kvm 0.12.4. i started a vm with: /usr/bin/qemu-kvm-0.12.4 -net tap,vlan=141,script=no,downscript=no,ifname=tap0 -net nic,vlan=141,model=e1000,macaddr=52:54:00:ff:00:72 -drive file=/dev/sdb,if=ide,boot=on,cache=none,aio=native -m 1024 -cpu qemu64,model_id='Intel(R) Xeon(R) CPU E5430 @ 2.66GHz' -monitor tcp:0:4001,server,nowait -vnc :1 -name 'migration-test-9-10' -boot order=dc,menu=on -k de -incoming tcp:172.21.55.22:5001 -pidfile /var/run/qemu/vm-155.pid -mem-path /hugepages -mem-prealloc -rtc base=utc,clock=host -usb -usbdevice tablet for testing i have a clean ubuntu 9.10 server 64-bit install and created a small script with fetches a dvd iso from a local server and checking md5sum in an endless loop. the download performance is approx. 50MB/s on that vm. to trigger the error i did several migrations of the vm throughout the last days. finally I ended up in the following oops in the guest: [64442.298521] irq 10: nobody cared (try booting with the "irqpoll" option) [64442.299175] Pid: 0, comm: swapper Not tainted 2.6.31-14-server #48-Ubuntu [64442.299179] Call Trace: [64442.299185] [] __report_bad_irq+0x26/0xa0 [64442.299227] [] note_interrupt+0x18c/0x1d0 [64442.299232] [] handle_fasteoi_irq+0xd5/0x100 [64442.299244] [] handle_irq+0x1d/0x30 [64442.299246] [] do_IRQ+0x67/0xe0 [64442.299249] [] ret_from_intr+0x0/0x11 [64442.299266] [] ? handle_IRQ_event+0x24/0x160 [64442.299269] [] ? handle_edge_irq+0xcf/0x170 [64442.299271] [] ? handle_irq+0x1d/0x30 [64442.299273] [] ? do_IRQ+0x67/0xe0 [64442.299275] [] ? ret_from_intr+0x0/0x11 [64442.299290] [] ? _spin_unlock_irqrestore+0x14/0x20 [64442.299302] [] ? scsi_dispatch_cmd+0x16c/0x2d0 [64442.299307] [] ? scsi_request_fn+0x3aa/0x500 [64442.299322] [] ? __blk_run_queue+0x6c/0x150 [64442.299324] [] ? blk_run_queue+0x2b/0x50 [64442.299327] [] ? scsi_run_queue+0xcf/0x2a0 [64442.299336] [] ? scsi_next_command+0x3d/0x60 [64442.299338] [] ? scsi_end_request+0xab/0xb0 [64442.299340] [] ? scsi_io_completion+0x9e/0x4d0 [64442.299348] [] ? default_spin_lock_flags+0x9/0x10 [64442.299351] [] ? scsi_finish_command+0xbd/0x130 [64442.299353] [] ? scsi_softirq_done+0x145/0x170 [64442.299356] [] ? blk_done_softirq+0x7d/0x90 [64442.299368] [] ? __do_softirq+0xbd/0x200 [64442.299370] [] ? call_softirq+0x1c/0x30 [64442.299372] [] ? do_softirq+0x55/0x90 [64442.299374] [] ? irq_exit+0x85/0x90 [64442.299376] [] ? do_IRQ+0x70/0xe0 [64442.299379] [] ? ret_from_intr+0x0/0x11 [64442.299380] [] ? native_safe_halt+0x6/0x10 [64442.299390] [] ? default_idle+0x4c/0xe0 [64442.299395] [] ? atomic_notifier_call_chain+0x15/0x20 [64442.299398] [] ? cpu_idle+0xb2/0x100 [64442.299406] [] ? rest_init+0x66/0x70 [64442.299424] [] ? start_kernel+0x352/0x35b [64442.299427] [] ? x86_64_start_reservations+0x125/0x129 [64442.299429] [] ? x86_64_start_kernel+0xfa/0x109 [64442.299433] handlers: [64442.299840] [] (e1000_intr+0x0/0x190 [e1000]) [64442.300046] Disabling IRQ #10 See also LP bug #584131 (https://bugs.launchpad.net/bugs/584131) and original Debian bug#580649 (http://bugs.debian.org/580649) Not sure if they're related... /mjt
Re: [Qemu-devel] Re: qemu-kvm hangs if multipath device is queing
Am 19.05.2010 um 10:18 schrieb Peter Lieven: > Kevin Wolf wrote: >> Am 19.05.2010 09:29, schrieb Christoph Hellwig: >> >>> On Tue, May 18, 2010 at 03:22:36PM +0200, Kevin Wolf wrote: >>> I think it's stuck here in an endless loop: while (laiocb->ret == -EINPROGRESS) qemu_laio_completion_cb(laiocb->ctx); Can you verify this by single-stepping one or two loop iterations? ret and errno after the read call could be interesting, too. >>> Maybe the compiler is just too smart. Without some form of barrier >>> it could just optimize the loop away as laiocb->ret couldn't change >>> in a normal single-threaded environment. >>> >> >> It probably could in theory, but in practice we're in a read() inside >> qemu_laio_completion, so it didn't do it here. >> > if you supply a patch that will add some usleeps at the point in > question i'm willing to test if it solves the 100% cpu problem. can someone help here? what would be the best option to add some usleeps? >> Kevin >> >> > > >
[Qemu-devel] [Bug 584510] [NEW] e1000 irq problems after live migration with qemu-kvm 0.12.4
Public bug reported: After live migrating ubuntu 9.10 server (2.6.31-14-server) and suse linux 10.1 (2.6.16.13-4-smp) it happens sometimes that the guest runs into irq problems. i mention these 2 guest oss since i have seen the error there. there are likely others around with the same problem. on the host i run 2.6.33.3 (kernel+mod) and qemu-kvm 0.12.4. i started a vm with: /usr/bin/qemu-kvm-0.12.4 -net tap,vlan=141,script=no,downscript=no,ifname=tap0 -net nic,vlan=141,model=e1000,macaddr=52:54:00:ff:00:72 -drive file=/dev/sdb,if=ide,boot=on,cache=none,aio=native -m 1024 -cpu qemu64,model_id='Intel(R) Xeon(R) CPU E5430 @ 2.66GHz' -monitor tcp:0:4001,server,nowait -vnc :1 -name 'migration-test-9-10' -boot order=dc,menu=on -k de -incoming tcp:172.21.55.22:5001 -pidfile /var/run/qemu/vm-155.pid -mem-path /hugepages -mem-prealloc -rtc base=utc,clock=host -usb -usbdevice tablet for testing i have a clean ubuntu 9.10 server 64-bit install and created a small script with fetches a dvd iso from a local server and checking md5sum in an endless loop. the download performance is approx. 50MB/s on that vm. to trigger the error i did several migrations of the vm throughout the last days. finally I ended up in the following oops in the guest: [64442.298521] irq 10: nobody cared (try booting with the "irqpoll" option) [64442.299175] Pid: 0, comm: swapper Not tainted 2.6.31-14-server #48-Ubuntu [64442.299179] Call Trace: [64442.299185][] __report_bad_irq+0x26/0xa0 [64442.299227] [] note_interrupt+0x18c/0x1d0 [64442.299232] [] handle_fasteoi_irq+0xd5/0x100 [64442.299244] [] handle_irq+0x1d/0x30 [64442.299246] [] do_IRQ+0x67/0xe0 [64442.299249] [] ret_from_intr+0x0/0x11 [64442.299266] [] ? handle_IRQ_event+0x24/0x160 [64442.299269] [] ? handle_edge_irq+0xcf/0x170 [64442.299271] [] ? handle_irq+0x1d/0x30 [64442.299273] [] ? do_IRQ+0x67/0xe0 [64442.299275] [] ? ret_from_intr+0x0/0x11 [64442.299290] [] ? _spin_unlock_irqrestore+0x14/0x20 [64442.299302] [] ? scsi_dispatch_cmd+0x16c/0x2d0 [64442.299307] [] ? scsi_request_fn+0x3aa/0x500 [64442.299322] [] ? __blk_run_queue+0x6c/0x150 [64442.299324] [] ? blk_run_queue+0x2b/0x50 [64442.299327] [] ? scsi_run_queue+0xcf/0x2a0 [64442.299336] [] ? scsi_next_command+0x3d/0x60 [64442.299338] [] ? scsi_end_request+0xab/0xb0 [64442.299340] [] ? scsi_io_completion+0x9e/0x4d0 [64442.299348] [] ? default_spin_lock_flags+0x9/0x10 [64442.299351] [] ? scsi_finish_command+0xbd/0x130 [64442.299353] [] ? scsi_softirq_done+0x145/0x170 [64442.299356] [] ? blk_done_softirq+0x7d/0x90 [64442.299368] [] ? __do_softirq+0xbd/0x200 [64442.299370] [] ? call_softirq+0x1c/0x30 [64442.299372] [] ? do_softirq+0x55/0x90 [64442.299374] [] ? irq_exit+0x85/0x90 [64442.299376] [] ? do_IRQ+0x70/0xe0 [64442.299379] [] ? ret_from_intr+0x0/0x11 [64442.299380][] ? native_safe_halt+0x6/0x10 [64442.299390] [] ? default_idle+0x4c/0xe0 [64442.299395] [] ? atomic_notifier_call_chain+0x15/0x20 [64442.299398] [] ? cpu_idle+0xb2/0x100 [64442.299406] [] ? rest_init+0x66/0x70 [64442.299424] [] ? start_kernel+0x352/0x35b [64442.299427] [] ? x86_64_start_reservations+0x125/0x129 [64442.299429] [] ? x86_64_start_kernel+0xfa/0x109 [64442.299433] handlers: [64442.299840] [] (e1000_intr+0x0/0x190 [e1000]) [64442.300046] Disabling IRQ #10 After this the guest is still allive, but download performance is down to approx. 500KB/s This error is definetly not triggerable with option -no-kvm-irqchip. I have seen this error occasionally since my first experiments with qemu-kvm-88 and also without hugetablefs. Help appreciated. ** Affects: qemu Importance: Undecided Status: New ** Tags: e1000 irq migration qemu-kvm -- e1000 irq problems after live migration with qemu-kvm 0.12.4 https://bugs.launchpad.net/bugs/584510 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: After live migrating ubuntu 9.10 server (2.6.31-14-server) and suse linux 10.1 (2.6.16.13-4-smp) it happens sometimes that the guest runs into irq problems. i mention these 2 guest oss since i have seen the error there. there are likely others around with the same problem. on the host i run 2.6.33.3 (kernel+mod) and qemu-kvm 0.12.4. i started a vm with: /usr/bin/qemu-kvm-0.12.4 -net tap,vlan=141,script=no,downscript=no,ifname=tap0 -net nic,vlan=141,model=e1000,macaddr=52:54:00:ff:00:72 -drive file=/dev/sdb,if=ide,boot=on,cache=none,aio=native -m 1024 -cpu qemu64,model_id='Intel(R) Xeon(R) CPU E5430 @ 2.66GHz' -monitor tcp:0:4001,server,nowait -vnc :1 -name 'migration-test-9-10' -boot order=dc,menu=on -k de -incoming tcp:172.21.55.22:5001 -pidfile /var/run/qemu/vm-155.pid -mem-path /hugepages -mem-prealloc -rtc base=utc,clock=host -usb -usbdevice tablet for testing i have a clean ubuntu 9.10 server 64-bit install and created a small script with fetche
Re: [Qemu-devel] [PATCH v2 08/15] Add base64 encoder/decoder
Avi Kivity wrote: > On 05/23/2010 10:55 AM, Jan Kiszka wrote: +/* + * Convert string 'src' of length 'srclen' from base64 to binary form, + * saving the result in 'dest'. The size of the destination buffer must be at + * least srclen * 3 / 4. + * + * Returns 0 on success, -1 on conversion error. + */ +int base64_decode(const char *src, size_t srclen, void *dest) >>> I think dest should be char *, like all the functions where dest is >>> passed to. >>> >> The output may but need not be a string, it's binary data. And to avoid >> needless warnings about signedness mismatches if unsigned char or >> uint8_t buffers are passed, I chose void *. >> > > I think qemu is pretty consistent in using uint8_t for binary, and void > * is a little dangerous as it allows passing any kind of data (anything > above a byte is subject to endianness issues for example). > > But I don't feel strongly about this. > Let's go for consistency: I switched to uint8_t for the binary input/output. Jan signature.asc Description: OpenPGP digital signature
[Qemu-devel] Re: [PATCH v2 12/15] monitor: Add basic device state visualization
Avi Kivity wrote:
> On 05/23/2010 10:57 AM, Jan Kiszka wrote:
>> Avi Kivity wrote:
>>
>>> On 05/22/2010 11:18 AM, Jan Kiszka wrote:
>>>
From: Jan Kiszka
This introduces device_show, a monitor command that saves the
vmstate of
a qdev device and visualizes it. QMP is also supported. Buffers are cut
after 16 byte by default, but the full content can be requested via
'-f'. To pretty-print sub-arrays, vmstate is extended to store the
start
index name. A new qerror is introduced to signal a missing vmstate. And
it comes with documentation.
+
+Dump a snapshot of the device state. Buffers are cut after 16 bytes
unless
+a full dump is requested.
+
+Arguments:
+
+- "path": the device's qtree path or unique ID (json-string)
>>> This may be ambiguous.
>>>
>> Can your elaborate what precisely is ambiguous?
>>
>
> Can't the user choose the unique ID so that it aliases an unrelated
> qtree path?
True. I'll swap the search order and document this. Qtree paths should
always rule.
>
> I prefer having mutually exclusive 'path' and 'ref' arguments.
That would be unhandy.
>
+- "full": report full state (json-bool, optional)
>>> Is this needed for QMP? The client can always truncate it to any
>>> length.
>>>
>> The effect may not be needed for QMP, but I do need this channel from
>> the command line to the monitor pretty-printer. I could just stick
>> "full": json-bool back into the return dict, but that would look somehow
>> strange IMO.
>>
>
> So we could disallow it as a QMP input, but allow it as an HMP input.
>
+
+Schema of returned object:
+
+{ "device": json-string, "id": json-string, "fields" : [
field-objects ] }
+
+The field object array may be empty, otherwise it consists of
+
+{ "name": json-string, "size": json-int, "elems": [ element-objects
] }
+
+"size" describes the real number of bytes required for a binary
representation
+of a single field element in the array. The actually transfered
amount may be
+smaller unless a full dump was requested.
>>> This converts the entire qdev tree into an undocumented stable protocol
>>> (the qdev paths were already in this state I believe). This really
>>> worries me.
>>>
>> Being primarily a debugging tool, device_show exports the entire
>> (qdev'ified) vmstates via QMP. Unlike the migration protocol, it does
>> not provide something like backward compatibility.
>
> Should be explicitly documented. All QMP commands should be backwards
> and forwards compatible unless noted.
>
>> This would be
>> overkill for the intended purpose (though someone may find a different
>> use case one day).
>>
>
> Even for simply showing things, a GUI may depend on the presence of
> certain fields. If we document that the fields may change, a correctly
> written GUI can fall back to a simpler display.
>
>> I think we have the following options:
>> - disable device_show via QMP, limit it to the monitor console
>> - declare its output inherently unstable, maybe at least adding the
>> vmstate version to each device so that potential QMP consumers notice
>> that they may have to update their tools or switch to a different
>> processing function
>>
>> Given that vmstate annotations will most probably require some work on
>> the output structure (and I don't have a QMP use case ATM anyway), I
>> would be fine with the first option for now. Still, I don't think we
>> will ever get beyond the second option because this service is tight to
>> some internals of QEMU we don't want to freeze.
>>
>
> I agree. This feature is very useful as a debugging aid, and as I don't
> think we'll have debugging GUIs any time soon, it's better to defer the
> problem until we really need to solve it.
I introduced .user_only as a monitor command tag and applied it on
device_show. But I also added the vmstate version to the device output,
maybe already helpful for users. All this will come with v3.
Jan
signature.asc
Description: OpenPGP digital signature
[Qemu-devel] irq problems after live migration with 0.12.4
Hi, after live migrating ubuntu 9.10 server (2.6.31-14-server) and suse linux 10.1 (2.6.16.13-4-smp) it happens sometimes that the guest runs into irq problems. i mention these 2 guest oss since i have seen the error there. there are likely others around with the same problem. on the host i run 2.6.33.3 (kernel+mod) and qemu-kvm 0.12.4. i started a vm with: /usr/bin/qemu-kvm-0.12.4 -net tap,vlan=141,script=no,downscript=no,ifname=tap0 -net nic,vlan=141,model=e1000,macaddr=52:54:00:ff:00:72 -drive file=/dev/sdb,if=ide,boot=on,cache=none,aio=native -m 1024 -cpu qemu64,model_id='Intel(R) Xeon(R) CPU E5430 @ 2.66GHz' -monitor tcp:0:4001,server,nowait -vnc :1 -name 'migration-test-9-10' -boot order=dc,menu=on -k de -incoming tcp:172.21.55.22:5001 -pidfile /var/run/qemu/vm-155.pid -mem-path /hugepages -mem-prealloc -rtc base=utc,clock=host -usb -usbdevice tablet for testing i have a clean ubuntu 9.10 server 64-bit install and created a small script with fetches a dvd iso from a local server and checking md5sum in an endless loop. the download performance is approx. 50MB/s on that vm. to trigger the error i did several migrations of the vm throughout the last days. finally I ended up in the following oops in the guest: [64442.298521] irq 10: nobody cared (try booting with the "irqpoll" option) [64442.299175] Pid: 0, comm: swapper Not tainted 2.6.31-14-server #48-Ubuntu [64442.299179] Call Trace: [64442.299185][] __report_bad_irq+0x26/0xa0 [64442.299227] [] note_interrupt+0x18c/0x1d0 [64442.299232] [] handle_fasteoi_irq+0xd5/0x100 [64442.299244] [] handle_irq+0x1d/0x30 [64442.299246] [] do_IRQ+0x67/0xe0 [64442.299249] [] ret_from_intr+0x0/0x11 [64442.299266] [] ? handle_IRQ_event+0x24/0x160 [64442.299269] [] ? handle_edge_irq+0xcf/0x170 [64442.299271] [] ? handle_irq+0x1d/0x30 [64442.299273] [] ? do_IRQ+0x67/0xe0 [64442.299275] [] ? ret_from_intr+0x0/0x11 [64442.299290] [] ? _spin_unlock_irqrestore+0x14/0x20 [64442.299302] [] ? scsi_dispatch_cmd+0x16c/0x2d0 [64442.299307] [] ? scsi_request_fn+0x3aa/0x500 [64442.299322] [] ? __blk_run_queue+0x6c/0x150 [64442.299324] [] ? blk_run_queue+0x2b/0x50 [64442.299327] [] ? scsi_run_queue+0xcf/0x2a0 [64442.299336] [] ? scsi_next_command+0x3d/0x60 [64442.299338] [] ? scsi_end_request+0xab/0xb0 [64442.299340] [] ? scsi_io_completion+0x9e/0x4d0 [64442.299348] [] ? default_spin_lock_flags+0x9/0x10 [64442.299351] [] ? scsi_finish_command+0xbd/0x130 [64442.299353] [] ? scsi_softirq_done+0x145/0x170 [64442.299356] [] ? blk_done_softirq+0x7d/0x90 [64442.299368] [] ? __do_softirq+0xbd/0x200 [64442.299370] [] ? call_softirq+0x1c/0x30 [64442.299372] [] ? do_softirq+0x55/0x90 [64442.299374] [] ? irq_exit+0x85/0x90 [64442.299376] [] ? do_IRQ+0x70/0xe0 [64442.299379] [] ? ret_from_intr+0x0/0x11 [64442.299380][] ? native_safe_halt+0x6/0x10 [64442.299390] [] ? default_idle+0x4c/0xe0 [64442.299395] [] ? atomic_notifier_call_chain+0x15/0x20 [64442.299398] [] ? cpu_idle+0xb2/0x100 [64442.299406] [] ? rest_init+0x66/0x70 [64442.299424] [] ? start_kernel+0x352/0x35b [64442.299427] [] ? x86_64_start_reservations+0x125/0x129 [64442.299429] [] ? x86_64_start_kernel+0xfa/0x109 [64442.299433] handlers: [64442.299840] [] (e1000_intr+0x0/0x190 [e1000]) [64442.300046] Disabling IRQ #10 After this the guest is still allive, but download performance is down to approx. 500KB/s This error is definetly not triggerable with option -no-kvm-irqchip. I have seen this error occasionally since my first experiments with qemu-kvm-88 and also without hugetablefs. Help appreciated. BR, Peter
Re: [Qemu-devel] Suggested Parameters for SLES 10 64-bit
Am 18.05.2010 um 15:51 schrieb Alexander Graf: > Peter Lieven wrote: >> Alexander Graf wrote: >>> Peter Lieven wrote: >>> we are running on intel xeons here: >>> >>> That might be the reason. Does it break when passing -no-kvm? >>> >>> processor: 0 vendor_id: GenuineIntel cpu family: 6 model: 26 model name: Intel(R) Xeon(R) CPU L5530 @ 2.40GHz stepping: 5 cpu MHz: 2394.403 cache size: 8192 KB physical id: 1 siblings: 4 core id: 0 cpu cores: 4 apicid: 16 initial apicid: 16 fpu: yes fpu_exception: yes cpuid level: 11 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology tsc_reliable nonstop_tsc pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid bogomips: 4788.80 clflush size: 64 cache_alignment: 64 address sizes: 40 bits physical, 48 bits virtual power management: kvm-kmod is 2.6.32.7 ... which commandline parameters do you supply to qemu-kvm? >>> >>> None :) >>> >> It seems to stop working if i supply -no-kvm-irqchip. Can you try to >> reproduce this? >> >> We introduced that parameter because we encountered some problems with >> the e1000 kernel driver stopped to work in some >> guests after live migration with a "nobody cared about interupt" (i >> don't know the exact error anymore). supplying >> -no-kvm-irqchip made live migration of these guests possible... >> Sounds that familiar to someone? > > So it works with the in-kernel irqchip? That's the normally supported > configuration anyways. If migration fails with that, that's a different > thing and definitely needs to be addressed. I got the error reproduced in ubuntu 9.10 server 64-bit and Suse Linux 10.1. I will file a seperate report. Peter > > Alex > > >
Re: [Qemu-devel] [PATCH v2 08/15] Add base64 encoder/decoder
On 05/23/2010 10:55 AM, Jan Kiszka wrote: +/* + * Convert string 'src' of length 'srclen' from base64 to binary form, + * saving the result in 'dest'. The size of the destination buffer must be at + * least srclen * 3 / 4. + * + * Returns 0 on success, -1 on conversion error. + */ +int base64_decode(const char *src, size_t srclen, void *dest) I think dest should be char *, like all the functions where dest is passed to. The output may but need not be a string, it's binary data. And to avoid needless warnings about signedness mismatches if unsigned char or uint8_t buffers are passed, I chose void *. I think qemu is pretty consistent in using uint8_t for binary, and void * is a little dangerous as it allows passing any kind of data (anything above a byte is subject to endianness issues for example). But I don't feel strongly about this. -- error compiling committee.c: too many arguments to function
[Qemu-devel] Re: [PATCH v2 12/15] monitor: Add basic device state visualization
On 05/23/2010 10:57 AM, Jan Kiszka wrote:
Avi Kivity wrote:
On 05/22/2010 11:18 AM, Jan Kiszka wrote:
From: Jan Kiszka
This introduces device_show, a monitor command that saves the vmstate of
a qdev device and visualizes it. QMP is also supported. Buffers are cut
after 16 byte by default, but the full content can be requested via
'-f'. To pretty-print sub-arrays, vmstate is extended to store the start
index name. A new qerror is introduced to signal a missing vmstate. And
it comes with documentation.
+
+Dump a snapshot of the device state. Buffers are cut after 16 bytes
unless
+a full dump is requested.
+
+Arguments:
+
+- "path": the device's qtree path or unique ID (json-string)
This may be ambiguous.
Can your elaborate what precisely is ambiguous?
Can't the user choose the unique ID so that it aliases an unrelated
qtree path?
I prefer having mutually exclusive 'path' and 'ref' arguments.
+- "full": report full state (json-bool, optional)
Is this needed for QMP? The client can always truncate it to any length.
The effect may not be needed for QMP, but I do need this channel from
the command line to the monitor pretty-printer. I could just stick
"full": json-bool back into the return dict, but that would look somehow
strange IMO.
So we could disallow it as a QMP input, but allow it as an HMP input.
+
+Schema of returned object:
+
+{ "device": json-string, "id": json-string, "fields" : [
field-objects ] }
+
+The field object array may be empty, otherwise it consists of
+
+{ "name": json-string, "size": json-int, "elems": [ element-objects ] }
+
+"size" describes the real number of bytes required for a binary
representation
+of a single field element in the array. The actually transfered
amount may be
+smaller unless a full dump was requested.
This converts the entire qdev tree into an undocumented stable protocol
(the qdev paths were already in this state I believe). This really
worries me.
Being primarily a debugging tool, device_show exports the entire
(qdev'ified) vmstates via QMP. Unlike the migration protocol, it does
not provide something like backward compatibility.
Should be explicitly documented. All QMP commands should be backwards
and forwards compatible unless noted.
This would be
overkill for the intended purpose (though someone may find a different
use case one day).
Even for simply showing things, a GUI may depend on the presence of
certain fields. If we document that the fields may change, a correctly
written GUI can fall back to a simpler display.
I think we have the following options:
- disable device_show via QMP, limit it to the monitor console
- declare its output inherently unstable, maybe at least adding the
vmstate version to each device so that potential QMP consumers notice
that they may have to update their tools or switch to a different
processing function
Given that vmstate annotations will most probably require some work on
the output structure (and I don't have a QMP use case ATM anyway), I
would be fine with the first option for now. Still, I don't think we
will ever get beyond the second option because this service is tight to
some internals of QEMU we don't want to freeze.
I agree. This feature is very useful as a debugging aid, and as I don't
think we'll have debugging GUIs any time soon, it's better to defer the
problem until we really need to solve it.
--
error compiling committee.c: too many arguments to function
[Qemu-devel] [PATCH] sdl: Do not disable screensaver by default
From: Jan Kiszka
Unless we are running in full-screen mode, QEMU's SDL window should not
disable the host's screensaver. The user can still change this behaviour
by setting the environment variable SDL_VIDEO_ALLOW_SCREENSAVER as
desired.
Signed-off-by: Jan Kiszka
---
Cool, thanks for digging out SDL_VIDEO_ALLOW_SCREENSAVER. I came across
by this issue as well but I was too lazy to analyze to reason. This
patch solves it for me.
sdl.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/sdl.c b/sdl.c
index 16a48e9..3bdd518 100644
--- a/sdl.c
+++ b/sdl.c
@@ -855,6 +855,10 @@ void sdl_display_init(DisplayState *ds, int full_screen,
int no_frame)
if (no_frame)
gui_noframe = 1;
+if (!full_screen) {
+setenv("SDL_VIDEO_ALLOW_SCREENSAVER", "1", 0);
+}
+
flags = SDL_INIT_VIDEO | SDL_INIT_NOPARACHUTE;
if (SDL_Init (flags)) {
fprintf(stderr, "Could not initialize SDL(%s) - exiting\n",
--
1.6.0.2
Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm
On Thu, May 20, 2010 at 11:02 PM, Yehuda Sadeh Weinraub
wrote:
> On Thu, May 20, 2010 at 1:31 PM, Blue Swirl wrote:
>> On Wed, May 19, 2010 at 7:22 PM, Christian Brunner wrote:
>>> The attached patch is a block driver for the distributed file system
>>> Ceph (http://ceph.newdream.net/). This driver uses librados (which
>>> is part of the Ceph server) for direct access to the Ceph object
>>> store and is running entirely in userspace. Therefore it is
>>> called "rbd" - rados block device.
> ...
>>
>> IIRC underscores here may conflict with system header use. Please use
>> something like QEMU_BLOCK_RADOS_H.
>
> This header is shared between the linux kernel client and the ceph
> userspace servers and client. We can actually get rid of it, as we
> only need it to define CEPH_OSD_TMAP_SET. We can move this definition
> to librados.h.
>
>>> diff --git a/block/rbd_types.h b/block/rbd_types.h
>>> new file mode 100644
>>> index 000..dfd5aa0
>>> --- /dev/null
>>> +++ b/block/rbd_types.h
>>> @@ -0,0 +1,48 @@
>>> +#ifndef _FS_CEPH_RBD
>>> +#define _FS_CEPH_RBD
>>
>> QEMU_BLOCK_RBD?
>
> This header is shared between the ceph kernel client, between the qemu
> rbd module (and between other ceph utilities). It'd be much easier
> maintaining it without having to have a different implementation for
> each. The same goes to the use of __le32/64 and __u32/64 within these
> headers.
This is user space, so identifiers must conform to C standards. The
identifiers beginning with underscores are reserved.
Doesn't __le32/64 also depend on some GCC extension? Or sparse magic?
>
>>
>>> +
>>> +#include
>>
>> Can you use standard includes, like or ? Are
>> Ceph libraries used in other systems than Linux?
>
> Not at the moment. I guess that we can take this include out.
>
>>
>>> +
>>> +/*
>>> + * rbd image 'foo' consists of objects
>>> + * foo.rbd - image metadata
>>> + * foo.
>>> + * foo.0001
>>> + * ... - data
>>> + */
>>> +
>>> +#define RBD_SUFFIX ".rbd"
>>> +#define RBD_DIRECTORY "rbd_directory"
>>> +
>>> +#define RBD_DEFAULT_OBJ_ORDER 22 /* 4MB */
>>> +
>>> +#define RBD_MAX_OBJ_NAME_SIZE 96
>>> +#define RBD_MAX_SEG_NAME_SIZE 128
>>> +
>>> +#define RBD_COMP_NONE 0
>>> +#define RBD_CRYPT_NONE 0
>>> +
>>> +static const char rbd_text[] = "<<< Rados Block Device Image >>>\n";
>>> +static const char rbd_signature[] = "RBD";
>>> +static const char rbd_version[] = "001.001";
>>> +
>>> +struct rbd_obj_snap_ondisk {
>>> + __le64 id;
>>> + __le64 image_size;
>>> +} __attribute__((packed));
>>> +
>>> +struct rbd_obj_header_ondisk {
>>> + char text[64];
>>> + char signature[4];
>>> + char version[8];
>>> + __le64 image_size;
>>
>> Unaligned? Is the disk format fixed?
>
> This is a packed structure that represents the on disk format.
> Operations on it are being done only to read from the disk header or
> to write to the disk header.
That's clear. But what exactly is the alignment of field 'image_size'?
Could there be implicit padding to mod 8 between 'version' and
'image_size' with some compilers?
If there were no other constraints, I'd either make the padding
explicit, or rearrange/resize fields so that the field alignment is
natural. Thus my question, can you change the disk format or are there
already some deployments?
Otherwise, I'd just add some warning comment so people don't try to
use clever pointer tricks which will crash on machines with enforced
alignment.
[Qemu-devel] Re: [PATCH v2 12/15] monitor: Add basic device state visualization
Avi Kivity wrote:
> On 05/22/2010 11:18 AM, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> This introduces device_show, a monitor command that saves the vmstate of
>> a qdev device and visualizes it. QMP is also supported. Buffers are cut
>> after 16 byte by default, but the full content can be requested via
>> '-f'. To pretty-print sub-arrays, vmstate is extended to store the start
>> index name. A new qerror is introduced to signal a missing vmstate. And
>> it comes with documentation.
>>
>> +
>> +Dump a snapshot of the device state. Buffers are cut after 16 bytes
>> unless
>> +a full dump is requested.
>> +
>> +Arguments:
>> +
>> +- "path": the device's qtree path or unique ID (json-string)
>>
>
> This may be ambiguous.
Can your elaborate what precisely is ambiguous?
>
>> +- "full": report full state (json-bool, optional)
>>
>
> Is this needed for QMP? The client can always truncate it to any length.
The effect may not be needed for QMP, but I do need this channel from
the command line to the monitor pretty-printer. I could just stick
"full": json-bool back into the return dict, but that would look somehow
strange IMO.
>
>> +
>> +Schema of returned object:
>> +
>> +{ "device": json-string, "id": json-string, "fields" : [
>> field-objects ] }
>> +
>> +The field object array may be empty, otherwise it consists of
>> +
>> +{ "name": json-string, "size": json-int, "elems": [ element-objects ] }
>> +
>> +"size" describes the real number of bytes required for a binary
>> representation
>> +of a single field element in the array. The actually transfered
>> amount may be
>> +smaller unless a full dump was requested.
>>
>
> This converts the entire qdev tree into an undocumented stable protocol
> (the qdev paths were already in this state I believe). This really
> worries me.
Being primarily a debugging tool, device_show exports the entire
(qdev'ified) vmstates via QMP. Unlike the migration protocol, it does
not provide something like backward compatibility. This would be
overkill for the intended purpose (though someone may find a different
use case one day).
I think we have the following options:
- disable device_show via QMP, limit it to the monitor console
- declare its output inherently unstable, maybe at least adding the
vmstate version to each device so that potential QMP consumers notice
that they may have to update their tools or switch to a different
processing function
Given that vmstate annotations will most probably require some work on
the output structure (and I don't have a QMP use case ATM anyway), I
would be fine with the first option for now. Still, I don't think we
will ever get beyond the second option because this service is tight to
some internals of QEMU we don't want to freeze.
>
>> +
>> +The element object array may be empty, otherwise it can contain
>> +
>> +- json-int objects
>> +- QMP buffer objects
>> +- field objects
>> +- arrays of json-ints, QMP buffers, or field objects
>> +
>> +Example:
>> +
>> +-> { "execute": "device_show", "arguments": { "path": "isa.0/i8042" } }
>> +<- { "return": { "device": "i8042", "id": "", "fields":
>> + [ { "name": "kbd", "size": 4, "elems":
>> + [ { "name": "write_cmd", "size": 1, "elems": [0] },
>> + { "name": "status", "size": 1, "elems": [25] },
>> + { "name": "mode", "size": 1, "elems": [3] },
>> + { "name": "pending", "size": 1, "elems": [1] }
>> + ] }
>> + ]
>> + }
>> + }
>> +
>> +EQMP
>>
>
> Looks good. I am only worried about long term stability and documentation.
>
Thanks,
Jan
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v2 00/15] Basic device state visualization
Blue Swirl wrote: > On Sat, May 22, 2010 at 8:17 AM, Jan Kiszka wrote: >> Here is version 2 of the device_show patch series. It currently has some >> dependencies on recently posted doc changes / enhancements, namely: >> - http://thread.gmane.org/gmane.comp.emulators.qemu/70673 >> ([PATCH v3 0/3]: QMP: Commands doc) >> - http://thread.gmane.org/gmane.comp.emulators.qemu/70756 >> ([PATCH 1/7] QMP: Add "Downstream extension of QMP" to spec) > > I had minor comments to 8/15, otherwise looks good. Great. I will follow up on that patch or incorporate those bits in a potential third run. Thanks again - and sorry for forgetting to CC you, Jan signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v2 08/15] Add base64 encoder/decoder
Blue Swirl wrote:
> On Sat, May 22, 2010 at 8:18 AM, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> Will be used by QBuffer.
>>
>> Signed-off-by: Jan Kiszka
>> ---
>> Makefile.objs |2 +-
>> base64.c | 202
>> +
>> base64.h | 18 +
>> 3 files changed, 221 insertions(+), 1 deletions(-)
>> create mode 100644 base64.c
>> create mode 100644 base64.h
>>
>> diff --git a/Makefile.objs b/Makefile.objs
>> index acbaf22..2c603b2 100644
>> --- a/Makefile.objs
>> +++ b/Makefile.objs
>> @@ -2,7 +2,7 @@
>> # QObject
>> qobject-obj-y = qint.o qstring.o qdict.o qlist.o qfloat.o qbool.o
>> qobject-obj-y += qjson.o json-lexer.o json-streamer.o json-parser.o
>> -qobject-obj-y += qerror.o
>> +qobject-obj-y += qerror.o base64.o
>>
>> ###
>> # block-obj-y is code used by both qemu system emulation and qemu-img
>> diff --git a/base64.c b/base64.c
>> new file mode 100644
>> index 000..543e8c6
>> --- /dev/null
>> +++ b/base64.c
>> @@ -0,0 +1,202 @@
>> +/*
>> + * Base64 encoder/decoder conforming to RFC 4648
>> + * (based on Mozilla's nsprpub/lib/libc/src/base64.c)
>> + *
>> + * Copyright (C) 2010 Siemens AG
>> + *
>> + * Authors:
>> + * Jan Kiszka
>> + *
>> + * This work is licensed under the terms of the GNU LGPL, version 2.1 or
>> later.
>> + * See the COPYING.LIB file in the top-level directory.
>> + *
>> + */
>> +
>> +#include "inttypes.h"
>
> Why not ?
Oops, no intention.
>
>> +#include "base64.h"
>> +
>> +static const char base[] =
>> +"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/";
>> +
>> +static void encode3to4(const char *src, char *dest)
>> +{
>> +uint32_t b32 = 0;
>> +int i, j = 18;
>> +
>> +for (i = 0; i < 3; i++) {
>> +b32 <<= 8;
>> +b32 |= src[i];
>> +}
>> +for (i = 0; i < 4; i++) {
>> +dest[i] = base[(b32 >> j) & 0x3F];
>> +j -= 6;
>> +}
>> +}
>> +
>> +static void encode2to4(const char *src, char *dest)
>> +{
>> +dest[0] = base[(src[0] >> 2) & 0x3F];
>> +dest[1] = base[((src[0] & 0x03) << 4) | ((src[1] >> 4) & 0x0F)];
>> +dest[2] = base[(src[1] & 0x0F) << 2];
>> +dest[3] = '=';
>> +}
>> +
>> +static void encode1to4(const char *src, char *dest)
>> +{
>> +dest[0] = base[(src[0] >> 2) & 0x3F];
>> +dest[1] = base[(src[0] & 0x03) << 4];
>> +dest[2] = '=';
>> +dest[3] = '=';
>> +}
>> +
>> +/*
>> + * Encode data in 'src' of length 'srclen' to a base64 string, saving the
>> + * null-terminated result in 'dest'. The size of the destition buffer must
>> be
>> + * at least ((srclen + 2) / 3) * 4 + 1.
>> + */
>> +void base64_encode(const void *src, size_t srclen, char *dest)
>> +{
>> +while (srclen >= 3) {
>> +encode3to4(src, dest);
>> +src += 3;
>> +dest += 4;
>> +srclen -= 3;
>> +}
>> +switch (srclen) {
>> +case 2:
>> +encode2to4(src, dest);
>> +dest += 4;
>> +break;
>> +case 1:
>> +encode1to4(src, dest);
>> +dest += 4;
>> +break;
>> +case 0:
>> +break;
>> +}
>> +dest[0] = 0;
>> +}
>> +
>> +static int32_t codetovalue(char c)
>> +{
>> +if (c >= 'A' && c <= 'Z') {
>> +return c - 'A';
>> +} else if (c >= 'a' && c <= 'z') {
>> +return c - 'a' + 26;
>> +} else if (c >= '0' && c <= '9') {
>> +return c - '0' + 52;
>> +} else if (c == '+') {
>> +return 62;
>> +} else if ( c == '/') {
>> +return 63;
>> +} else {
>> +return -1;
>> +}
>> +}
>> +
>> +static int decode4to3 (const char *src, char *dest)
>> +{
>> +uint32_t b32 = 0;
>> +int32_t bits;
>> +int i;
>> +
>> +for (i = 0; i < 4; i++) {
>> +bits = codetovalue(src[i]);
>> +if (bits < 0) {
>> +return bits;
>> +}
>> +b32 <<= 6;
>> +b32 |= bits;
>> +}
>> +dest[0] = (b32 >> 16) & 0xFF;
>> +dest[1] = (b32 >> 8) & 0xFF;
>> +dest[2] = b32 & 0xFF;
>> +
>> +return 0;
>> +}
>> +
>> +static int decode3to2(const char *src, char *dest)
>> +{
>> +uint32_t b32 = 0;
>> +int32_t bits;
>> +
>> +bits = codetovalue(src[0]);
>> +if (bits < 0) {
>> +return bits;
>> +}
>> +b32 = (uint32_t)bits;
>> +b32 <<= 6;
>> +
>> +bits = codetovalue(src[1]);
>> +if (bits < 0) {
>> +return bits;
>> +}
>> +b32 |= (uint32_t)bits;
>> +b32 <<= 4;
>> +
>> +bits = codetovalue(src[2]);
>> +if (bits < 0) {
>> +return bits;
>> +}
>> +b32 |= ((uint32_t)bits) >> 2;
>> +
>> +dest[0] = (b32 >> 8) & 0xFF;
>> +dest[1] = b32 & 0xFF;
>> +
>> +return 0;
>> +}
>> +
>> +static int decode2to1(const char *src, char *dest)
>> +{
>> +uint32_t b32;
>> +int32_t bits;
>> +
>> +bits = codetovalue(src[0]);
>> +if (bits < 0) {
>> +return bits;
>> +}
>> +b32 = (uint32_
[Qemu-devel] Re: [PATCH] do not require lookahead for escapes too
On 05/21/2010 12:10 PM, Paolo Bonzini wrote: diff --git a/roms/seabios b/roms/seabios index 7d09d0e..8f469b9 16 --- a/roms/seabios +++ b/roms/seabios @@ -1 +1 @@ -Subproject commit 7d09d0e3ba11310e973d4302c7fcc3fc2184e04c +Subproject commit 8f469b9676127ba6bb52609d89ec774e61db0ee1 This was obviously not intended. I'll send a new version tomorrow. Paolo
Re: [Qemu-devel] Inquiry about qemu for Motorola 68360
> >>While QEMU does indeed works for x86 Windows, current QEMU's m68k architecture does not included that specific Motorola chip. Thank you for your reply. Can you please let me know which Motorola chips are being currently supported?
Re: [Qemu-devel] Inquiry about qemu for Motorola 68360
While QEMU does indeed works for x86 Windows, current QEMU's m68k architecture does not included that specific Motorola chip. El 23/05/2010, a las 05:28, hadi motamedi escribió: > Dear All > Do you have qemu emulator for Motorola 68360 emulation on x86 Windows > platform? > Thank you in advance >
