Re: [kvm-devel] [Qemu-devel] Re: [PATCH 0/4] Rework alarm timer infrastrucure - take2
Avi Kivity wrote: Paul Brook wrote: Yes, good thinking, but this should only be done if it actually impacts something. Reducing overhead from 0.1% to 0.05% is not worthwhile if it introduces extra complexity. If the overhead is that small, why are we touching this code in the first place? Accuracy is much more important from my point of view. Also, the reduction in the number of signals delivered when the guest uses 100Hz is significant. You'd also get better battery life on laptops. -- error compiling committee.c: too many arguments to function
[Qemu-devel] last AIO patch
Hi.
A small last AIO patch for current qemu make async disk write
for non-dma mode.
This patch can use always, can install w2k without
disk-full-problem and without use -w2k-hack option now for system
with AIO support.
--w
vodz
diff -rbu qemu.orig/hw/ide.c qemu/hw/ide.c
--- qemu.orig/hw/ide.c 2007-07-12 02:48:58.0 +0400
+++ qemu/hw/ide.c 2007-08-20 15:33:44.0 +0400
@@ -863,10 +863,44 @@
ide_set_irq(s);
}
+static void ide_sector_write_aio_cb(void *opaque, int ret)
+{
+BMDMAState *bm = opaque;
+IDEState *s = bm-ide_if;
+
+#ifdef TARGET_I386
+if (win2k_install_hack ((++s-irq_count % 16) == 0)) {
+ /* It seems there is a bug in the Windows 2000 installer HDD
+ IDE driver which fills the disk with empty logs when the
+ IDE write IRQ comes too early. This hack tries to correct
+ that at the expense of slower write performances. Use this
+ option _only_ to install Windows 2000. You must disable it
+ for normal use. */
+ qemu_mod_timer(s-sector_write_timer,
+ qemu_get_clock(vm_clock) + (ticks_per_sec / 1000));
+} else
+#endif
+{
+ ide_set_irq(s);
+}
+bm-aiocb = NULL;
+}
+
static void ide_sector_write(IDEState *s)
{
+BMDMAState *bm;
int64_t sector_num;
-int ret, n, n1;
+int n, n1;
+
+s-io_buffer_index = 0;
+s-io_buffer_size = 0;
+bm = s-bmdma;
+if(bm == NULL) {
+ bm = qemu_mallocz(sizeof(BMDMAState));
+ s-bmdma = bm;
+}
+bm-ide_if = s;
+bm-dma_cb = ide_sector_write_aio_cb;
s-status = READY_STAT | SEEK_STAT;
sector_num = ide_get_sector(s);
@@ -876,7 +910,6 @@
n = s-nsector;
if (n s-req_nb_sectors)
n = s-req_nb_sectors;
-ret = bdrv_write(s-bs, sector_num, s-io_buffer, n);
s-nsector -= n;
if (s-nsector == 0) {
/* no more sectors to write */
@@ -889,21 +922,8 @@
}
ide_set_sector(s, sector_num + n);
-#ifdef TARGET_I386
-if (win2k_install_hack ((++s-irq_count % 16) == 0)) {
-/* It seems there is a bug in the Windows 2000 installer HDD
- IDE driver which fills the disk with empty logs when the
- IDE write IRQ comes too early. This hack tries to correct
- that at the expense of slower write performances. Use this
- option _only_ to install Windows 2000. You must disable it
- for normal use. */
-qemu_mod_timer(s-sector_write_timer,
- qemu_get_clock(vm_clock) + (ticks_per_sec / 1000));
-} else
-#endif
-{
-ide_set_irq(s);
-}
+bm-aiocb = bdrv_aio_write(s-bs, sector_num, s-io_buffer, n,
+ ide_sector_write_aio_cb, bm);
}
/* XXX: handle errors */
[Qemu-devel] qemu vl.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/08/20 15:42:23 Modified files: . : vl.c Log message: Windows build fix, spotted by Herve Poussineau. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.325r2=1.326
Re: [Qemu-devel] Sparc guest
On 8/19/07, Nigel Horne [EMAIL PROTECTED] wrote: On the CVS version, networking has stopped working again with Sparc guests running Debian Linux. It had been working fine for a few weeks, but the latest version is broken again, with the device not being found. I cannot reproduce this on either i386 or x86_64 host with Debian stable guest. Also, none of the recent patches could have caused this effect. I'll update the guest to see if the problem comes from some updated Debian package.
[Qemu-devel] Re: [kvm-devel] [PATCH 0/4] Rework alarm timer infrastrucure - take2
Il Sun, Aug 19, 2007 at 10:31:26PM +0300, Avi Kivity ha scritto:
Luca wrote:
On 8/19/07, Luca Tettamanti [EMAIL PROTECTED] wrote:
+static uint64_t qemu_next_deadline(void) {
+uint64_t nearest_delta_us = ULLONG_MAX;
+uint64_t vmdelta_us;
Hum, I introduced a bug here... those vars should be signed.
On the overhead introduced: how do you measure it?
Run a 100Hz guest, measure cpu usage using something accurate like
cyclesoak, with and without dynticks, with and without kvm.
Ok, here I've measured the CPU usage on the host when running an idle
guest.
At 100Hz
QEMU
hpet4.8%
dynticks5.1%
Note: I've taken the mean over a period of 20 secs, but the difference
between hpet and dynticks is well inside the variability of the test.
KVM
hpet2.2%
dynticks1.0%
Hum... here the numbers jumps a bit, but dynticks is always below hpet.
At 1000Hz:
QEMU
hpet5.5%
dynticks 11.7%
KVM
hpet3.4%
dynticks7.3%
No surprises here, you can see the additional 1k syscalls per second. On
the bright side, keep in mind that with a tickless guest and dynticks
I've seen as little as 50-60 timer ticks per second.
Hackbench (hackbench -pipe 50) inside the guest:
QEMU: impossible to measure, the variance of the results is much bigger
than difference between dynticks and hpet.
KVM:
Around 0.8s slower in case on dynticks; variance of the results is
about 0.3s in both cases.
Luca
--
Chi parla in tono cortese, ma continua a prepararsi, potra` andare avanti;
chi parla in tono bellicoso e avanza rapidamente dovra` ritirarsi
Sun Tzu -- L'arte della guerra
Re: [Qemu-devel] Sparc guest
Am 20.08.2007 um 21:26 schrieb Blue Swirl: On 8/19/07, Nigel Horne [EMAIL PROTECTED] wrote: On the CVS version, networking has stopped working again with Sparc guests running Debian Linux. It had been working fine for a few weeks, but the latest version is broken again, with the device not being found. I cannot reproduce this on either i386 or x86_64 host with Debian stable guest. Also, none of the recent patches could have caused this effect. I'll update the guest to see if the problem comes from some updated Debian package. A recent security update was kernel 2.6.18.5 but I have not yet noticed problems, just having upgraded. What exactly were you observing? Was it during boot, or are there any specific steps to reproduce?
Re: [Qemu-devel] Re: [kvm-devel] [PATCH 0/4] Rework alarm timer infrastrucure - take2
On Mon, 20 Aug 2007, Luca Tettamanti wrote:
Il Sun, Aug 19, 2007 at 10:31:26PM +0300, Avi Kivity ha scritto:
Luca wrote:
On 8/19/07, Luca Tettamanti [EMAIL PROTECTED] wrote:
+static uint64_t qemu_next_deadline(void) {
+uint64_t nearest_delta_us = ULLONG_MAX;
+uint64_t vmdelta_us;
Hum, I introduced a bug here... those vars should be signed.
On the overhead introduced: how do you measure it?
Run a 100Hz guest, measure cpu usage using something accurate like
cyclesoak, with and without dynticks, with and without kvm.
Ok, here I've measured the CPU usage on the host when running an idle
guest.
[..snip the numbers..]
After briefly looking at the cyclesoak it indeed looks like it does
the right thing, but considering the limitations of user-space only
approach it introduces some (sometimes really unwanted) variables
into the system, those can, and i guess will, influence things.
The upshot is this - if you have used any standard utility (iostat,
top - basically anything /proc/stat based) the accounting has a fair
chance of being inaccurate. If cyclesoak is what you have used then
the results should be better, but still i would be worried about
them.
In conclusion until kernel native accounting is fixed your best bet
is to use: http://www.boblycat.org/~malc/apc/
--
vale
Re: [Qemu-devel] qemu-system-arm -M akita/terrier - which roms work? (more patches, this time keyboard... :)
On Mon, Jul 30, 2007 at 12:30:23AM +0200, Juergen Lock wrote:
On Sun, Jul 29, 2007 at 03:46:37AM +0200, andrzej zaborowski wrote:
Hi,
Hi,
On 29/07/07, Juergen Lock [EMAIL PROTECTED] wrote:
Anyway, boot now fails with:
qemu: fatal: pxa2xx_gpio_read: Bad offset 0x1c
i.e. it is apparently expecting something there that is not yet
Oh, it's Sharp's poor code :) the GPSR (0x1c) and GPCR registers are
write-only. I think it's safe to assume that the real hardware returns
the last written value in these addresses when reading, but in the
documentation they are write-only.
Yeah it was crashing in static int force_8bit_access_check_and_set
in linux/drivers/pcmcia/cistpl.c, apparently while doing an
GPSR(GPIO54_nPCE_2) = GPSR(GPIO54_nPCE_2);
Patched that (patch-pxa-gpsr, attached), and now the boot seems
to be hanging somewhere in userland...
Btw that patch is not yet committed, did it get lost? or does it
cause problems...
emulated. And when i boot with init=/bin/sh I can't do much because
the keymap seems to be wrong or the fn key otherwise gets lost.
(similar effect with the poky image btw, I wonder is this a qemu
problem or is just noone using the terminal there? :)
The problem here is the 2.6 kernel's default keymap and the zaurusd
daemon used in poky and openzaurus. They use this strange keymap and
qemu tries to account for that. I had first set a keymap in qemu that
matched the console keymap but later when I started using X it was
unusable and other users also didn't like that so I remapped all the
keys, but the remapping is not perfect even now, because the real
Zaurus keymap is too far from a normal pc keyboard (and I don't have a
physical one).
Yeah it has an fn key that is used to generate most special characters...
But even shift didn't work on the 2.4 kernel's console (and as I said
fn apparently got lost too), and with the poky rxvt it seemed like
anything that uses fn caused an error (cursor flashes quickly) instead
of sending the corresponding character.
Anyway I just played with this a bit again and got the fn key
working by exchanging 0x3d and 0x38 in hw/spitz.c, spitz_keymap... :)
(after looking at linux/drivers/char/spitz_rawmap.h in the sharp kernel.)
I also added definitions for { and } while I was at it, and now
the keyboard mostly works, only the right shift key still does nothing
on the sharp kernel's console and there seem to be the occasional
timing issues especially with 2.6 kernels i.e. sometimes the fn key
still gets lost etc.
Patch attached, enjoy...
Juergen
Index: qemu/hw/spitz.c
@@ -194,8 +194,8 @@
{ 0x0f, 0x10, 0x12, 0x14, 0x22, 0x16, 0x24, 0x25, -1 , -1 , -1 },
{ 0x3c, 0x11, 0x1f, 0x21, 0x2f, 0x23, 0x32, 0x26, -1 , 0x36, -1 },
{ 0x3b, 0x1e, 0x20, 0x2e, 0x30, 0x31, 0x34, -1 , 0x1c, 0x2a, -1 },
-{ 0x44, 0x2c, 0x2d, 0x0c, 0x39, 0x33, -1 , 0x48, -1 , -1 , 0x3d },
-{ 0x37, 0x38, -1 , 0x45, 0x57, 0x58, 0x4b, 0x50, 0x4d, -1 , -1 },
+{ 0x44, 0x2c, 0x2d, 0x0c, 0x39, 0x33, -1 , 0x48, -1 , -1 , 0x38 },
+{ 0x37, 0x3d, -1 , 0x45, 0x57, 0x58, 0x4b, 0x50, 0x4d, -1 , -1 },
{ 0x52, 0x43, 0x01, 0x47, 0x49, -1 , -1 , -1 , -1 , -1 , -1 },
};
@@ -425,6 +428,10 @@
s-pre_map[0x35 | SHIFT] = 0x34 | SHIFT; /* question */
s-pre_map[0x49] = 0x48 | FN; /* Page_Up */
s-pre_map[0x51] = 0x50 | FN; /* Page_Down */
+s-pre_map[0x33 | SHIFT] = 0x33 | FN; /* less */
+s-pre_map[0x34 | SHIFT] = 0x34 | FN; /* greater */
+s-pre_map[0x1a | SHIFT] = 0x16 | FN; /* braceleft */
+s-pre_map[0x1b | SHIFT] = 0x17 | FN; /* braceright */
s-modifiers = 0;
s-imodifiers = 0;
Re: [kvm-devel] [Qemu-devel] Re: [PATCH 0/4] Rework alarm timer infrastrucure - take2
On 8/20/07, malc [EMAIL PROTECTED] wrote:
On Mon, 20 Aug 2007, Luca Tettamanti wrote:
Il Sun, Aug 19, 2007 at 10:31:26PM +0300, Avi Kivity ha scritto:
Luca wrote:
On 8/19/07, Luca Tettamanti [EMAIL PROTECTED] wrote:
+static uint64_t qemu_next_deadline(void) {
+uint64_t nearest_delta_us = ULLONG_MAX;
+uint64_t vmdelta_us;
Hum, I introduced a bug here... those vars should be signed.
On the overhead introduced: how do you measure it?
Run a 100Hz guest, measure cpu usage using something accurate like
cyclesoak, with and without dynticks, with and without kvm.
Ok, here I've measured the CPU usage on the host when running an idle
guest.
[...]
The upshot is this - if you have used any standard utility (iostat,
top - basically anything /proc/stat based) the accounting has a fair
chance of being inaccurate. If cyclesoak is what you have used then
the results should be better, but still i would be worried about
them.
Yes, I've used cyclesoak.
Luca
