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
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer 07/08/19 22:09:40
Modified files:
. : vl.c
Log message:
Add -clock option, by Luca Tettamanti.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemu&r1=1.324&r2=1
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer 07/08/19 21:56:03
Modified files:
. : vl.c vl.h
Log message:
Rework alarm timer infrastrucure, by Luca Tettamanti.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroo
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer 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:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ide.c?cvsr
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer 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:
http://cvs.savannah.gnu.org/viewcvs/qemu/dar
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
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 introduc
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 thi
>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
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
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
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?
Insig
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
>>> 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?
>>
>
>Accurac
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 i
> 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
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
On 19 Aug 2007, at 12:08, Avi Kivity wrote:
Markus Hitter wrote:
Am 19.08.2007 um 12:35 schrieb Avi Kivity:
- this deviates from standard Unix (and Windows) practice.
Arguably the OS X way is superior, but qemu is perhaps not the
best vehicle to introduce it to other OSes.
NeXTstep i
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 the "unix" tim
Hi Qemu people.
After my last mail about CASIMIR, I had answers of people complaining that it
was not it English and they can't read my article...
Well, the software is still not in English, but there are some improvements :)
ยง There is a translation of the previous article at at this address
Avi Kivity wrote:
This allows save/restore (and live migration on kvm) of smp guests.
Index: hw/apic.c
===
RCS file: /sources/qemu/qemu/hw/apic.c,v
retrieving revision 1.13
diff -u -r1.13 apic.c
--- hw/apic.c 3 Apr 2007 16:38:34 -
Markus Hitter wrote:
Am 19.08.2007 um 12:35 schrieb Avi Kivity:
- this deviates from standard Unix (and Windows) practice.
Arguably the OS X way is superior, but qemu is perhaps not the best
vehicle to introduce it to other OSes.
NeXTstep introduced this into the Unix world and GN
Am 19.08.2007 um 12:35 schrieb Avi Kivity:
- this deviates from standard Unix (and Windows) practice.
Arguably the OS X way is superior, but qemu is perhaps not the best
vehicle to introduce it to other OSes.
NeXTstep introduced this into the Unix world and GNUstep uses it
today. So, th
Christian Brunschen wrote:
On 17 Aug 2007, at 13:40, Avi Kivity wrote:
It's not easy to use: if you move the image, you need to move the file.
I'd like to have exactly one entity to worry about when using a virtual
machine.
As I wrote previously, there is already such a thing on every modern
Anthony Liguori wrote:
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.
Matthew Kent wrote:
If DYNAMIC_TICKS is defined qemu does not attepmt to generate SIGALRM at a
constant rate. Rather, the system timer is set to generate SIGALRM only
when it is needed. DYNAMIC_TICKS reduces the number of SIGALRMs sent to
idle dynamic-ticked guests.
Original patch from Dan Kenigs
>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 mini
27 matches
Mail list logo
