search for: qemu_get_clock

...-- a/tools/ioemu/vl.c Tue Mar 04 12:32:31 2008 +0000 +++ b/tools/ioemu/vl.c Tue Mar 04 15:34:25 2008 +0000 @@ -6125,7 +6125,11 @@ void gui_update(void *opaque) void gui_update(void *opaque) { display_state.dpy_refresh(&display_state); - qemu_mod_timer(gui_timer, GUI_REFRESH_INTERVAL + qemu_get_clock(rt_clock)); + qemu_mod_timer(gui_timer, + (display_state.gui_timer_interval ? + display_state.gui_timer_interval : + GUI_REFRESH_INTERVAL) + + qemu_get_clock(rt_clock)); } struct vm_change_state_entry { diff -r c6cd384a48bf tools/ioemu/vl.h...

(I posted this on xen-users last week, and nobody seemed to know what was up. It is time, I suppose then, to dust off the debugger; I was hoping one of you could point me in the correct direction to begin troubleshooting this.) I''m HVM booting our install-disks (systemimager) here, and I''m spotting some weird performance issues. Our install uses rsync and prints every

Attached please see the hvm guest os acpi patch part 2 of 4:piix4acpi_timer ACPI timer is required during guest windows installation and boot. Signed-off-by: Tang Liang <tangliang@lenovo.com> Signed-off-by: Winston Wang <winston.l.wang@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

..._ioreq_t *buf_req = NULL; ioreq_t req; @@ -493,7 +494,7 @@ void __handle_buffered_iopage(CPUState * } } -void handle_buffered_io(void *opaque) +static void handle_buffered_io(void *opaque) { CPUState *env = opaque; @@ -502,7 +503,7 @@ void handle_buffered_io(void *opaque) qemu_get_clock(rt_clock)); } -void cpu_handle_ioreq(void *opaque) +static void cpu_handle_ioreq(void *opaque) { extern int vm_running; extern int shutdown_requested; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-d...

...15 ++++++++------- 1 files changed, 8 insertions(+), 7 deletions(-) diff --git a/vl.c b/vl.c index be8587a..d30cb2c 100644 --- a/vl.c +++ b/vl.c @@ -1410,8 +1410,7 @@ static int64_t qemu_next_deadline(void) delta = active_timers[QEMU_TIMER_VIRTUAL]->expire_time - qemu_get_clock(vm_clock); } else { - /* To avoid problems with overflow limit this to 2^32. */ - delta = INT32_MAX; + delta = INT64_MAX; } if (delta < 0) @@ -1427,9 +1426,11 @@ static uint64_t qemu_next_deadline_dyntick(void) int64_t rtdelta; if (use_icount) -...

...,19 @@ static void gui_update(void *opaque) { + uint64_t interval = GUI_REFRESH_INTERVAL; DisplayState *ds = opaque; - ds->dpy_refresh(ds); - qemu_mod_timer(ds->gui_timer, - (ds->gui_timer_interval ? - ds->gui_timer_interval : - GUI_REFRESH_INTERVAL) - + qemu_get_clock(rt_clock)); + DisplayChangeListener *dcl = ds->listeners; + + dpy_refresh(ds); + + while (dcl != NULL) { + if (dcl->gui_timer_interval && + dcl->gui_timer_interval < interval) + interval = dcl->gui_timer_interval; + dcl = dcl->n...

...628,7 @@ int n_rectangles; int saved_offset; int maxx, maxy; - int tile_bytes = vs->depth * DP2X(vs, 1); + int tile_bytes = vs->serverds.pf.bytes_per_pixel * DP2X(vs, 1); if (!vs->update_requested || vs->csock == -1) return; @@ -638,7 +648,7 @@ now = qemu_get_clock(rt_clock); - if (vs->width != DP2X(vs, DIRTY_PIXEL_BITS)) + if (vs->serverds.width != DP2X(vs, DIRTY_PIXEL_BITS)) width_mask = (1ULL << X2DP_UP(vs, ds_get_width(vs->ds))) - 1; else width_mask = ~(0ULL); @@ -1541,81 +1551,79 @@ check_pointer_type_change(vs, kbd_m...

...tches moving the "flush tx queue on ring full" into the I/O thread. http://markmc.fedorapeople.org/virtio-netperf/2008-11-06/g-h-tput-02-flush-in-io-thread.html the graph seems to show no effect on performance. ] [ mst: it is interesting that to start timer, we use qemu_get_clock which does a systemcall. ] [ mst: test how well does this work. We should get a kick once for N packets. ] [ mst: idea: instead of enabling interrupts after draining the queue, try waiting another timer tick ... ] [ mst: test whether the queue gets full. It will if...

...tches moving the "flush tx queue on ring full" into the I/O thread. http://markmc.fedorapeople.org/virtio-netperf/2008-11-06/g-h-tput-02-flush-in-io-thread.html the graph seems to show no effect on performance. ] [ mst: it is interesting that to start timer, we use qemu_get_clock which does a systemcall. ] [ mst: test how well does this work. We should get a kick once for N packets. ] [ mst: idea: instead of enabling interrupts after draining the queue, try waiting another timer tick ... ] [ mst: test whether the queue gets full. It will if...

Hi all, this is the long awaited patch series to add xen device model support in qemu; the main author is Anthony Perard. Developing this series we tried to come up with the cleanest possible solution from the qemu point of view, limiting the amount of changes to common code as much as possible. The end result still requires a couple of hooks in piix_pci but overall the impact should be very

(The list appears to have eaten my previous attempt to send this. Apologies if you receive multiple copies.) The attached patches allow you to use paravirtualised network and block interfaces from fully virtualised domains, based on Intel''s patches from a few months ago. These are significantly faster than the equivalent ioemu devices, sometimes by more than an order of magnitude.

The following series of 10 patches is a merge of the xenfb and xenconsoled functionality into the qemu-dm code. The general approach taken is to have qemu-dm provide two machine types - one for xen paravirt, the other for fullyvirt. For compatability the later is the default. The goals overall are to kill LibVNCServer, remove alot of code duplication and/or parallel impls of the same concepts, and