[Qemu-devel] RE: [kvm-devel] [PATCH 0/4] Rework alarm timer infrastrucure -take2

2007-08-19 Thread Dor Laor
I think this is a really nice and important patch set. Just a couple things: On Sun, 2007-08-19 at 00:02 +0200, Luca Tettamanti wrote: In this case the dyn-tick minimum res will be 1msec. I believe it should work ok since this is the case without any dyn-tick. Actually minimum resolution

Re: [kvm-devel] [Qemu-devel] Re: [PATCH 0/4] Rework alarm timer infrastrucure - take2

2007-08-19 Thread Avi Kivity
Jamie Lokier wrote: Avi Kivity wrote: In this case the dyn-tick minimum res will be 1msec. I believe it should work ok since this is the case without any dyn-tick. Actually minimum resolution depends on host HZ setting, but - yes - essentially you have the same behaviour of

Re: [kvm-devel] [Qemu-devel] Re: [PATCH 0/4] Rework alarm timer infrastrucure - take2

2007-08-19 Thread Paul Brook
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? Paul

Re: [kvm-devel] [Qemu-devel] Re: [PATCH 0/4] Rework alarm timer infrastrucure - take2

2007-08-19 Thread Avi Kivity
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

RE: [kvm-devel] [Qemu-devel] Re: [PATCH 0/4] Rework alarm timer infrastrucure - take2

2007-08-19 Thread Dor Laor
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

[Qemu-devel] Re: [kvm-devel] [PATCH 0/4] Rework alarm timer infrastrucure - take2

2007-08-19 Thread Luca
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? Luca

Re: [kvm-devel] [Qemu-devel] Re: [PATCH 0/4] Rework alarm timer infrastrucure - take2

2007-08-19 Thread Jamie Lokier
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? Insightful.

Re: [Qemu-devel] Re: PATCH, RFC: Generic DMA framework

2007-08-19 Thread Blue Swirl
In 8/16/07, malc [EMAIL PROTECTED] wrote: Very long time ago i changed the ISA DMA API to address some of the critique that Fabrice expressed, i can't remember offhand if that included removal of explicit position passing or not (the patch is on some off-line HDD so it's not easy to check

Re: [Qemu-devel] sparc kqemu?

2007-08-19 Thread Blue Swirl
On 8/16/07, Jonathan Kalbfeld [EMAIL PROTECTED] wrote: Is this on the horizon? Is there any interest in it? For Sparc32 this could be possible, the page table structures are not unlike i386 ones. Given the death of Sparc32 distros I don't think there would be much interest. On Sparc64 there

RE: [kvm-devel] [Qemu-devel] Re: [PATCH 0/4] Rework alarmtimer infrastrucure - take2

2007-08-19 Thread Dor Laor
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? Insightful. A

Re: [kvm-devel] [Qemu-devel] Re: [PATCH 0/4] Rework alarm timer infrastrucure - take2

2007-08-19 Thread Avi Kivity
Jamie Lokier 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

[Qemu-devel] Re: [kvm-devel] [PATCH 0/4] Rework alarm timer infrastrucure - take2

2007-08-19 Thread Avi Kivity
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

[Qemu-devel] Sparc guest

2007-08-19 Thread Nigel Horne
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. -Nigel

[Qemu-devel] qemu/darwin-user main.c

2007-08-19 Thread Thiemo Seufer
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/08/19 21:43:54 Modified files: darwin-user: main.c Log message: Darwin-user: Compile fix for ppc targets, by Pierre d'Herbemont. CVSWeb URLs:

[Qemu-devel] qemu/hw ide.c

2007-08-19 Thread Thiemo Seufer
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/08/19 21:46:53 Modified files: hw : ide.c Log message: Fix bugs in the ATAPI cdrom driver, by Brandon Philips. CVSWeb URLs:

[Qemu-devel] qemu vl.c vl.h

2007-08-19 Thread Thiemo Seufer
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/08/19 21:56:03 Modified files: . : vl.c vl.h Log message: Rework alarm timer infrastrucure, by Luca Tettamanti. CVSWeb URLs:

[Qemu-devel] qemu vl.c

2007-08-19 Thread Thiemo Seufer
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/08/19 22:09:40 Modified files: . : vl.c Log message: Add -clock option, by Luca Tettamanti. CVSWeb URLs:

Re: [Qemu-devel] [PATCH][RFC] Fix bugs in the ATAPI cdrom driver

2007-08-19 Thread Thiemo Seufer
Brandon Philips wrote: On 17:42 Fri 17 Aug 2007, Matthew Kent wrote: On Fri, 2007-17-08 at 16:43 -0700, Brandon Philips wrote: The new libata-eh in the Linux kernel is throwing a fit over the QEMU cdrom device for two reasons: Nice thanks, was suffering from this issue as well.