Re: [Qemu-devel] [PATCH v2 resend 3/4] Block: readonly changes
Am 04.02.2010 23:04, schrieb Naphtali Sprei:
> Open backing file for read-only
> During commit upgrade to read-write and back at end to read-only
>
> Signed-off-by: Naphtali Sprei
> ---
> block.c | 68
> ---
> block_int.h |1 +
> 2 files changed, 61 insertions(+), 8 deletions(-)
>
> diff --git a/block.c b/block.c
> index 66564de..4a9df91 100644
> --- a/block.c
> +++ b/block.c
> @@ -451,7 +451,6 @@ int bdrv_open2(BlockDriverState *bs, const char
> *filename, int flags,
> if (flags & (BDRV_O_CACHE_WB|BDRV_O_NOCACHE))
> bs->enable_write_cache = 1;
>
> -bs->read_only = (flags & BDRV_O_RDWR) == 0;
> if (!(flags & BDRV_O_FILE)) {
> open_flags = (flags & (BDRV_O_RDWR |
> BDRV_O_CACHE_MASK|BDRV_O_NATIVE_AIO));
> if (bs->is_temporary) { /* snapshot should be writeable */
> @@ -466,6 +465,7 @@ int bdrv_open2(BlockDriverState *bs, const char
> *filename, int flags,
> goto free_and_fail;
> }
>
> +bs->keep_read_only = bs->read_only = !(open_flags & BDRV_O_RDWR);
> if (drv->bdrv_getlength) {
> bs->total_sectors = bdrv_getlength(bs) >> BDRV_SECTOR_BITS;
> }
> @@ -482,13 +482,28 @@ int bdrv_open2(BlockDriverState *bs, const char
> *filename, int flags,
> filename, bs->backing_file);
> if (bs->backing_format[0] != '\0')
> back_drv = bdrv_find_format(bs->backing_format);
> +
> +open_flags &= ~BDRV_O_RDWR; /* clear RW, then restore from orig */
> +if (bs->is_temporary) {
> +open_flags |= (flags & BDRV_O_RDWR);
> +}
> +
> ret = bdrv_open2(bs->backing_hd, backing_filename, open_flags,
> back_drv);
> -bs->backing_hd->read_only = (open_flags & BDRV_O_RDWR) == 0;
> +if (ret < 0) {
> +open_flags &= ~BDRV_O_RDWR; /* Fall-back to read-only for the
> backing file */
> +ret = bdrv_open2(bs->backing_hd, backing_filename, open_flags,
> + back_drv);
> +}
Why is this needed? The only case in which a backing file is opened
read-write is during commit, right? For commit there is certainly no use
in opening it read-only instead.
This whole code looks like there are cases where a backing file is still
opened read-write by default, though the commit message says that no
such backing files exist. Am I missing something?
> if (ret < 0) {
> bdrv_close(bs);
> return ret;
> }
> +if (!bs->is_temporary) {
> +bs->backing_hd->keep_read_only = bs->keep_read_only; /* base
> image inherits from "parent" and open read-only */
This looks like more than 80 characters on a line.
What would helps here and also would improve consistency in style is to
move the comments to the line before instead of sticking them at the end
of a code line. This is true even more if the comment actually applies
to a whole block and not only to the line in which it is written (you're
doing this in other places).
> +} else {
> +bs->backing_hd->keep_read_only = !(flags & BDRV_O_RDWR);
> +}
> }
>
> if (!bdrv_key_required(bs)) {
> @@ -564,19 +579,38 @@ int bdrv_commit(BlockDriverState *bs)
> {
> BlockDriver *drv = bs->drv;
> int64_t i, total_sectors;
> -int n, j;
> +int n, j, ro, open_flags;
> int ret = 0;
> unsigned char sector[512];
> +char filename[1024];
> +BlockDriverState *bs_rw, *bs_ro;
>
> if (!drv)
> return -ENOMEDIUM;
> +
> +if (!bs->backing_hd) {
> + return -ENOTSUP;
> +}
>
> -if (bs->read_only) {
> +if (bs->backing_hd->keep_read_only) {
> return -EACCES;
> }
> +
> +ro = bs->backing_hd->read_only;
> +strncpy(filename, bs->backing_hd->filename, sizeof(filename));
> +open_flags = bs->backing_hd->open_flags;
>
> -if (!bs->backing_hd) {
> - return -ENOTSUP;
> +if (ro) { /* re-open as RW */
> +bdrv_close(bs->backing_hd);
> +qemu_free(bs->backing_hd);
bdrv_delete is doing what you mean here. But actually, you don't need to
delete it, you can just reuse the old bs for re-opening the image.
> +
> +bs_rw = bdrv_new("");
> +ret = bdrv_open2(bs_rw, filename, open_flags | BDRV_O_RDWR, NULL);
> +if (ret < 0) {
> +bdrv_delete(bs_rw);
> +return -EACCES;
Why don't you pass the right return value up? Apart from that, you
should re-open the backing file (read-only) or the VM will get into
trouble...
> +}
> +bs->backing_hd = bs_rw;
Eek... ;-) Well, it should work, as far as I know the block drivers.
> }
>
> total_sectors = bdrv_getlength(bs) >> BDRV_SECTOR_BITS;
> @@ -584,11 +618,13 @@ int bdrv_commit(BlockDriverState *bs)
> if (drv->bdrv_is_allocated(bs, i, 65536, &n)) {
> for(j = 0; j < n; j++
Re: [Qemu-devel] Re: [PATCH 0/4] Fix printf calls embedding preprocessor directives
Am 05.02.2010 03:26, schrieb Sheng Yang: > On Thursday 04 February 2010 23:49:55 Paolo Bonzini wrote: >> Patch 1 is the same I sent earlier. Patches 2 and 3/4 fix the >> other two problems by Sheng (tip: next time use "make -k" and >> report all problems in a single message). >> >> Paolo Bonzini (4): >> qemu-img: avoid preprocessor directives in a printf call >> cope with printf macro definition in readline.c >> do not interpolate % from vl.c to qemu-options.h >> vl.c: avoid preprocessor directives in a printf call >> >> qemu-img.c |9 + >> qemu-options.hx | 15 --- >> readline.c |1 + >> vl.c| 23 +-- >> 4 files changed, 23 insertions(+), 25 deletions(-) >> > Works fine with me. Thanks. :) > > But: > > diff --git a/vl.c b/vl.c > index 39833fc..3d2de7b 100644 > --- a/vl.c > +++ b/vl.c > @@ -4041,14 +4041,7 @@ static void help(int exitcode) > "\n" > "When using -nographic, press 'ctrl-a h' to get some help.\n" > , > - "qemu", > - DEFAULT_RAM_SIZE, > -#ifndef _WIN32 > - DEFAULT_NETWORK_SCRIPT, > - DEFAULT_NETWORK_DOWN_SCRIPT, > -#endif > - DEFAULT_GDBSTUB_PORT, > - "/tmp/qemu.log"); > + "qemu"); > exit(exitcode); > } > > Is it proper to remove #ifndef _WIN32 there? These lines are only moved into another #ifdef (in qemu-options.hx), so this looks right to me. Kevin
Re: [Qemu-devel] [PATCH v2 0/4]: QMP capability negotiation support
Luiz Capitulino writes: > Capability negotiation allows clients to enable new QMP capabilities they > support and thus allows QMP to evolve in a compatible way. > > This series implements Markus's design and is a revamp of the previous > one. It's very simple now, as mode-oriented support has been dropped. I've > maintained the same terminology, though. > > Basically, QMP starts in capability negotiation mode where only the > 'qmp_capabilities' command is allowed to run. This command should be used > by clients to enable capabilities they support. When this command is issued > QMP enters in command mode, where the party begins. > > Details in the patches. > > changelog > - > > v1 -> v2 > > - Typos and minor changes > > v0 -> v1 > > - Drop mode-oriented support Looks good, thanks!
Re: [Qemu-devel] [PATCH 1/4] qjson: Improve debugging
Anthony Liguori writes: > On 02/04/2010 02:13 PM, Luiz Capitulino wrote: >> Add an assert() to qobject_from_jsonf() to assure that the returned >> QObject is not NULL. Currently this is duplicated in the callers. >> >> Signed-off-by: Luiz Capitulino >> --- >> qjson.c |1 + >> 1 files changed, 1 insertions(+), 0 deletions(-) >> >> diff --git a/qjson.c b/qjson.c >> index 9ad8a91..0922c06 100644 >> --- a/qjson.c >> +++ b/qjson.c >> @@ -62,6 +62,7 @@ QObject *qobject_from_jsonf(const char *string, ...) >> obj = qobject_from_jsonv(string,&ap); >> va_end(ap); >> >> +assert(obj != NULL); >> > > This is wrong. We may get JSON from an untrusted source. Callers > need to deal with failure appropriately. > > It just so happens that we only parse JSON from an untrusted source > via qobject_from_json(), but the trust relationship is not obvious > given the two functions in their current form. We have many uses of qobject_from_jsonf() with a literal argument, and more to come. Making them all deal with failure would be tedious and clutter the code. What about a wrapper function that cannot fail?
Re: [Qemu-devel] [PATCH 3/4] QError: Don't abort on multiple faults
Luiz Capitulino writes: > Ideally, Monitor code should report an error only once and > return the error information up the call chain. > > To assure that this happens as expected and that no error is > lost, we have an assert() in qemu_error_internal(). > > However, we still have not fully converted handlers using > monitor_printf() to report errors. As there can be multiple > monitor_printf() calls on an error, the assertion is easily > triggered when debugging is enabled; and we will get a memory > leak if it's not. > > The solution to this problem is to allow multiple faults by only > reporting the first one, and to release the additional error objects. I want this badly. [...]
Re: [Qemu-devel] Adding support for MIPS64 as host
pinery writes: Hi, > 於 四，2010-02-04 於 22:56 +0530，Utkarsh Sopan 提到： >> >> Can you tell me what is the status of adding MIPS64 support? >> as at the wiki page it showed Red earlier. >> On Wed, Feb 3, 2010 at 10:29 PM, Laurent Desnogues >> wrote: >> On Wed, Feb 3, 2010 at 5:53 PM, Utkarsh Sopan >> wrote: >> > I am trying to add support for MIPS 64 as Host machine as my >> academic >> > project. >> >> >> Note that some work has already been done for MIPS host >> support. >> >> > I am new to QEMU. >> > >> > Problem is I dont have a MIPS 64 machine to test on. >> > Please suggest whether or not I can use a nested QEMU >> emulator to test the >> > same. >> > i.e. running my version on top of a simulated MIPS64 >> machine. >> > >> > Is it possible to do so? >> >> >> I was able to run on an x86_64 host, an ARM-hosted QEMU >> simulating >> x86. That was for Linux user mode. I can't say if that would >> work for >> other targets or for system simulation. >> >> >> Laurent >> > A company called lemote[1] sells laptop and mini-PC based MIPS > CPU ,loongson[2],a 800M 64-bit four-issues out-of-order execution > Superscalar architecture. Quad-Core Loongson-3 Processor has been taped > out by ST Microelectronics. Currently,I run qemu on my loongson > computer,but qemu crashs during booting. Unfortunately, you won't get further for now. There's a cache problem leading to bad relocation (in case of relocations, jump to label are "transformed" into jump to next instruction). See linux-mips mailing list, there was on thread about it. Arnaud
[Qemu-devel] Re: [PATCH 0/4] Fix printf calls embedding preprocessor directives
On 02/05/2010 03:26 AM, Sheng Yang wrote: -#ifndef _WIN32 - DEFAULT_NETWORK_SCRIPT, - DEFAULT_NETWORK_DOWN_SCRIPT, -#endif - DEFAULT_GDBSTUB_PORT, - "/tmp/qemu.log"); + "qemu"); exit(exitcode); } Is it proper to remove #ifndef _WIN32 there? Yes, this matched a #ifndef in qemu-options.hx that remains there. Paolo
[Qemu-devel] [PATCH v2] vnc: Migrate to using QTAILQ instead of custom implementation
Just a 1-1 conversion for now.
Signed-off-by: Amit Shah
---
v2:
- QTAILQ_INIT the queue.
vnc.c | 74
vnc.h |5 ++-
2 files changed, 31 insertions(+), 48 deletions(-)
diff --git a/vnc.c b/vnc.c
index 92facde..2200fbf 100644
--- a/vnc.c
+++ b/vnc.c
@@ -356,17 +356,14 @@ void do_info_vnc(Monitor *mon, QObject **ret_data)
*ret_data = qobject_from_jsonf("{ 'enabled': false }");
} else {
QList *clist;
+VncState *client;
clist = qlist_new();
-if (vnc_display->clients) {
-VncState *client = vnc_display->clients;
-while (client) {
-if (client->info) {
-/* incref so that it's not freed by upper layers */
-qobject_incref(client->info);
-qlist_append_obj(clist, client->info);
-}
-client = client->next;
+QTAILQ_FOREACH(client, &vnc_display->clients, next) {
+if (client->info) {
+/* incref so that it's not freed by upper layers */
+qobject_incref(client->info);
+qlist_append_obj(clist, client->info);
}
}
@@ -519,7 +516,7 @@ static void vnc_dpy_resize(DisplayState *ds)
{
int size_changed;
VncDisplay *vd = ds->opaque;
-VncState *vs = vd->clients;
+VncState *vs;
/* server surface */
if (!vd->server)
@@ -540,7 +537,7 @@ static void vnc_dpy_resize(DisplayState *ds)
*(vd->guest.ds) = *(ds->surface);
memset(vd->guest.dirty, 0xFF, sizeof(vd->guest.dirty));
-while (vs != NULL) {
+QTAILQ_FOREACH(vs, &vd->clients, next) {
vnc_colordepth(vs);
if (size_changed) {
if (vs->csock != -1 && vnc_has_feature(vs, VNC_FEATURE_RESIZE)) {
@@ -553,7 +550,6 @@ static void vnc_dpy_resize(DisplayState *ds)
}
}
memset(vs->dirty, 0xFF, sizeof(vs->dirty));
-vs = vs->next;
}
}
@@ -867,8 +863,7 @@ static void vnc_dpy_copy(DisplayState *ds, int src_x, int
src_y, int dst_x, int
int cmp_bytes;
vnc_refresh_server_surface(vd);
-for (vs = vd->clients; vs != NULL; vs = vn) {
-vn = vs->next;
+QTAILQ_FOREACH_SAFE(vs, &vd->clients, next, vn) {
if (vnc_has_feature(vs, VNC_FEATURE_COPYRECT)) {
vs->force_update = 1;
vnc_update_client(vs, 1);
@@ -912,11 +907,10 @@ static void vnc_dpy_copy(DisplayState *ds, int src_x, int
src_y, int dst_x, int
if (memcmp(src_row, dst_row, cmp_bytes) == 0)
continue;
memmove(dst_row, src_row, cmp_bytes);
-vs = vd->clients;
-while (vs != NULL) {
-if (!vnc_has_feature(vs, VNC_FEATURE_COPYRECT))
+QTAILQ_FOREACH(vs, &vd->clients, next) {
+if (!vnc_has_feature(vs, VNC_FEATURE_COPYRECT)) {
vnc_set_bit(vs->dirty[y], ((x + dst_x) / 16));
-vs = vs->next;
+}
}
}
src_row += pitch - w * depth;
@@ -924,9 +918,10 @@ static void vnc_dpy_copy(DisplayState *ds, int src_x, int
src_y, int dst_x, int
y += inc;
}
-for (vs = vd->clients; vs != NULL; vs = vs->next) {
-if (vnc_has_feature(vs, VNC_FEATURE_COPYRECT))
+QTAILQ_FOREACH(vs, &vd->clients, next) {
+if (vnc_has_feature(vs, VNC_FEATURE_COPYRECT)) {
vnc_copy(vs, src_x, src_y, dst_x, dst_y, w, h);
+}
}
}
@@ -1109,19 +1104,11 @@ static void vnc_disconnect_finish(VncState *vs)
#endif /* CONFIG_VNC_SASL */
audio_del(vs);
-VncState *p, *parent = NULL;
-for (p = vs->vd->clients; p != NULL; p = p->next) {
-if (p == vs) {
-if (parent)
-parent->next = p->next;
-else
-vs->vd->clients = p->next;
-break;
-}
-parent = p;
-}
-if (!vs->vd->clients)
+QTAILQ_REMOVE(&vs->vd->clients, vs, next);
+
+if (QTAILQ_EMPTY(&vs->vd->clients)) {
dcl->idle = 1;
+}
vnc_remove_timer(vs->vd);
qemu_free(vs);
@@ -2299,7 +2286,7 @@ static int vnc_refresh_server_surface(VncDisplay *vd)
uint8_t *server_row;
int cmp_bytes;
uint32_t width_mask[VNC_DIRTY_WORDS];
-VncState *vs = NULL;
+VncState *vs;
int has_dirty = 0;
/*
@@ -2328,10 +2315,8 @@ static int vnc_refresh_server_surface(VncDisplay *vd)
if (memcmp(server_ptr, guest_ptr, cmp_bytes) == 0)
continue;
memcpy(server_ptr, guest_ptr, cmp_bytes);
-vs = vd->clients;
-while (vs != NULL) {
+QTAILQ_FOREACH(vs, &vd->clients, next) {
vnc_set_bit(vs->dirty[y], (x / 16));
-vs = vs->next;
}
has_dirty++;
}
@@ -2345,19 +2330,16 @@ static int
[Qemu-devel] Re: [PATCH] qemu-kvm: Speed up of the dirty-bitmap-traveling
OHMURA Kei wrote:
> dirty-bitmap-traveling is carried out by byte size in qemu-kvm.c.
> But We think that dirty-bitmap-traveling by long size is faster than by byte
> size especially when most of memory is not dirty.
Sounds logical - do you have numbers on the improvement?
Would be great if you could provide a version for upstream as well
because it will likely replace this qemu-kvm code on day.
Jan
>
> Signed-off-by: OHMURA Kei
> ---
> qemu-kvm.c | 49 ++---
> 1 files changed, 42 insertions(+), 7 deletions(-)
>
> diff --git a/qemu-kvm.c b/qemu-kvm.c
> index a305907..5459cdd 100644
> --- a/qemu-kvm.c
> +++ b/qemu-kvm.c
> @@ -2433,22 +2433,21 @@ int kvm_physical_memory_set_dirty_tracking(int enable)
> }
>
> /* get kvm's dirty pages bitmap and update qemu's */
> -static int kvm_get_dirty_pages_log_range(unsigned long start_addr,
> - unsigned char *bitmap,
> - unsigned long offset,
> - unsigned long mem_size)
> +static void kvm_get_dirty_pages_log_range_by_byte(unsigned int start,
> + unsigned int end,
> + unsigned char *bitmap,
> + unsigned long offset)
> {
> unsigned int i, j, n = 0;
> unsigned char c;
> unsigned long page_number, addr, addr1;
> ram_addr_t ram_addr;
> -unsigned int len = ((mem_size / TARGET_PAGE_SIZE) + 7) / 8;
>
> /*
> * bitmap-traveling is faster than memory-traveling (for addr...)
> * especially when most of the memory is not dirty.
> */
> -for (i = 0; i < len; i++) {
> +for (i = start; i < end; i++) {
> c = bitmap[i];
> while (c > 0) {
> j = ffsl(c) - 1;
> @@ -2461,13 +2460,49 @@ static int kvm_get_dirty_pages_log_range(unsigned
> long start_addr,
> n++;
> }
> }
> +}
> +
> +static int kvm_get_dirty_pages_log_range_by_long(unsigned long start_addr,
> + unsigned char *bitmap,
> + unsigned long offset,
> + unsigned long mem_size)
> +{
> +unsigned int i;
> +unsigned int len;
> +unsigned long *bitmap_ul = (unsigned long *)bitmap;
> +
> +/* bitmap-traveling by long size is faster than by byte size
> + * especially when most of memory is not dirty.
> + * bitmap should be long-size aligned for traveling by long.
> + */
> +if (((unsigned long)bitmap & (TARGET_LONG_SIZE - 1)) == 0) {
> +len = ((mem_size / TARGET_PAGE_SIZE) + TARGET_LONG_BITS - 1) /
> +TARGET_LONG_BITS;
> +for (i = 0; i < len; i++)
> +if (bitmap_ul[i] != 0)
> +kvm_get_dirty_pages_log_range_by_byte(i * TARGET_LONG_SIZE,
> +(i + 1) * TARGET_LONG_SIZE, bitmap, offset);
> +/*
> + * We will check the remaining dirty-bitmap,
> + * when the mem_size is not a multiple of TARGET_LONG_SIZE.
> + */
> +if ((mem_size & (TARGET_LONG_SIZE - 1)) != 0) {
> +len = ((mem_size / TARGET_PAGE_SIZE) + 7) / 8;
> +kvm_get_dirty_pages_log_range_by_byte(i * TARGET_LONG_SIZE,
> +len, bitmap, offset);
> +}
> +} else { /* slow path: traveling by byte. */
> +len = ((mem_size / TARGET_PAGE_SIZE) + 7) / 8;
> +kvm_get_dirty_pages_log_range_by_byte(0, len, bitmap, offset);
> +}
> +
> return 0;
> }
>
> static int kvm_get_dirty_bitmap_cb(unsigned long start, unsigned long len,
> void *bitmap, void *opaque)
> {
> -return kvm_get_dirty_pages_log_range(start, bitmap, start, len);
> +return kvm_get_dirty_pages_log_range_by_long(start, bitmap, start, len);
> }
>
> /*
> -- 1.6.3.3
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH 1/4] qjson: Improve debugging
On Thu, 04 Feb 2010 16:31:46 -0600 Anthony Liguori wrote: > On 02/04/2010 02:13 PM, Luiz Capitulino wrote: > > Add an assert() to qobject_from_jsonf() to assure that the returned > > QObject is not NULL. Currently this is duplicated in the callers. > > > > Signed-off-by: Luiz Capitulino > > --- > > qjson.c |1 + > > 1 files changed, 1 insertions(+), 0 deletions(-) > > > > diff --git a/qjson.c b/qjson.c > > index 9ad8a91..0922c06 100644 > > --- a/qjson.c > > +++ b/qjson.c > > @@ -62,6 +62,7 @@ QObject *qobject_from_jsonf(const char *string, ...) > > obj = qobject_from_jsonv(string,&ap); > > va_end(ap); > > > > +assert(obj != NULL); > > > > This is wrong. We may get JSON from an untrusted source. Callers need > to deal with failure appropriately. What kind of untrusted source? This function is only used by handlers and assuming that the only possible error here is bad syntax, not having this check in the source will only duplicate it in the users. > It just so happens that we only parse JSON from an untrusted source via > qobject_from_json(), but the trust relationship is not obvious given the > two functions in their current form. Not exactly, qobject_from_json() is not even being currently used. We parse JSON data from clients by using the low-level parser API, that's by calling json_message_parser_feed() to read the input and then calling json_parser_parse() when we have collected enough data. qobject_from_jsonf() is only used internally, by handlers. Both, qobject_from_jsonf() and qobject_from_json() are _wrappers_ to qobject_from_jsonv(), which uses the low-level API directly. So, having the assert() in qobject_from_jsonf() should only affect handlers, which seems fine to me.
Re: [Qemu-devel] [PATCH 1/4] qjson: Improve debugging
On Fri, 05 Feb 2010 10:13:33 +0100 Markus Armbruster wrote: > Anthony Liguori writes: > > > On 02/04/2010 02:13 PM, Luiz Capitulino wrote: > >> Add an assert() to qobject_from_jsonf() to assure that the returned > >> QObject is not NULL. Currently this is duplicated in the callers. > >> > >> Signed-off-by: Luiz Capitulino > >> --- > >> qjson.c |1 + > >> 1 files changed, 1 insertions(+), 0 deletions(-) > >> > >> diff --git a/qjson.c b/qjson.c > >> index 9ad8a91..0922c06 100644 > >> --- a/qjson.c > >> +++ b/qjson.c > >> @@ -62,6 +62,7 @@ QObject *qobject_from_jsonf(const char *string, ...) > >> obj = qobject_from_jsonv(string,&ap); > >> va_end(ap); > >> > >> +assert(obj != NULL); > >> > > > > This is wrong. We may get JSON from an untrusted source. Callers > > need to deal with failure appropriately. > > > > It just so happens that we only parse JSON from an untrusted source > > via qobject_from_json(), but the trust relationship is not obvious > > given the two functions in their current form. > > We have many uses of qobject_from_jsonf() with a literal argument, and > more to come. Making them all deal with failure would be tedious and > clutter the code. What about a wrapper function that cannot fail? As far as I can understand, qobject_from_jsonf() is supposed to be that wrapper already.
[Qemu-devel] Re: kqemu and XP guest - lock-up at mup.sys
Gordan Bobic wrote: > Hi, > > It would appear that kqemu somehow breaks the XP guest under some > circumstances. > > If I install from scratch in qemu+kqemu, it works fine in kqemu, but not > on bare metal. The fact it doesn't work on bare metal COULD be related > to the fact that on bare metal I'm running off a USB stick (it's a > rescue system). > > If I install onto bare metal (again, onto a USB stick - I have a > modified installer that includes the USB disk drivers at setup stage) > and then start up that install in qemu, that works as long as I don't > apply kqemu. But if I modprobe kqemu and start with > -enable-kqemu/-kernel-kqemu (-smp 1 in all cases), the quest instanty > locks up at 100% CPU usage. Everything else about the qemu configuration > is exactly the same between the runs. Booting the system with -no-acpi > at this point causes it to reboot instead of just locking up. > > I tried with qemu 0.10.5 (RHEL5 from atrpms) and 0.11.1 (built from > source). kqemu I use is dkms 1.4.0pre1 from the Dag repository. > > With kqemu, the guest stops booting (including safe mode) at mup.sys. > Googling around for similar problems didn't reveal much of use (other > than the usual Windows solution to everything of "reinstall", which > isn't an option here because I need the same setup to work both on bare > metal and in qemu). Is there a work-around/tweak to make this work? Is > there any particular reason why kqemu would break things under these > circumstances when running without kqemu works fine, if slower? Is there > a difference in how the emulated hardware looks/behaves with and without > kqemu? Due to limitations of the x86 architecture, kqemu used to be far a way from providing accurate virtualization. That was one of the reasons why no one worked on it anymore and, thus, it is no longer supported by QEMU starting with release 0.12. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH 2/4] block: add block topology options
On Wed, Feb 03, 2010 at 01:00:47PM -0600, Anthony Liguori wrote: > But I don't think this is the wrong place to do it. The > BlockDriverState reflects that backing device, not the emulated device > itself. In this case, you're trying to set a property of the emulated > device. I think that's very borderline. While the emulated device exposes these properties, they are in fact a property of the backing storage, the right sector and min/max I/O sizes are determined by the backing storage device. > I think these need to be qdev properties of the respective devices. > From a UI perspective, you can still expose -drive options for the end > user to consume, but this data should be associated with the devices > themselves. In addition to not really beeing more logical this would be a lot more effort. We'd need to add properties to all the device, which means including dealing with the n+1 ide variants, the virtio-pci proxy, etc. If you believe it really needs to be in the qdev properties I'll implement it, but I suspect the current version is a better idea.
Re: [Qemu-devel] Re: kqemu and XP guest - lock-up at mup.sys
Jan Kiszka wrote: Gordan Bobic wrote: Hi, It would appear that kqemu somehow breaks the XP guest under some circumstances. If I install from scratch in qemu+kqemu, it works fine in kqemu, but not on bare metal. The fact it doesn't work on bare metal COULD be related to the fact that on bare metal I'm running off a USB stick (it's a rescue system). If I install onto bare metal (again, onto a USB stick - I have a modified installer that includes the USB disk drivers at setup stage) and then start up that install in qemu, that works as long as I don't apply kqemu. But if I modprobe kqemu and start with -enable-kqemu/-kernel-kqemu (-smp 1 in all cases), the quest instanty locks up at 100% CPU usage. Everything else about the qemu configuration is exactly the same between the runs. Booting the system with -no-acpi at this point causes it to reboot instead of just locking up. I tried with qemu 0.10.5 (RHEL5 from atrpms) and 0.11.1 (built from source). kqemu I use is dkms 1.4.0pre1 from the Dag repository. With kqemu, the guest stops booting (including safe mode) at mup.sys. Googling around for similar problems didn't reveal much of use (other than the usual Windows solution to everything of "reinstall", which isn't an option here because I need the same setup to work both on bare metal and in qemu). Is there a work-around/tweak to make this work? Is there any particular reason why kqemu would break things under these circumstances when running without kqemu works fine, if slower? Is there a difference in how the emulated hardware looks/behaves with and without kqemu? Due to limitations of the x86 architecture, kqemu used to be far a way from providing accurate virtualization. KVM is subject to the same limitations, though, so that point is a bit moot. The only reason why I'm using kqemu is because I still have legacy 32-bit hardware around that doesn't have VT extensions. Either way, I'm mainly interested in the details of the differences in the environment provided by qemu with and without kqemu, as clearly it is this difference that causes the problem in question. Gordan
[Qemu-devel] [PULL] linux-user-for upstream
Same patchset as sent last week, with the TLS patched changed to the "refactor cp15.c13" patch already acked by Laurent. The following changes since commit 117f8eb81dfdf51a0418fbf6d260cbb72bcd4a9d: Markus Armbruster (1): qdev: Add rudimentary help for property value are available in the git repository at: http://git.gitorious.org/qemu-maemo/qemu-maemo.git linux-user-for-upstream Loïc Minier (1): linux-user: adapt uname machine to emulated CPU Riku Voipio (3): fix locking error with current_tb linux-user: remove signal handler before calling abort() target-arm: refactor cp15.c13 register access Makefile.target|2 +- exec.c | 13 +++- linux-user/cpu-uname.c | 72 linux-user/cpu-uname.h |1 + linux-user/syscall.c |3 +- target-arm/helper.c| 16 -- target-arm/translate.c | 55 7 files changed, 142 insertions(+), 20 deletions(-) create mode 100644 linux-user/cpu-uname.c create mode 100644 linux-user/cpu-uname.h
Re: [Qemu-devel] [PATCH 3/4] QError: Don't abort on multiple faults
Markus Armbruster writes: > Luiz Capitulino writes: > >> Ideally, Monitor code should report an error only once and >> return the error information up the call chain. >> >> To assure that this happens as expected and that no error is >> lost, we have an assert() in qemu_error_internal(). >> >> However, we still have not fully converted handlers using >> monitor_printf() to report errors. As there can be multiple >> monitor_printf() calls on an error, the assertion is easily >> triggered when debugging is enabled; and we will get a memory >> leak if it's not. >> >> The solution to this problem is to allow multiple faults by only >> reporting the first one, and to release the additional error objects. > > I want this badly. > > [...] Let me elaborate a bit. While this patch is a much wanted improvement, what I *really* want is something else. Right now, we have 41 uses of qemu_error_new(). We still have >300 uses of monitor_printf(), many of them errors. Plus some 100 uses of qemu_error(), which boils down to monitor_printf() when running within a monitor. Not to mention >1000 uses of stderr. To convert a monitor handler to QError, we have to make it report exactly one error on every unsuccessful path, with qemu_error_new(). That's not too hard. Then we have to ensure it does not call monitor_printf() directly (not hard either) or indirectly (ouch). I say "ouch", because those prints can hide behind long call chains, in code shared with other users. Cleaning up all those stray prints will take time. Without this patch, a stray print is fatal, unless it happens to be the only one *and* there is no real error. With this patch, we survive, but the UndefinedError triggered by the stray print displaces any later real error. What I really want is that stray prints do not mess with my real errors.
Re: [Qemu-devel] [PATCH 3/4] QError: Don't abort on multiple faults
On Fri, 05 Feb 2010 15:21:13 +0100 Markus Armbruster wrote: > Markus Armbruster writes: > > > Luiz Capitulino writes: > > > >> Ideally, Monitor code should report an error only once and > >> return the error information up the call chain. > >> > >> To assure that this happens as expected and that no error is > >> lost, we have an assert() in qemu_error_internal(). > >> > >> However, we still have not fully converted handlers using > >> monitor_printf() to report errors. As there can be multiple > >> monitor_printf() calls on an error, the assertion is easily > >> triggered when debugging is enabled; and we will get a memory > >> leak if it's not. > >> > >> The solution to this problem is to allow multiple faults by only > >> reporting the first one, and to release the additional error objects. > > > > I want this badly. > > > > [...] > > Let me elaborate a bit. While this patch is a much wanted improvement, > what I *really* want is something else. > > Right now, we have 41 uses of qemu_error_new(). We still have >300 uses > of monitor_printf(), many of them errors. Plus some 100 uses of > qemu_error(), which boils down to monitor_printf() when running within a > monitor. Not to mention >1000 uses of stderr. > > To convert a monitor handler to QError, we have to make it report > exactly one error on every unsuccessful path, with qemu_error_new(). > That's not too hard. Then we have to ensure it does not call > monitor_printf() directly (not hard either) or indirectly (ouch). I say > "ouch", because those prints can hide behind long call chains, in code > shared with other users. Cleaning up all those stray prints will take > time. As we have talked, this situation will be improved by making cmd_new return an error code, right? I've started working on it already, patches will be sent soon. > Without this patch, a stray print is fatal, unless it happens to be the > only one *and* there is no real error. > > With this patch, we survive, but the UndefinedError triggered by the > stray print displaces any later real error. > > What I really want is that stray prints do not mess with my real errors. There are two issues here: 1. In command handlers stray prints _usually_ report errors. If we go with shallow conversion, I believe that clients should be informed (in the form of an undefined error) that monitor_printf() has been called 2. We have agreed that multiple faults are not allowed and that reporting only the first one is fine. In shallow conversion (or even in buggy conversions) we can get multiple faults and we have to handle it So, the situation will be improved by my next series as we can use the return code to 'audit' qemu_error_new() usage (which includes monitor_printf() calls).
[Qemu-devel] TB monitoring
Guys, I need a Qemu-internals expert to help me out here: I'm trying to monitor execution of certain (user-land) TBs in a i386-softmmu system. For this, the cpu-main loop has been patched: Before jumping into a TB's generated code, I first check its guest-virtual start address whether it matches any of my monitored EIPs. Obviously, this only works for monitoring function starts (or other locations where a new TB is guaranteed to start) and with TB-chaining turned off. So far, this has been working great (for years even). Now I tried to improve the performance of my monitoring system by doing the following: Each TB is associated with an additional 2 bits (in the "cflags"): "seen-before" and "monitored". Whenever I check a TB, I also set its seen- before flag and update the monitored bit (if the TB contains a monitored start EIP). Since a TB might be shared between two guest processes (the system is monitoring a Windows XP guest), I also save the a guest-process unique ID with the TB (using some bits from its CR3). With this, I can skip checking a TB if its seen-before bit is set, but the monitored is clear. If the TB's guest-process-ID is different from the currently executing process-ID I just reset the seen-before bit (which forces the EIP analysis). I have tried this on various programs, running inside my guest and it seems to be fast and working (almost ;-)). However, sometimes (*very* rarely), the above approach misses a monitored TB (skips analysis). Could someone comment on my approach, maybe including some of the following thoughts: 1) is it possible that a TB grows ... i.e., it merges with a second TB where the second is monitored but the first one isn't? 2) are there any situations how a TB can be created without going through tb_alloc (which internally resets the cflags and thus my bits)? Note that my code is based on Qemu 0.9.1 (if you wonder why I refer to certain old-style Qemu-internals). Any help would be greatly appreciated!! If you need some more information or don't fully understand the problem, please don't hesitate to ask. Thanks!! Clemens
Re: [Qemu-devel] [PATCH 3/4] QError: Don't abort on multiple faults
Luiz Capitulino writes: > On Fri, 05 Feb 2010 15:21:13 +0100 > Markus Armbruster wrote: > >> Markus Armbruster writes: >> >> > Luiz Capitulino writes: >> > >> >> Ideally, Monitor code should report an error only once and >> >> return the error information up the call chain. >> >> >> >> To assure that this happens as expected and that no error is >> >> lost, we have an assert() in qemu_error_internal(). >> >> >> >> However, we still have not fully converted handlers using >> >> monitor_printf() to report errors. As there can be multiple >> >> monitor_printf() calls on an error, the assertion is easily >> >> triggered when debugging is enabled; and we will get a memory >> >> leak if it's not. >> >> >> >> The solution to this problem is to allow multiple faults by only >> >> reporting the first one, and to release the additional error objects. >> > >> > I want this badly. >> > >> > [...] >> >> Let me elaborate a bit. While this patch is a much wanted improvement, >> what I *really* want is something else. >> >> Right now, we have 41 uses of qemu_error_new(). We still have >300 uses >> of monitor_printf(), many of them errors. Plus some 100 uses of >> qemu_error(), which boils down to monitor_printf() when running within a >> monitor. Not to mention >1000 uses of stderr. >> >> To convert a monitor handler to QError, we have to make it report >> exactly one error on every unsuccessful path, with qemu_error_new(). >> That's not too hard. Then we have to ensure it does not call >> monitor_printf() directly (not hard either) or indirectly (ouch). I say >> "ouch", because those prints can hide behind long call chains, in code >> shared with other users. Cleaning up all those stray prints will take >> time. > > As we have talked, this situation will be improved by making cmd_new > return an error code, right? Yes. > I've started working on it already, patches will be sent soon. Excellent. >> Without this patch, a stray print is fatal, unless it happens to be the >> only one *and* there is no real error. >> >> With this patch, we survive, but the UndefinedError triggered by the >> stray print displaces any later real error. >> >> What I really want is that stray prints do not mess with my real errors. > > There are two issues here: > > 1. In command handlers stray prints _usually_ report errors. If we go > with shallow conversion, I believe that clients should be informed > (in the form of an undefined error) that monitor_printf() has been > called It's not so easy. A command should report an error if and only if it really failed. Reporting an error even though the command succeeded is just as bad as not reporting an error when it failed. Barring bugs, a handler *knows* whether it got the job done or not. It can and should communicate that knowledge up by returning status. I understand one of your next patch series will do that. If a handler returns failure, and we haven't reported an error, we must report UndefinedError whether we had stray prints or not. If a handler returns success, we should *not* report UndefinedError just because it had stray prints. A stray print does not necessarily imply command failure, and hence a stray print should not make an otherwise successful command fail. Adding a suitable mechanism to alert developers to stray prints is fine. But abusing error replies for that is not. > 2. We have agreed that multiple faults are not allowed and that > reporting only the first one is fine. In shallow conversion (or > even in buggy conversions) we can get multiple faults and we have > to handle it Reporting only the first one sucks when it's an UndefinedError triggered by a stray print, while one of the other ones is the real error. > So, the situation will be improved by my next series as we can > use the return code to 'audit' qemu_error_new() usage (which > includes monitor_printf() calls). Yes.
[Qemu-devel] [PATCH 4/4] target-arm: neon fix
From: Juha Riihimäki
add an extra check in "two registers and a shift" to ensure element
size decoding logic cannot fail.
Signed-off-by: Juha Riihimäki
Signed-off-by: Riku Voipio
---
target-arm/translate.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/target-arm/translate.c b/target-arm/translate.c
index 743b846..8bba034 100644
--- a/target-arm/translate.c
+++ b/target-arm/translate.c
@@ -4567,8 +4567,9 @@ static int disas_neon_data_insn(CPUState * env,
DisasContext *s, uint32_t insn)
size = 3;
} else {
size = 2;
-while (size && (insn & (1 << (size + 19))) == 0)
+while (size && (insn & (1 << (size + 19))) == 0) {
size--;
+}
}
shift = (insn >> 16) & ((1 << (3 + size)) - 1);
/* To avoid excessive dumplication of ops we implement shift
--
1.6.5
[Qemu-devel] [PATCH 0/4] arm/neon fixes
From: Riku Voipio "neon emulation enhancements" was already sent earlier, other patches are new. vshll and vraddhn fixes are needed to pass the pixman testsuite when pixman is compiled with NEON support. Thanks to Siamashka Siarhei for pointing us to this testsuite. Also available from: git clone git://gitorious.org/qemu-maemo/qemu-maemo.git arm-fixes-for-upstream Juha Riihimäki (3): target-arm: neon vshll instruction fix target-arm: neon emulation enhancements target-arm: neon fix Riku Voipio (1): target-arm: neon - fix VRADDHN/VRSUBHN and VADDHN/VSUBHN target-arm/translate.c | 456 +--- 1 files changed, 280 insertions(+), 176 deletions(-)
[Qemu-devel] [PATCH 1/4] target-arm: neon - fix VRADDHN/VRSUBHN vs VADDHN/VSUBHN
From: Riku Voipio
The rounding/truncating options were inverted. truncating
was done when rounding was meant and vice verse.
Signed-off-by: Riku Voipio
---
target-arm/translate.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/target-arm/translate.c b/target-arm/translate.c
index 5cf3e06..4bd813a 100644
--- a/target-arm/translate.c
+++ b/target-arm/translate.c
@@ -4957,7 +4957,7 @@ static int disas_neon_data_insn(CPUState * env,
DisasContext *s, uint32_t insn)
case 0: case 1: case 4: /* VADDL, VADDW, VADDHN, VRADDHN */
gen_neon_addl(size);
break;
-case 2: case 3: case 6: /* VSUBL, VSUBW, VSUBHL, VRSUBHL */
+case 2: case 3: case 6: /* VSUBL, VSUBW, VSUBHN, VRSUBHN */
gen_neon_subl(size);
break;
case 5: case 7: /* VABAL, VABDL */
@@ -5026,7 +5026,7 @@ static int disas_neon_data_insn(CPUState * env,
DisasContext *s, uint32_t insn)
} else if (op == 4 || op == 6) {
/* Narrowing operation. */
tmp = new_tmp();
-if (u) {
+if (!u) {
switch (size) {
case 0:
gen_helper_neon_narrow_high_u8(tmp, cpu_V0);
--
1.6.5
[Qemu-devel] [PATCH 2/4] target-arm: neon vshll instruction fix
From: Juha Riihimäki implementation only widened the 32bit source vector elements into a 64bit destination vector but forgot to perform the actual shifting operation. Signed-off-by: Juha Riihimäki Signed-off-by: Riku Voipio --- target-arm/translate.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/target-arm/translate.c b/target-arm/translate.c index 4bd813a..537d9d6 100644 --- a/target-arm/translate.c +++ b/target-arm/translate.c @@ -5385,6 +5385,7 @@ static int disas_neon_data_insn(CPUState * env, DisasContext *s, uint32_t insn) if (pass == 1) tmp = tmp2; gen_neon_widen(cpu_V0, tmp, size, 1); +tcg_gen_shli_i64(cpu_V0, cpu_V0, 8 << size); neon_store_reg64(cpu_V0, rd + pass); } break; -- 1.6.5
[Qemu-devel] [PATCH 3/4] target-arm: neon emulation enhancements
From: Juha Riihimäki
This patch improves the detection of undefined NEON data instruction
encodings, fixes bugs in some of the instruction decodings and adds an
implementation for 64bit wide vsli and vsri instructions.
Signed-off-by: Juha Riihimäki
Signed-off-by: Riku Voipio
---
target-arm/translate.c | 450 +---
1 files changed, 276 insertions(+), 174 deletions(-)
diff --git a/target-arm/translate.c b/target-arm/translate.c
index 537d9d6..743b846 100644
--- a/target-arm/translate.c
+++ b/target-arm/translate.c
@@ -4147,73 +4147,82 @@ static int disas_neon_data_insn(CPUState * env,
DisasContext *s, uint32_t insn)
if ((insn & (1 << 23)) == 0) {
/* Three register same length. */
op = ((insn >> 7) & 0x1e) | ((insn >> 4) & 1);
-if (size == 3 && (op == 1 || op == 5 || op == 8 || op == 9
- || op == 10 || op == 11 || op == 16)) {
-/* 64-bit element instructions. */
-for (pass = 0; pass < (q ? 2 : 1); pass++) {
-neon_load_reg64(cpu_V0, rn + pass);
-neon_load_reg64(cpu_V1, rm + pass);
-switch (op) {
-case 1: /* VQADD */
-if (u) {
-gen_helper_neon_add_saturate_u64(CPU_V001);
-} else {
-gen_helper_neon_add_saturate_s64(CPU_V001);
-}
-break;
-case 5: /* VQSUB */
-if (u) {
-gen_helper_neon_sub_saturate_u64(CPU_V001);
-} else {
-gen_helper_neon_sub_saturate_s64(CPU_V001);
-}
-break;
-case 8: /* VSHL */
-if (u) {
-gen_helper_neon_shl_u64(cpu_V0, cpu_V1, cpu_V0);
-} else {
-gen_helper_neon_shl_s64(cpu_V0, cpu_V1, cpu_V0);
-}
-break;
-case 9: /* VQSHL */
-if (u) {
-gen_helper_neon_qshl_u64(cpu_V0, cpu_env,
- cpu_V0, cpu_V0);
-} else {
-gen_helper_neon_qshl_s64(cpu_V1, cpu_env,
- cpu_V1, cpu_V0);
-}
-break;
-case 10: /* VRSHL */
-if (u) {
-gen_helper_neon_rshl_u64(cpu_V0, cpu_V1, cpu_V0);
-} else {
-gen_helper_neon_rshl_s64(cpu_V0, cpu_V1, cpu_V0);
-}
-break;
-case 11: /* VQRSHL */
-if (u) {
-gen_helper_neon_qrshl_u64(cpu_V0, cpu_env,
- cpu_V1, cpu_V0);
-} else {
-gen_helper_neon_qrshl_s64(cpu_V0, cpu_env,
- cpu_V1, cpu_V0);
-}
-break;
-case 16:
-if (u) {
-tcg_gen_sub_i64(CPU_V001);
-} else {
-tcg_gen_add_i64(CPU_V001);
+if (op == 24 || op == 25 || (q && ((rd | rn | rm) & 1))) {
+return 1;
+}
+if (size == 3) {
+if (op == 1 || op == 5 || op == 8 || op == 9 || op == 10
+|| op == 11 || op == 16) {
+/* 64-bit element instructions. */
+for (pass = 0; pass < (q ? 2 : 1); pass++) {
+neon_load_reg64(cpu_V0, rn + pass);
+neon_load_reg64(cpu_V1, rm + pass);
+switch (op) {
+case 1: /* VQADD */
+if (u) {
+gen_helper_neon_add_saturate_u64(CPU_V001);
+} else {
+gen_helper_neon_add_saturate_s64(CPU_V001);
+}
+break;
+case 5: /* VQSUB */
+if (u) {
+gen_helper_neon_sub_saturate_u64(CPU_V001);
+} else {
+gen_helper_neon_sub_saturate_s64(CPU_V001);
+}
+break;
+case 8: /* VSHL */
+if (u) {
+gen_helper_neon_shl_u64(cpu_V0, cpu_V1, cpu_V0);
+} else {
+gen_helper_neon_shl_s64(cpu_V0, cpu_V1, cpu_V0);
+}
+break;
+case 9: /* VQSHL */
+if (u) {
+gen_helper_neon_qshl_u64(cpu_V0, cpu_env,
+
Re: [Qemu-devel] [PATCH 1/4] qjson: Improve debugging
On 02/05/2010 06:12 AM, Luiz Capitulino wrote: On Thu, 04 Feb 2010 16:31:46 -0600 Anthony Liguori wrote: On 02/04/2010 02:13 PM, Luiz Capitulino wrote: Add an assert() to qobject_from_jsonf() to assure that the returned QObject is not NULL. Currently this is duplicated in the callers. Signed-off-by: Luiz Capitulino --- qjson.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/qjson.c b/qjson.c index 9ad8a91..0922c06 100644 --- a/qjson.c +++ b/qjson.c @@ -62,6 +62,7 @@ QObject *qobject_from_jsonf(const char *string, ...) obj = qobject_from_jsonv(string,&ap); va_end(ap); +assert(obj != NULL); This is wrong. We may get JSON from an untrusted source. Callers need to deal with failure appropriately. What kind of untrusted source? This function is only used by handlers and assuming that the only possible error here is bad syntax, not having this check in the source will only duplicate it in the users. I don't know yet, but there's nothing about this function that indicates that it cannot handle malformed JSON. I don't think it's a reasonable expectation either. There are absolutely ways to mitigate this. You can use GCC macros to enforce at compile time that the string argument is always a literal and never a user supplied string. Run time asserts are a terrible way to deal with reasonably expected errors. Regards, Anthony Liguori
Re: [Qemu-devel] Re: kqemu and XP guest - lock-up at mup.sys
Gordan Bobic wrote: > Jan Kiszka wrote: > >Gordan Bobic wrote: > >Due to limitations of the x86 architecture, kqemu used to be far a way > >from providing accurate virtualization. > > KVM is subject to the same limitations, though, so that point is a bit > moot. No, it isn't. The VT/SVM extensions used by KVM support much more accurate virtualisation than the tricks used by kqemu. There are a few bugs and omissions in KVM itself, but for most things it's a high quality virtualisation. -- Jamie
Re: [Qemu-devel] [PATCH 2/4] block: add block topology options
Christoph Hellwig wrote: > On Wed, Feb 03, 2010 at 01:00:47PM -0600, Anthony Liguori wrote: > > But I don't think this is the wrong place to do it. The > > BlockDriverState reflects that backing device, not the emulated device > > itself. In this case, you're trying to set a property of the emulated > > device. > > I think that's very borderline. While the emulated device exposes these > properties, they are in fact a property of the backing storage, the > right sector and min/max I/O sizes are determined by the backing storage > device. > > > I think these need to be qdev properties of the respective devices. > > From a UI perspective, you can still expose -drive options for the end > > user to consume, but this data should be associated with the devices > > themselves. > > In addition to not really beeing more logical this would be a lot more > effort. We'd need to add properties to all the device, which means > including dealing with the n+1 ide variants, the virtio-pci proxy, etc. > > If you believe it really needs to be in the qdev properties I'll > implement it, but I suspect the current version is a better idea. If you move your VM to a new system with different backing devices, sometimes you want to be sure there is no guest-visible change. Or even if you just replace a drive - you might prefer confidence that the guest sees no change. Even if you just convert between qcow2 and a raw block device, or the other way, you'll sometimes want to be sure it's not guest-visible. -- Jamie
Re: [Qemu-devel] [PATCH 2/4] block: add block topology options
On Fri, Feb 05, 2010 at 04:16:20PM +, Jamie Lokier wrote: > If you move your VM to a new system with different backing devices, > sometimes you want to be sure there is no guest-visible change. Or > even if you just replace a drive - you might prefer confidence that > the guest sees no change. Yes, that's why we do not auto probe it but require it to be set manually. Note that not the physical block size attribute can we a data integrity issue, though. A storage device guarnatees that it can write a sector atomically, so moving from a 4k to a 512 byte physcical sector device could lead to not beeing able to atomically write a 4k piece of data that the guest expects to write atomcially. I'm not sure how failure safe the read-modify-write algorithms on 4k sector disks with logical 512 bye blocks are, but I'd expect issues there, too. > Even if you just convert between qcow2 and a raw block device, or the > other way, you'll sometimes want to be sure it's not guest-visible. The image format has no hooks into these options currently.
[Qemu-devel] Re: kqemu and XP guest - lock-up at mup.sys
Gordan Bobic wrote: > Jan Kiszka wrote: >> Gordan Bobic wrote: >>> Hi, >>> >>> It would appear that kqemu somehow breaks the XP guest under some >>> circumstances. >>> >>> If I install from scratch in qemu+kqemu, it works fine in kqemu, but not >>> on bare metal. The fact it doesn't work on bare metal COULD be related >>> to the fact that on bare metal I'm running off a USB stick (it's a >>> rescue system). >>> >>> If I install onto bare metal (again, onto a USB stick - I have a >>> modified installer that includes the USB disk drivers at setup stage) >>> and then start up that install in qemu, that works as long as I don't >>> apply kqemu. But if I modprobe kqemu and start with >>> -enable-kqemu/-kernel-kqemu (-smp 1 in all cases), the quest instanty >>> locks up at 100% CPU usage. Everything else about the qemu configuration >>> is exactly the same between the runs. Booting the system with -no-acpi >>> at this point causes it to reboot instead of just locking up. >>> >>> I tried with qemu 0.10.5 (RHEL5 from atrpms) and 0.11.1 (built from >>> source). kqemu I use is dkms 1.4.0pre1 from the Dag repository. >>> >>> With kqemu, the guest stops booting (including safe mode) at mup.sys. >>> Googling around for similar problems didn't reveal much of use (other >>> than the usual Windows solution to everything of "reinstall", which >>> isn't an option here because I need the same setup to work both on bare >>> metal and in qemu). Is there a work-around/tweak to make this work? Is >>> there any particular reason why kqemu would break things under these >>> circumstances when running without kqemu works fine, if slower? Is there >>> a difference in how the emulated hardware looks/behaves with and without >>> kqemu? >> >> Due to limitations of the x86 architecture, kqemu used to be far a way >> from providing accurate virtualization. > > KVM is subject to the same limitations, though, so that point is a bit > moot. The only reason why I'm using kqemu is because I still have legacy > 32-bit hardware around that doesn't have VT extensions. As Jamie already pointed out, your perception of KVM is not correct. But the issue of legacy hardware exists, no question. Just the effort to keep it working is beyond reasonable limits. > > Either way, I'm mainly interested in the details of the differences in > the environment provided by qemu with and without kqemu, as clearly it > is this difference that causes the problem in question. The differences are various and subtle. If you want to understand them (you do not, believe me), look at the code of kqemu or even debug it - under KVM like we did. But, again, you do not want to do this... Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH 3/4] QError: Don't abort on multiple faults
On Fri, 05 Feb 2010 16:15:56 +0100 Markus Armbruster wrote: > Luiz Capitulino writes: > > > On Fri, 05 Feb 2010 15:21:13 +0100 > > Markus Armbruster wrote: > > > >> Markus Armbruster writes: > >> > >> > Luiz Capitulino writes: > >> > > >> >> Ideally, Monitor code should report an error only once and > >> >> return the error information up the call chain. > >> >> > >> >> To assure that this happens as expected and that no error is > >> >> lost, we have an assert() in qemu_error_internal(). > >> >> > >> >> However, we still have not fully converted handlers using > >> >> monitor_printf() to report errors. As there can be multiple > >> >> monitor_printf() calls on an error, the assertion is easily > >> >> triggered when debugging is enabled; and we will get a memory > >> >> leak if it's not. > >> >> > >> >> The solution to this problem is to allow multiple faults by only > >> >> reporting the first one, and to release the additional error objects. > >> > > >> > I want this badly. > >> > > >> > [...] > >> > >> Let me elaborate a bit. While this patch is a much wanted improvement, > >> what I *really* want is something else. > >> > >> Right now, we have 41 uses of qemu_error_new(). We still have >300 uses > >> of monitor_printf(), many of them errors. Plus some 100 uses of > >> qemu_error(), which boils down to monitor_printf() when running within a > >> monitor. Not to mention >1000 uses of stderr. > >> > >> To convert a monitor handler to QError, we have to make it report > >> exactly one error on every unsuccessful path, with qemu_error_new(). > >> That's not too hard. Then we have to ensure it does not call > >> monitor_printf() directly (not hard either) or indirectly (ouch). I say > >> "ouch", because those prints can hide behind long call chains, in code > >> shared with other users. Cleaning up all those stray prints will take > >> time. > > > > As we have talked, this situation will be improved by making cmd_new > > return an error code, right? > > Yes. > > > I've started working on it already, patches will be sent soon. > > Excellent. > > >> Without this patch, a stray print is fatal, unless it happens to be the > >> only one *and* there is no real error. > >> > >> With this patch, we survive, but the UndefinedError triggered by the > >> stray print displaces any later real error. > >> > >> What I really want is that stray prints do not mess with my real errors. > > > > There are two issues here: > > > > 1. In command handlers stray prints _usually_ report errors. If we go > > with shallow conversion, I believe that clients should be informed > > (in the form of an undefined error) that monitor_printf() has been > > called > > It's not so easy. > > A command should report an error if and only if it really failed. > Reporting an error even though the command succeeded is just as bad as > not reporting an error when it failed. > > Barring bugs, a handler *knows* whether it got the job done or not. It > can and should communicate that knowledge up by returning status. I > understand one of your next patch series will do that. Yes. > If a handler returns failure, and we haven't reported an error, we must > report UndefinedError whether we had stray prints or not. Agreed and the stray prints have to reported to the developer. > If a handler returns success, we should *not* report UndefinedError just > because it had stray prints. A stray print does not necessarily imply > command failure, and hence a stray print should not make an otherwise > successful command fail. Right, but a stray print which is not reporting an error and which is not just OK, is returning data. We have to detect this, because this has to be done by using the QObject API and shallow conversion can't miss that. I'm not saying we should use UndefinedError, I'm saying we have to have a mechanism to detect this reliably. Unfortunately this can only be detected at run time.
Re: [Qemu-devel] [PATCH 1/4] qjson: Improve debugging
Anthony Liguori writes: > On 02/05/2010 06:12 AM, Luiz Capitulino wrote: >> On Thu, 04 Feb 2010 16:31:46 -0600 >> Anthony Liguori wrote: >> >> >>> On 02/04/2010 02:13 PM, Luiz Capitulino wrote: >>> Add an assert() to qobject_from_jsonf() to assure that the returned QObject is not NULL. Currently this is duplicated in the callers. Signed-off-by: Luiz Capitulino --- qjson.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/qjson.c b/qjson.c index 9ad8a91..0922c06 100644 --- a/qjson.c +++ b/qjson.c @@ -62,6 +62,7 @@ QObject *qobject_from_jsonf(const char *string, ...) obj = qobject_from_jsonv(string,&ap); va_end(ap); +assert(obj != NULL); >>> This is wrong. We may get JSON from an untrusted source. Callers need >>> to deal with failure appropriately. >>> >> What kind of untrusted source? This function is only used by handlers >> and assuming that the only possible error here is bad syntax, not having >> this check in the source will only duplicate it in the users. >> > > I don't know yet, but there's nothing about this function that > indicates that it cannot handle malformed JSON. I don't think it's a > reasonable expectation either. > > There are absolutely ways to mitigate this. You can use GCC macros to > enforce at compile time that the string argument is always a literal > and never a user supplied string. A string literal always comes from the programmer, not the user, but the converse is not true. Therefore, I don't see why we should make the function unusable with non-literal arguments. But if you really want -Wformat-nonliteral, you know where to find it :) > Run time asserts are a terrible way to deal with reasonably expected errors. Yes. But what's reasonably expected entirely depends on the contract between the function and its callers. I think we need a function that cannot fail and shouldn't used with untrusted arguments (for what it's worth, that's how we use qobject_from_jsonf() now). Having related functions with different contracts is fine with me.
Re: [Qemu-devel] [PATCH 2/4] block: add block topology options
Christoph Hellwig wrote: > Note that not the physical block size attribute can > we a data integrity issue, though. I agree. > A storage device guarnatees that it can write a sector atomically, I've looked everywhere for confirmation of *atomicity*, and so far all I've seen are rumours. Some people believe sector writes are atomic during power failure, some people believe they are not. Those who believe it is, don't have reliable references, and I haven't seen it in any standard. SQLite has a flag which can be set for a backing store to say block writes are atomic, to enable it to optimise some things; the flag is not set when writing to a disk block device, because they didn't find confirmation of it. > so moving from a 4k to a 512 byte physcical sector device could lead > to not beeing able to atomically write a 4k piece of data that the > guest expects to write atomcially. If there is no confirmation that sector writes are atomic, then no database or filesystem should be relying on that property anyway. > I'm not sure how failure safe the read-modify-write algorithms on > 4k sector disks with logical 512 bye blocks are, but I'd expect issues > there, too. I think you might be referring to what I'm calling "radius of destruction", because I don't know if there's a well known term for it. By that I mean if you write 512 bytes, and it's implemented as RMW to a 4k sector, then on power failure any part of the 4k sector could be corrupted. On some RAIDs the size is much larger; also on many flash devices. (RAIDs make it clearer that the alignment is relevant too.) Note that if 4k sector writes were _atomic_, then read-modify-write of 512 bytes would be completely reliable. > > Even if you just convert between qcow2 and a raw block device, or the > > other way, you'll sometimes want to be sure it's not guest-visible. > > The image format has no hooks into these options currently. No, but whatever is reported to the guest, you may device you want it to continue being reported to the guest after doing the convert operation. Even if it's a data integrity concern. In fact *precisely* when the guest has algorithms which write differently depending on the sector size, for integrity, that means changing the guest-visible sector size may trigger bugs and other changes that you sometimes don't want. I agree that it should report the size by default, though, because the integrity concern. -- Jamie
Re: [Qemu-devel] [PATCH 2/4] block: add block topology options
On 02/05/2010 07:09 AM, Christoph Hellwig wrote: On Wed, Feb 03, 2010 at 01:00:47PM -0600, Anthony Liguori wrote: But I don't think this is the wrong place to do it. The BlockDriverState reflects that backing device, not the emulated device itself. In this case, you're trying to set a property of the emulated device. I think that's very borderline. While the emulated device exposes these properties, they are in fact a property of the backing storage, the right sector and min/max I/O sizes are determined by the backing storage device. It's guest visible state that should be configured based on the properties of the backing store. However, as you said, live migration complicates things. drive is not an optimal interface because it mixes host and guest state. But the subset of -drive that you normally use should be independent of the guest. For instance, with: -drive file=/home/anthony/foo.img,cache=off,aio=native,id=foo -device virtio-blk-pci,drive=foo file, cache, and aio are all host properties. They have no visible impact to the guest and if I change those properties during live migration, they take affect without the guest noticing These topology options still can be specified via -drive, but the proper way of splitting things would have them as part of the -device option. During live migration, things on the -device side inherited as part of the live migration process. I think these need to be qdev properties of the respective devices. From a UI perspective, you can still expose -drive options for the end user to consume, but this data should be associated with the devices themselves. In addition to not really beeing more logical this would be a lot more effort. We'd need to add properties to all the device, which means including dealing with the n+1 ide variants, the virtio-pci proxy, etc. The way we deal with this with network devices is we have a common DEFINE_NIC_PROPERTIES that lets us consistently add properties for all network devices. We need exactly this sort of thing for disk drives for the reason you describe. If you believe it really needs to be in the qdev properties I'll implement it, but I suspect the current version is a better idea. It definitely a correctness issue. Once we can describe the full PC via qdev, we want to be able to migrate that description as part of the migration traffic. For that to work, we need to have all of the device characteristics expressed as qdev properties. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH v2 RESEND 0/5] clang fixes
Thanks, applied. On Thu, Feb 4, 2010 at 3:31 PM, Paolo Bonzini wrote: > I removed the patch that malc NACKed. > > Paolo Bonzini (5): > remove two dead assignments in target-i386/translate.c > fix undefined shifts by >32 > exec.c: dead assignments > vnc.c: remove dead code > usb-linux.c: remove write-only variable > > exec.c | 4 > target-i386/translate.c | 2 -- > usb-linux.c | 2 -- > vl.c | 4 ++-- > vnc.c | 3 --- > 5 files changed, 2 insertions(+), 13 deletions(-) > > > >
[Qemu-devel] rtl8139 timer interrupt rewrote
Hi,
I rewrote timer implementation for this card. I wrote even a small
Linux guest test program (attached as main.c). This patch add a QEMU
timer only when needed (timeout status not set, timeout irq wanted and
timer set). I tested this patch with a Darwin system and with my test
program (I bought a compatible physical card and it works too).
Regards
Frediano Ziglio
--- hw/rtl8139.c.orig 2010-01-14 23:17:59.0 +0100
+++ hw/rtl8139.c 2010-02-05 20:25:31.711462995 +0100
@@ -34,41 +34,44 @@
* Implemented Tally Counters, increased VM load/save version
* Implemented IP/TCP/UDP checksum task offloading
*
* 2006-Jul-04 Igor Kovalenko : Implemented TCP segmentation offloading
* Fixed MTU=1500 for produced ethernet frames
*
* 2006-Jul-09 Igor Kovalenko : Fixed TCP header length calculation while processing
* segmentation offloading
* Removed slirp.h dependency
* Added rx/tx buffer reset when enabling rx/tx operation
+ *
+ * 2009-Feb-04 Frediano Ziglio: Rewrote timer support using QEMU timer only when strictly
+ * needed (required for for Darwin)
*/
#include "hw.h"
#include "pci.h"
#include "qemu-timer.h"
#include "net.h"
#include "loader.h"
/* debug RTL8139 card */
//#define DEBUG_RTL8139 1
#define PCI_FREQUENCY 3300L
/* debug RTL8139 card C+ mode only */
//#define DEBUG_RTL8139CP 1
/* Calculate CRCs properly on Rx packets */
#define RTL8139_CALCULATE_RXCRC 1
/* Uncomment to enable on-board timer interrupts */
-//#define RTL8139_ONBOARD_TIMER 1
+#define RTL8139_ONBOARD_TIMER 1
#if defined(RTL8139_CALCULATE_RXCRC)
/* For crc32 */
#include
#endif
#define SET_MASKED(input, mask, curr) \
( ( (input) & ~(mask) ) | ( (curr) & (mask) ) )
/* arg % size for size which is a power of 2 */
@@ -482,25 +485,34 @@ typedef struct RTL8139State {
int64_tTCTR_base;
/* Tally counters */
RTL8139TallyCounters tally_counters;
/* Non-persistent data */
uint8_t *cplus_txbuffer;
intcplus_txbuffer_len;
intcplus_txbuffer_offset;
+#ifdef RTL8139_ONBOARD_TIMER
/* PCI interrupt timer */
QEMUTimer *timer;
+int64_t TimerExpire;
+#endif
} RTL8139State;
+#ifdef RTL8139_ONBOARD_TIMER
+static void rtl8139_set_next_tctr_time(RTL8139State *s, int64_t current_time);
+#else
+#define rtl8139_set_next_tctr_time(s,t) do { ; } while(0)
+#endif
+
static void prom9346_decode_command(EEprom9346 *eeprom, uint8_t command)
{
DEBUG_PRINT(("RTL8139: eeprom command 0x%02x\n", command));
switch (command & Chip9346_op_mask)
{
case Chip9346_op_read:
{
eeprom->address = command & EEPROM_9346_ADDR_MASK;
eeprom->output = eeprom->contents[eeprom->address];
@@ -2510,21 +2522,23 @@ static uint32_t rtl8139_RxBuf_read(RTL81
static void rtl8139_IntrMask_write(RTL8139State *s, uint32_t val)
{
DEBUG_PRINT(("RTL8139: IntrMask write(w) val=0x%04x\n", val));
/* mask unwriteable bits */
val = SET_MASKED(val, 0x1e00, s->IntrMask);
s->IntrMask = val;
+rtl8139_set_next_tctr_time(s, qemu_get_clock(vm_clock));
rtl8139_update_irq(s);
+
}
static uint32_t rtl8139_IntrMask_read(RTL8139State *s)
{
uint32_t ret = s->IntrMask;
DEBUG_PRINT(("RTL8139: IntrMask read(w) val=0x%04x\n", ret));
return ret;
}
@@ -2543,26 +2557,36 @@ static void rtl8139_IntrStatus_write(RTL
uint16_t newStatus = s->IntrStatus & ~val;
/* mask unwriteable bits */
newStatus = SET_MASKED(newStatus, 0x1e00, s->IntrStatus);
/* writing 1 to interrupt status register bit clears it */
s->IntrStatus = 0;
rtl8139_update_irq(s);
s->IntrStatus = newStatus;
+/*
+ * Computing if we miss an interrupt here is not that correct but
+ * considered that we should have had already an interrupt
+ * and probably emulated is slower is better to assume this resetting was done before
+ * testing on previous rtl8139_update_irq lead to IRQ loosing
+ */
+rtl8139_set_next_tctr_time(s, qemu_get_clock(vm_clock));
rtl8139_update_irq(s);
+
#endif
}
static uint32_t rtl8139_IntrStatus_read(RTL8139State *s)
{
+rtl8139_set_next_tctr_time(s, qemu_get_clock(vm_clock));
+
uint32_t ret = s->IntrStatus;
DEBUG_PRINT(("RTL8139: IntrStatus read(w) val=0x%04x\n", ret));
#if 0
/* reading ISR clears all interrupts */
s->IntrStatus = 0;
rtl8139_update_irq(s);
@@ -2727,20 +2751,56 @@ static void rtl8139_io_writew(void *opaq
default:
DEBUG_PRINT(("RTL8139: ioport write(w) addr=0x%x val=0x%04x via write(b)\n", addr, val));
rtl8139_io_writeb(opaque, addr, val & 0xff);
rtl8139_io_writeb(
[Qemu-devel] [RFC] Documentation
The following patches enhance the existing documentation. They contain several parts marked with TODO where information is still missing, so feedback is welcome. They also add an index, or even several of them. There are many ways to organize an index, so I need feedback here, too. Overview of patches: Documentation: Add build support for documentation in pdf format (unmodified resend) Documentation: Add direntry for info format Documentation: Use UTF-8 encoding and fix one wrong encoding Documentation: Add some basic documentation on make targets Documentation: Fix item list Documentation: Enhance documentation (index, keywords) Documentation: Add monitor commands to function index Documentation: Add command line options to function index Regards Stefan Weil
[Qemu-devel] [PATCH 1/8] Documentation: Add build support for documentation in pdf format
Makefile already supported dvi, html and info formats,
but pdf was missing.
pdf is especially convenient for printing and for
documentation reviews. I hope it will help to
improve qemu's documentation.
Make now supports the new target 'pdf' which will
create qemu-doc.pdf and qemu-tech.pdf. It is also
possible to build both files individually.
texi2pdf and texi2dvi are rather noisy, so normally
some less important warnings are suppressed.
When make is called with V=1 (verbose mode),
warnings are not suppressed.
The patch also sorts the documentation targets
alphabetically and wraps a line which was too long.
Signed-off-by: Stefan Weil
---
.gitignore |1 +
Makefile | 21 +
2 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/.gitignore b/.gitignore
index d7d2146..dfc8e5b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -36,6 +36,7 @@ qemu-monitor.texi
*.fn
*.ky
*.log
+*.pdf
*.pg
*.toc
*.tp
diff --git a/Makefile b/Makefile
index 24938db..c72a059 100644
--- a/Makefile
+++ b/Makefile
@@ -22,7 +22,7 @@ Makefile: ;
configure: ;
.PHONY: all clean cscope distclean dvi html info install install-doc \
- recurse-all speed tar tarbin test build-all
+ pdf recurse-all speed tar tarbin test build-all
$(call set-vpath, $(SRC_PATH):$(SRC_PATH)/hw)
@@ -160,7 +160,7 @@ distclean: clean
rm -f config-host.mak config-host.h* config-host.ld $(DOCS)
qemu-options.texi qemu-img-cmds.texi qemu-monitor.texi
rm -f config-all-devices.mak
rm -f roms/seabios/config.mak roms/vgabios/config.mak
- rm -f qemu-{doc,tech}.{info,aux,cp,dvi,fn,info,ky,log,pg,toc,tp,vr}
+ rm -f qemu-{doc,tech}.{info,aux,cp,dvi,fn,info,ky,log,pdf,pg,toc,tp,vr}
for d in $(TARGET_DIRS) libhw32 libhw64 libuser; do \
rm -rf $$d || exit 1 ; \
done
@@ -224,14 +224,18 @@ cscope:
cscope -b
# documentation
+TEXIFLAG=$(if $(V),,--quiet)
+%.dvi: %.texi
+ $(call quiet-command,texi2dvi $(TEXIFLAG) -I . $<," GEN $@")
+
%.html: %.texi
$(call quiet-command,texi2html -I=. -monolithic -number $<," GEN $@")
%.info: %.texi
$(call quiet-command,makeinfo -I . $< -o $@," GEN $@")
-%.dvi: %.texi
- $(call quiet-command,texi2dvi -I . $<," GEN $@")
+%.pdf: %.texi
+ $(call quiet-command,texi2pdf $(TEXIFLAG) -I . $<," GEN $@")
qemu-options.texi: $(SRC_PATH)/qemu-options.hx
$(call quiet-command,sh $(SRC_PATH)/hxtool -t < $< > $@," GEN $@")
@@ -260,13 +264,14 @@ qemu-nbd.8: qemu-nbd.texi
pod2man --section=8 --center=" " --release=" " qemu-nbd.pod > $@, \
" GEN $@")
-info: qemu-doc.info qemu-tech.info
-
dvi: qemu-doc.dvi qemu-tech.dvi
-
html: qemu-doc.html qemu-tech.html
+info: qemu-doc.info qemu-tech.info
+pdf: qemu-doc.pdf qemu-tech.pdf
-qemu-doc.dvi qemu-doc.html qemu-doc.info: qemu-img.texi qemu-nbd.texi
qemu-options.texi qemu-monitor.texi qemu-img-cmds.texi
+qemu-doc.dvi qemu-doc.html qemu-doc.info qemu-doc.pdf: \
+ qemu-img.texi qemu-nbd.texi qemu-options.texi \
+ qemu-monitor.texi qemu-img-cmds.texi
VERSION ?= $(shell cat VERSION)
FILE = qemu-$(VERSION)
--
1.6.5
[Qemu-devel] [PATCH 3/8] Documentation: Use UTF-8 encoding and fix one wrong encoding
At least for Linux distributions UTF-8 is now standard, so the QEMU documentation should use this encoding, too. Even if there was currently only a single special character using ISO-8859-1, this might change in the future. So the texinfo keywords @documentlanguage and @documentencoding now document the language and the encoding. The special character was changed to UTF-8 (it could also have been changed to an x, but the original cross looks really nice if it is displayed correctly). These changes fix the html presentation at http://www.qemu.org/qemu-doc.html#SEC65 (ARM System emulator). Signed-off-by: Stefan Weil --- qemu-doc.texi |6 +- qemu-tech.texi |4 2 files changed, 9 insertions(+), 1 deletions(-) diff --git a/qemu-doc.texi b/qemu-doc.texi index eba6437..84de318 100644 --- a/qemu-doc.texi +++ b/qemu-doc.texi @@ -1,6 +1,10 @@ \input texinfo @c -*- texinfo -*- @c %**start of header @setfilename qemu-doc.info + +...@documentlanguage en +...@documentencoding UTF-8 + @settitle QEMU Emulator User Documentation @exampleindent 0 @paragraphindent 0 @@ -1831,7 +1835,7 @@ MV88W8xx8 Ethernet controller @item MV88W8618 audio controller, WM8750 CODEC and mixer @item -128×64 display with brightness control +128Ã64 display with brightness control @item 2 buttons, 2 navigation wheels with button function @end itemize diff --git a/qemu-tech.texi b/qemu-tech.texi index 52560dc..2e2a081 100644 --- a/qemu-tech.texi +++ b/qemu-tech.texi @@ -1,6 +1,10 @@ \input texinfo @c -*- texinfo -*- @c %**start of header @setfilename qemu-tech.info + +...@documentlanguage en +...@documentencoding UTF-8 + @settitle QEMU Internals @exampleindent 0 @paragraphindent 0 -- 1.6.5
[Qemu-devel] [PATCH 5/8] Documentation: Fix item list
@itemize @minus does not work as expected (the items start with "* -"). A simple @itemize gives a better result. Signed-off-by: Stefan Weil --- qemu-doc.texi |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/qemu-doc.texi b/qemu-doc.texi index 8ecd175..4ac3183 100644 --- a/qemu-doc.texi +++ b/qemu-doc.texi @@ -58,7 +58,7 @@ achieve good emulation speed. QEMU has two operating modes: -...@itemize @minus +...@itemize @item Full system emulation. In this mode, QEMU emulates a full system (for -- 1.6.5
[Qemu-devel] [PATCH 2/8] Documentation: Add direntry for info format
update-info-dir maintains an index of all available documentation in info format (the file /usr/share/info/dir). It reads special @direntry tags in info files. This patch (extracted from a larger patch provided by Dirk Ullrich) adds these tags for qemu-doc.info and qemu-tech.info. Signed-off-by: Stefan Weil --- qemu-doc.texi |6 ++ qemu-tech.texi |6 ++ 2 files changed, 12 insertions(+), 0 deletions(-) diff --git a/qemu-doc.texi b/qemu-doc.texi index 2fb5c0b..eba6437 100644 --- a/qemu-doc.texi +++ b/qemu-doc.texi @@ -6,6 +6,12 @@ @paragraphindent 0 @c %**end of header +...@ifinfo +...@direntry +* QEMU: (qemu-doc).The QEMU Emulator User Documentation. +...@end direntry +...@end ifinfo + @iftex @titlepage @sp 7 diff --git a/qemu-tech.texi b/qemu-tech.texi index 97d8dea..52560dc 100644 --- a/qemu-tech.texi +++ b/qemu-tech.texi @@ -6,6 +6,12 @@ @paragraphindent 0 @c %**end of header +...@ifinfo +...@direntry +* QEMU Internals: (qemu-tech). The QEMU Emulator Internals. +...@end direntry +...@end ifinfo + @iftex @titlepage @sp 7 -- 1.6.5
[Qemu-devel] [PATCH 7/8] Documentation: Add monitor commands to function index
* Add monitor commands to function index.
* Fix description for acl_remove.
Signed-off-by: Stefan Weil
---
qemu-monitor.hx | 62 ++-
1 files changed, 61 insertions(+), 1 deletions(-)
diff --git a/qemu-monitor.hx b/qemu-monitor.hx
index e5bff8e..cf9e430 100644
--- a/qemu-monitor.hx
+++ b/qemu-monitor.hx
@@ -19,6 +19,7 @@ ETEXI
STEXI
@item help or ? [...@var{cmd}]
+...@findex help
Show the help for all commands or just for command @var{cmd}.
ETEXI
@@ -32,6 +33,7 @@ ETEXI
STEXI
@item commit
+...@findex commit
Commit changes to the disk images (if -snapshot is used) or backing files.
ETEXI
@@ -46,6 +48,7 @@ ETEXI
STEXI
@item info @var{subcommand}
+...@findex info
Show various information about the system state.
@table @option
@@ -125,6 +128,7 @@ ETEXI
STEXI
@item q or quit
+...@findex quit
Quit the emulator.
ETEXI
@@ -139,6 +143,7 @@ ETEXI
STEXI
@item eject [-f] @var{device}
+...@findex eject
Eject a removable medium (use -f to force it).
ETEXI
@@ -153,6 +158,7 @@ ETEXI
STEXI
@item change @var{device} @var{setting}
+...@findex change
Change the configuration of a device.
@@ -198,6 +204,7 @@ ETEXI
STEXI
@item screendump @var{filename}
+...@findex screendump
Save screen into PPM image @var{filename}.
ETEXI
@@ -211,6 +218,7 @@ ETEXI
STEXI
@item logfile @var{filename}
+...@findex logfile
Output logs to @var{filename}.
ETEXI
@@ -224,6 +232,7 @@ ETEXI
STEXI
@item log @var{item1}[,...]
+...@findex log
Activate logging of the specified items to @file{/tmp/qemu.log}.
ETEXI
@@ -237,6 +246,7 @@ ETEXI
STEXI
@item savevm [...@var{tag}|@var{id}]
+...@findex savevm
Create a snapshot of the whole virtual machine. If @var{tag} is
provided, it is used as human readable identifier. If there is already
a snapshot with the same tag or ID, it is replaced. More info at
@@ -253,6 +263,7 @@ ETEXI
STEXI
@item loadvm @var{tag}|@var{id}
+...@findex loadvm
Set the whole virtual machine to the snapshot identified by the tag
@var{tag} or the unique snapshot ID @var{id}.
ETEXI
@@ -267,6 +278,7 @@ ETEXI
STEXI
@item delvm @var{tag}|@var{id}
+...@findex delvm
Delete the snapshot identified by @var{tag} or @var{id}.
ETEXI
@@ -280,6 +292,7 @@ ETEXI
STEXI
@item singlestep [off]
+...@findex singlestep
Run the emulation in single step mode.
If called with option off, the emulation returns to normal mode.
ETEXI
@@ -295,6 +308,7 @@ ETEXI
STEXI
@item stop
+...@findex stop
Stop emulation.
ETEXI
@@ -309,6 +323,7 @@ ETEXI
STEXI
@item c or cont
+...@findex cont
Resume emulation.
ETEXI
@@ -322,6 +337,7 @@ ETEXI
STEXI
@item gdbserver [...@var{port}]
+...@findex gdbserver
Start gdbserver session (default @var{port}=1234)
ETEXI
@@ -335,6 +351,7 @@ ETEXI
STEXI
@item x/fmt @var{addr}
+...@findex x
Virtual memory dump starting at @var{addr}.
ETEXI
@@ -348,6 +365,7 @@ ETEXI
STEXI
@item xp /@var{fmt} @var{addr}
+...@findex xp
Physical memory dump starting at @var{addr}.
@var{fmt} is a format which tells the command how to format the
@@ -355,13 +373,16 @@ data. Its syntax is: @option{/@{co...@}@{for...@}@{s...@}}
@table @var
@item count
+...@findex count
is the number of items to be dumped.
@item format
+...@findex format
can be x (hex), d (signed decimal), u (unsigned decimal), o (octal),
c (char) or i (asm instruction).
@item size
+...@findex size
can be b (8 bits), h (16 bits), w (32 bits) or g (64 bits). On x86,
@code{h} or @code{w} can be specified with the @code{i} format to
respectively select 16 or 32 bit code instruction size.
@@ -414,6 +435,7 @@ ETEXI
STEXI
@item p or print/@var{fmt} @var{expr}
+...@findex print
Print expression value. Only the @var{format} part of @var{fmt} is
used.
@@ -453,6 +475,7 @@ ETEXI
STEXI
@item sendkey @var{keys}
+...@findex sendkey
Send @var{keys} to the emulator. @var{keys} could be the name of the
key or @code{#} followed by the raw value in either decimal or hexadecimal
@@ -476,6 +499,7 @@ ETEXI
STEXI
@item system_reset
+...@findex system_reset
Reset the system.
ETEXI
@@ -491,6 +515,7 @@ ETEXI
STEXI
@item system_powerdown
+...@findex system_powerdown
Power down the system (if supported).
ETEXI
@@ -505,6 +530,7 @@ ETEXI
STEXI
@item sum @var{addr} @var{size}
+...@findex sum
Compute the checksum of a memory region.
ETEXI
@@ -519,6 +545,7 @@ ETEXI
STEXI
@item usb_add @var{devname}
+...@findex usb_add
Add the USB device @var{devname}. For details of available devices see
@ref{usb_devices}
@@ -534,6 +561,7 @@ ETEXI
STEXI
@item usb_del @var{devname}
+...@findex usb_del
Remove the USB device @var{devname} from the QEMU virtual USB
hub. @var{devname} has the syntax @code{bus.addr}. Use the monitor
@@ -550,6 +578,7 @@ ETEXI
STEXI
@item device_add @var{config}
+...@findex device_add
Add device.
ETEXI
@@ -564,6 +593,7 @@ ETEXI
STEXI
@item device_del @var{id
[Qemu-devel] [PATCH 6/8] Documentation: Enhance documentation (index, keywords)
* Add some keywords for the concept index.
* Add some keywords for the keystroke index.
* Mark invalid or unclear documentation with TODO.
Is there a better proposal how to do this?
* Fix copy+paste error in ColdFire section
(options were copied from ARM).
* Fix documentation for Wine.
* Add placeholders for missing system emulations.
* Add placeholders for missing user emulation commands.
* Add an appendix with license (to be discussed).
* Add an appendix for every type of index which is
supported by texinfo. Currently, not all are used,
but this might change in the future.
Signed-off-by: Stefan Weil
---
qemu-doc.texi | 165 +---
1 files changed, 156 insertions(+), 9 deletions(-)
diff --git a/qemu-doc.texi b/qemu-doc.texi
index 4ac3183..3d723f6 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -37,6 +37,7 @@
* QEMU System emulator for non PC targets::
* QEMU User space emulator::
* compilation:: Compilation from the sources
+* License::
* Index::
@end menu
@end ifnottex
@@ -59,14 +60,17 @@ achieve good emulation speed.
QEMU has two operating modes:
@itemize
+...@cindex operating modes
@item
+...@cindex system emulation
Full system emulation. In this mode, QEMU emulates a full system (for
example a PC), including one or several processors and various
peripherals. It can be used to launch different Operating Systems
without rebooting the PC or to debug system code.
@item
+...@cindex user mode emulation
User mode emulation. In this mode, QEMU can launch
processes compiled for one CPU on another CPU. It can be used to
launch the Wine Windows API emulator (@url{http://www.winehq.org}) or
@@ -79,6 +83,8 @@ performance.
For system emulation, the following hardware targets are supported:
@itemize
+...@cindex emulated target systems
+...@cindex supported target systems
@item PC (x86 or x86_64 processor)
@item ISA PC (old style PC without PCI bus)
@item PREP (PowerPC processor)
@@ -106,7 +112,10 @@ For system emulation, the following hardware targets are
supported:
@item Petalogix Spartan 3aDSP1800 MMU ref design (MicroBlaze).
@end itemize
-For user emulation, x86, PowerPC, ARM, 32-bit MIPS, Sparc32/64,
ColdFire(m68k), CRISv32 and MicroBlaze CPUs are supported.
+...@cindex supported user mode targets
+For user emulation, x86 (32 and 64 bit), PowerPC (32 and 64 bit),
+ARM, MIPS (32 bit only), Sparc (32 and 64 bit),
+Alpha, ColdFire(m68k), CRISv32 and MicroBlaze CPUs are supported.
@node Installation
@chapter Installation
@@ -121,24 +130,29 @@ If you want to compile QEMU yourself, see
@ref{compilation}.
@node install_linux
@section Linux
+...@cindex installation (Linux)
If a precompiled package is available for your distribution - you just
have to install it. Otherwise, see @ref{compilation}.
@node install_windows
@section Windows
+...@cindex installation (Windows)
Download the experimental binary installer at
@url{http://www.free.oszoo.org/@/download.html}.
+TODO (no longer available)
@node install_mac
@section Mac OS X
Download the experimental binary installer at
@url{http://www.free.oszoo.org/@/download.html}.
+TODO (no longer available)
@node QEMU PC System emulator
@chapter QEMU PC System emulator
+...@cindex system emulation (PC)
@menu
* pcsys_introduction:: Introduction
@@ -229,6 +243,7 @@ CS4231A is the chip used in Windows Sound System and GUSMAX
products
@node pcsys_quickstart
@section Quick Start
+...@cindex quick start
Download and uncompress the linux image (@file{linux.img}) and type:
@@ -263,12 +278,15 @@ targets do not need a disk image.
During the graphical emulation, you can use the following keys:
@table @key
@item Ctrl-Alt-f
+...@kindex Ctrl-Alt-f
Toggle full screen
@item Ctrl-Alt-u
+...@kindex Ctrl-Alt-u
Restore the screen's un-scaled dimensions
@item Ctrl-Alt-n
+...@kindex Ctrl-Alt-n
Switch to virtual console 'n'. Standard console mappings are:
@table @emph
@item 1
@@ -280,30 +298,44 @@ Serial port
@end table
@item Ctrl-Alt
+...@kindex Ctrl-Alt
Toggle mouse and keyboard grab.
@end table
+...@kindex Ctrl-Up
+...@kindex Ctrl-Down
+...@kindex Ctrl-PageUp
+...@kindex Ctrl-PageDown
In the virtual consoles, you can use @key{Ctrl-Up}, @key{Ctrl-Down},
@key{Ctrl-PageUp} and @key{Ctrl-PageDown} to move in the back log.
+...@kindex Ctrl-a h
During emulation, if you are using the @option{-nographic} option, use
@key{Ctrl-a h} to get terminal commands:
@table @key
@item Ctrl-a h
+...@kindex Ctrl-a h
@item Ctrl-a ?
+...@kindex Ctrl-a ?
Print this help
@item Ctrl-a x
+...@kindex Ctrl-a x
Exit emulator
@item Ctrl-a s
+...@kindex Ctrl-a s
Save disk data back to file (if -snapshot)
@item Ctrl-a t
+...@kindex Ctrl-a t
Toggle console timestamps
@item Ctrl-a b
+...@kindex Ctrl-a b
Send break (magic sysrq in Linux)
@item Ctrl-a c
+...@kindex Ctrl-a c
Switch between console and monitor
@item Ctrl-a Ctrl-a
+...@kindex C
[Qemu-devel] [PATCH 4/8] Documentation: Add some basic documentation on make targets
This should help new users to get started. Signed-off-by: Stefan Weil --- qemu-doc.texi | 41 + 1 files changed, 41 insertions(+), 0 deletions(-) diff --git a/qemu-doc.texi b/qemu-doc.texi index 84de318..8ecd175 100644 --- a/qemu-doc.texi +++ b/qemu-doc.texi @@ -2286,6 +2286,7 @@ Run the emulation in single step mode. * Windows:: * Cross compilation for Windows with Linux:: * Mac OS X:: +* Make targets:: @end menu @node Linux/Unix @@ -2381,6 +2382,46 @@ The Mac OS X patches are not fully merged in QEMU, so you should look at the QEMU mailing list archive to have all the necessary information. +...@node Make targets +...@section Make targets + +...@table @code + +...@item make +...@item make all +Make everything which is typically needed. + +...@item install +TODO + +...@item install-doc +TODO + +...@item make clean +Remove most files which were built during make. + +...@item make distclean +Remove everything which was built during make. + +...@item make dvi +...@item make html +...@item make info +...@item make pdf +Create documentation in dvi, html, info or pdf format. + +...@item make cscope +TODO + +...@item make defconfig +(Re-)create some build configuration files. +User made changes will be overwritten. + +...@item tar +...@item tarbin +TODO + +...@end table + @node Index @chapter Index @printindex cp -- 1.6.5
[Qemu-devel] [PATCH 8/8] Documentation: Add command line options to function index
* Add line options to function index.
* Add description for -set (TODO).
* Add description for -global (TODO).
Signed-off-by: Stefan Weil
---
qemu-options.hx | 153 +--
1 files changed, 125 insertions(+), 28 deletions(-)
diff --git a/qemu-options.hx b/qemu-options.hx
index 4c1bcfb..0105da7 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -14,6 +14,7 @@ DEF("help", 0, QEMU_OPTION_h,
"-h or -help display this help and exit\n")
STEXI
@item -h
+...@findex -h
Display help and exit
ETEXI
@@ -21,6 +22,7 @@ DEF("version", 0, QEMU_OPTION_version,
"-versiondisplay version information and exit\n")
STEXI
@item -version
+...@findex -version
Display version information and exit
ETEXI
@@ -28,6 +30,7 @@ DEF("M", HAS_ARG, QEMU_OPTION_M,
"-M machine select emulated machine (-M ? for list)\n")
STEXI
@item -M @var{machine}
+...@findex -M
Select the emulated @var{machine} (@code{-M ?} for list)
ETEXI
@@ -35,6 +38,7 @@ DEF("cpu", HAS_ARG, QEMU_OPTION_cpu,
"-cpu cpuselect CPU (-cpu ? for list)\n")
STEXI
@item -cpu @var{model}
+...@findex -cpu
Select CPU model (-cpu ? for list and additional feature selection)
ETEXI
@@ -48,6 +52,7 @@ DEF("smp", HAS_ARG, QEMU_OPTION_smp,
"sockets= number of discrete sockets in the system\n")
STEXI
@item -smp
@var{n}[,cor...@var{cores}][,threa...@var{threads}][,socke...@var{sockets}][,maxcp...@var{maxcpus}]
+...@findex -smp
Simulate an SMP system with @var{n} CPUs. On the PC target, up to 255
CPUs are supported. On Sparc32 target, Linux limits the number of usable CPUs
to 4.
@@ -62,6 +67,7 @@ DEF("numa", HAS_ARG, QEMU_OPTION_numa,
"-numa node[,mem=size][,cpus=cpu[-cpu]][,nodeid=node]\n")
STEXI
@item -numa @var{opts}
+...@findex -numa
Simulate a multi node NUMA system. If mem and cpus are omitted, resources
are split equally.
ETEXI
@@ -72,6 +78,8 @@ DEF("fdb", HAS_ARG, QEMU_OPTION_fdb, "")
STEXI
@item -fda @var{file}
@item -fdb @var{file}
+...@findex -fda
+...@findex -fdb
Use @var{file} as floppy disk 0/1 image (@pxref{disk_images}). You can
use the host floppy by using @file{/dev/fd0} as filename (@pxref{host_drives}).
ETEXI
@@ -87,6 +95,10 @@ STEXI
@item -hdb @var{file}
@item -hdc @var{file}
@item -hdd @var{file}
+...@findex -hda
+...@findex -hdb
+...@findex -hdc
+...@findex -hdd
Use @var{file} as hard disk 0, 1, 2 or 3 image (@pxref{disk_images}).
ETEXI
@@ -94,6 +106,7 @@ DEF("cdrom", HAS_ARG, QEMU_OPTION_cdrom,
"-cdrom file use 'file' as IDE cdrom image (cdrom is ide1 master)\n")
STEXI
@item -cdrom @var{file}
+...@findex -cdrom
Use @var{file} as CD-ROM image (you cannot use @option{-hdc} and
@option{-cdrom} at the same time). You can use the host CD-ROM by
using @file{/dev/cdrom} as filename (@pxref{host_drives}).
@@ -105,15 +118,9 @@ DEF("drive", HAS_ARG, QEMU_OPTION_drive,
" [,cache=writethrough|writeback|none][,format=f][,serial=s]\n"
" [,addr=A][,id=name][,aio=threads|native][,readonly=on|off]\n"
"use 'file' as a drive image\n")
-DEF("set", HAS_ARG, QEMU_OPTION_set,
-"-set group.id.arg=value\n"
-"set parameter for item of type \n"
-"i.e. -set drive.$id.file=/path/to/image\n")
-DEF("global", HAS_ARG, QEMU_OPTION_global,
-"-global driver.property=value\n"
-"set a global default for a driver property\n")
STEXI
@item -drive @var{option}[,@var{option}[,@var{option}[,...]]]
+...@findex -drive
Define a new drive. Valid options are:
@@ -216,11 +223,30 @@ qemu -hda a -hdb b
@end example
ETEXI
+DEF("set", HAS_ARG, QEMU_OPTION_set,
+"-set group.id.arg=value\n"
+"set parameter for item of type \n"
+"i.e. -set drive.$id.file=/path/to/image\n")
+STEXI
+...@item -set
+...@findex -set
+TODO
+ETEXI
+
+DEF("global", HAS_ARG, QEMU_OPTION_global,
+"-global driver.property=value\n"
+"set a global default for a driver property\n")
+STEXI
+...@item -global
+...@findex -global
+TODO
+ETEXI
+
DEF("mtdblock", HAS_ARG, QEMU_OPTION_mtdblock,
"-mtdblock file use 'file' as on-board Flash memory image\n")
STEXI
-
@item -mtdblock @var{file}
+...@findex -mtdblock
Use @var{file} as on-board Flash memory image.
ETEXI
@@ -228,6 +254,7 @@ DEF("sd", HAS_ARG, QEMU_OPTION_sd,
"-sd fileuse 'file' as SecureDigital card image\n")
STEXI
@item -sd @var{file}
+...@findex -sd
Use @var{file} as SecureDigital card image.
ETEXI
@@ -235,6 +262,7 @@ DEF("pflash", HAS_ARG, QEMU_OPTION_pflash,
"-pflash fileuse 'file' as a parallel flash image\n")
STEXI
@item -pflash @var{file}
+...@findex -pflash
Use @var{file} as a parallel flash image.
ETEXI
@@ -243,7 +271,7 @@ DEF("boot", HAS_ARG, QEMU_OPTION_boot,
"'drives': floppy (a), hard disk (c), CD-ROM (d), network
(n)\n")
STEXI
@item -boot [ord...
Re: [Qemu-devel] [PATCH] User mode: Handle x86_64 vsyscall
Laurent Desnogues schrieb: > On Sun, Oct 18, 2009 at 5:09 AM, Jamie Lokier wrote: > [...] >> Please don't do that. Some code traces instructions through the >> vsyscall/vdso page, and will be surprised if a syscall instruction >> does not do what's expected based on the registers at that point. >> >> Also I don't know if anyone's done this, but I have played with the >> idea of an optimising x86->x86 JIT translator (similar to valgrind or >> qemu's TCG) which would include the vdso instruction sequence in it's >> traces, just because it didn't treat that any differently from other >> userspace code. Making the syscall instruction behave differently due >> to EIP would break that sort of thing. >> >> There's no performance penalty in setting a few registers prior to >> using the syscall instruction normally, so please do that. > > My proposed patch intercepts vsyscall as soon as the PC is > in the [VSYSCALL_START, VSYSCALL_END[ range, so all > instructions in that range won't be translated. Doing it > differently will cause problems due to the virtual address. > >> On x86_64, the vsyscall page has fixed address (see >> linux/arch/x86/kernel/vsyscall_64.c), but the vdso usually has >> variable address. >> >> On x86_32, the vdso has randomised address unless configurd to be a >> fixed address. On older kernels it was a fixed address and some >> binary programs assume they can call that. > > So QEMU can't do things properly and some binaries will > fail, right? > > > Laurent I'm still struggling with bntest and other x86_64-linux-user software calling any of the vsyscall functions. Laurent, your vsyscall patch only works on x86_64 hosts. A lot of software calls time() which uses vsyscall on x86_64 which does not work with x86_64-linux-user mode. So the status of x86_64-linux-user is not more than experimental :-( I tried to modify x86_64-linux-user to set up a vsyscall page in high memory, but this seems to be difficult (at least with 32 bit host). Any hints how this should be done are welcome. Stefan
Re: [Qemu-devel] [PATCH] User mode: Handle x86_64 vsyscall
On Fri, Feb 5, 2010 at 11:57 PM, Stefan Weil wrote: > Laurent Desnogues schrieb: [...] > > I'm still struggling with bntest and other x86_64-linux-user software > calling any of the vsyscall functions. > > Laurent, your vsyscall patch only works on x86_64 hosts. > > A lot of software calls time() which uses vsyscall on x86_64 which > does not work with x86_64-linux-user mode. I'm not sure I understand what you mean. Did you try on some other host and it failed? Was your host 32-bit? If so, I'm afraid user-mode will fail for more reasons than vsyscall. > So the status of x86_64-linux-user is not more than experimental :-( > > I tried to modify x86_64-linux-user to set up a vsyscall page in high > memory, > but this seems to be difficult (at least with 32 bit host). > > Any hints how this should be done are welcome. My patch explicitly prevents the linking of the vsyscall page. Could you provide more info about your host? Laurent
[Qemu-devel] [PATCH] qemu-kvm: Speed up of the dirty-bitmap-traveling
dirty-bitmap-traveling is carried out by byte size in qemu-kvm.c.
But We think that dirty-bitmap-traveling by long size is faster than by byte
size especially when most of memory is not dirty.
Signed-off-by: OHMURA Kei
---
qemu-kvm.c | 49 ++---
1 files changed, 42 insertions(+), 7 deletions(-)
diff --git a/qemu-kvm.c b/qemu-kvm.c
index a305907..5459cdd 100644
--- a/qemu-kvm.c
+++ b/qemu-kvm.c
@@ -2433,22 +2433,21 @@ int kvm_physical_memory_set_dirty_tracking(int enable)
}
/* get kvm's dirty pages bitmap and update qemu's */
-static int kvm_get_dirty_pages_log_range(unsigned long start_addr,
- unsigned char *bitmap,
- unsigned long offset,
- unsigned long mem_size)
+static void kvm_get_dirty_pages_log_range_by_byte(unsigned int start,
+ unsigned int end,
+ unsigned char *bitmap,
+ unsigned long offset)
{
unsigned int i, j, n = 0;
unsigned char c;
unsigned long page_number, addr, addr1;
ram_addr_t ram_addr;
-unsigned int len = ((mem_size / TARGET_PAGE_SIZE) + 7) / 8;
/*
* bitmap-traveling is faster than memory-traveling (for addr...)
* especially when most of the memory is not dirty.
*/
-for (i = 0; i < len; i++) {
+for (i = start; i < end; i++) {
c = bitmap[i];
while (c > 0) {
j = ffsl(c) - 1;
@@ -2461,13 +2460,49 @@ static int kvm_get_dirty_pages_log_range(unsigned long
start_addr,
n++;
}
}
+}
+
+static int kvm_get_dirty_pages_log_range_by_long(unsigned long start_addr,
+ unsigned char *bitmap,
+ unsigned long offset,
+ unsigned long mem_size)
+{
+unsigned int i;
+unsigned int len;
+unsigned long *bitmap_ul = (unsigned long *)bitmap;
+
+/* bitmap-traveling by long size is faster than by byte size
+ * especially when most of memory is not dirty.
+ * bitmap should be long-size aligned for traveling by long.
+ */
+if (((unsigned long)bitmap & (TARGET_LONG_SIZE - 1)) == 0) {
+len = ((mem_size / TARGET_PAGE_SIZE) + TARGET_LONG_BITS - 1) /
+TARGET_LONG_BITS;
+for (i = 0; i < len; i++)
+if (bitmap_ul[i] != 0)
+kvm_get_dirty_pages_log_range_by_byte(i * TARGET_LONG_SIZE,
+(i + 1) * TARGET_LONG_SIZE, bitmap, offset);
+/*
+ * We will check the remaining dirty-bitmap,
+ * when the mem_size is not a multiple of TARGET_LONG_SIZE.
+ */
+if ((mem_size & (TARGET_LONG_SIZE - 1)) != 0) {
+len = ((mem_size / TARGET_PAGE_SIZE) + 7) / 8;
+kvm_get_dirty_pages_log_range_by_byte(i * TARGET_LONG_SIZE,
+len, bitmap, offset);
+}
+} else { /* slow path: traveling by byte. */
+len = ((mem_size / TARGET_PAGE_SIZE) + 7) / 8;
+kvm_get_dirty_pages_log_range_by_byte(0, len, bitmap, offset);
+}
+
return 0;
}
static int kvm_get_dirty_bitmap_cb(unsigned long start, unsigned long len,
void *bitmap, void *opaque)
{
-return kvm_get_dirty_pages_log_range(start, bitmap, start, len);
+return kvm_get_dirty_pages_log_range_by_long(start, bitmap, start, len);
}
/*
-- 1.6.3.3
Re: [Qemu-devel] [PATCH] User mode: Handle x86_64 vsyscall
Laurent Desnogues schrieb: > On Fri, Feb 5, 2010 at 11:57 PM, Stefan Weil wrote: >> Laurent Desnogues schrieb: > [...] >> I'm still struggling with bntest and other x86_64-linux-user software >> calling any of the vsyscall functions. >> >> Laurent, your vsyscall patch only works on x86_64 hosts. >> >> A lot of software calls time() which uses vsyscall on x86_64 which >> does not work with x86_64-linux-user mode. > > I'm not sure I understand what you mean. Did you try > on some other host and it failed? Was your host > 32-bit? If so, I'm afraid user-mode will fail for more > reasons than vsyscall. > >> So the status of x86_64-linux-user is not more than experimental :-( >> >> I tried to modify x86_64-linux-user to set up a vsyscall page in high >> memory, >> but this seems to be difficult (at least with 32 bit host). >> >> Any hints how this should be done are welcome. > > My patch explicitly prevents the linking of the vsyscall > page. > > Could you provide more info about your host? > > > Laurent > I tested two different hosts with x86_64-linux-user: * 32 bit Intel (i386) - does not work with your patch * 64 bit AMD (x86_64) - works with your patch Your patch improves the emulation for 64 bit hosts. Nevertheless, it has some open points: * target-i386 code should not have to know about linux vsyscall * there is no vsyscall page in memory, but very special programs might expect to see one (it is even worse: the target sees the memory page of the host) * it is not possible to step into vsyscall code using a debugger My favorite solution would be a vsyscall page mapped to the correct fixed address and filled with QEMU generated specific code, for example code which calls the normal syscalls to do the work. This would only need modifications for linux-user code. Regards Stefan
