Hi,
I made a little patch of timer/clock for Linux host. It always trys to use
/dev/rtc.
getitimer doesn't report a correct interval value.
http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060407-linux-timer.patch
To get a precise timer/clock., do:
(1) Set max-user-freq 1024 as root.
[Linux h
Hi,
I have already made a patch. Try this.
http://lists.gnu.org/archive/html/qemu-devel/2006-03/msg00041.html
Regards,
Kazu
Sent: Wednesday, April 12, 2006 3:19 AM Helmut Auer wrote:
> Hello
>> In my case, the guest CPU is idle. The host CPU utilization is only 5
>> or 10 percent when runnin
I was confused by the comments around the delaying of acks. Delaying
these acks didn't make intuitive sense to me and is inconsistent with
RFC 2581, which states:
... a TCP receiver MUST NOT excessively delay
acknowledgments. Specifically, an ACK SHOULD be generated for at
least every s
The "qemu-slirp-performance" patch contains three improvements to qemu
slirp networking performance. Booting my virtual machine (which
NFS-mounts its root filesystem from the host) has been accelerated by
8x, from over 5 minutes to 40 seconds. TCP throughput has been
accelerated from about 2 mega
Yes... I sent a follow-up note after I looked at the latest vl.c with a
newer patch applied. much simpler.
As for the delay acks, I've seen this and removed the delay for testing
before. I read in the comment (not sure if it was Fabrice or the slirp
author) about how the delay was 1 of 3 meth
Thanks, Leo. It appears your patch or something similar has made it
into 0.8.0. I have already merged the select loops, but it didn't
help as much as I hoped, maybe 10%. A much bigger improvement was
made by fixing the badly hacked slirp DELACK behavior. Believe it or
not, slirp delays all TCP
Brad Campbell wrote:
G'day all,
This takes Anthony Liguori's <[EMAIL PROTECTED]> patch from this
morning and rolls into it my hid descriptor fixes and the wheel sdl
double step fix.
I spent some time cleaning this all up. The following integrates Brad's
patches and the patch from
http:/
Hi Ken,
please disregard my last mail on this... here's a current patch against
today's CVS. I didn't realize that vl.c already converted from poll()
to select(), so the patch logic is much easier and cleaner.
Check it out... I tested it minimally and it seems to work - only tested
it on Li
Hi Ken,
I'm attaching a pretty old patch I made (from the 0.7.1 days), which did
a quick and dirty merge of the select's. It's not something that is
clean and it will need adapting to 0.8.0... but, I figure you could draw
some quick hints on how to merge the 2. Basically it fills the select
The attached patch is an updated version of my previous patch. Now it
applies
cleanly to cvs head and the read and write performance is increased.
Great work! Now the Debian 3.0r4 installer with 2.6.11+tcx kernel almost
finishes. Performance is also much better.
There is some problem with CD
The following makes a
ttyd0 "/usr/libexec/getty std.9600" dialup on secure
/etc/ttys entry work for a FreeBSD guest. Without it the emulated
serial port lacks carrier and hardware flow control and needs
ttyd0 "/usr/libexec/getty 3wire.9600" dialup on secure
which is not alw
Hello
In my case, the guest CPU is idle. The host CPU utilization is only 5
or 10 percent when running "find / -print > /dev/null" on the guest.
So I don't think guest interrupt latency is the issue for me in this
case.
In my environment the performance of about 300 KB is the good case, tha
Paul, thanks for the note.
In my case, the guest CPU is idle. The host CPU utilization is only 5
or 10 percent when running "find / -print > /dev/null" on the guest.
So I don't think guest interrupt latency is the issue for me in this
case.
My first guess is that qemu is asleep when the NFS res
On Tuesday 11 April 2006 18:20, Kenneth Duda wrote:
> I am also having severe performance problems using NFS-over-TCP on
> qemu-0.8 with a Linux host and guest. I will be looking at this
> today. My current theory is that the whole machine is going idle
> before qemu decides to poll kernel ring b
-- Forwarded message --
From: Pippijn van Steenhoven <[EMAIL PROTECTED]>
Date: 11-Apr-2006 19:22
Subject: minor fixes to get rid of warnings
Hi!
I just made some minor fixes in the code. All C compiler warnings are
gone now. The only warnings I still get are from texi2html that, b
My personal opinion:
Discussions of the GPL are like the bird 'flu -- any time
anyone offers any program for free and there is a
list/newsgroup about it, we know some "bird" will get the GPL
discussion 'flu. This is inevitable but we can't seem to
avoid it. And everyone who gets it, starts throw
How's this:
Index: sdl.c
===
RCS file: /cvsroot/qemu/qemu/sdl.c,v
retrieving revision 1.25
diff -a -u -r1.25 sdl.c
--- sdl.c 9 Apr 2006 01:06:34 - 1.25
+++ sdl.c 11 Apr 2006 17:03:51 -
@@ -510,4 +510,9 @@
By the way, I did verify that the patch works correctly in B/G/R 5/6/5
mode - I wasn't sure about 16-bit BGR before. However, in 16-bit mode,
only -std-vga works correctly if the X server is in BGR mode. In 24-bit
BGR mode, cirrus has no problem. I think there is some 16-bit trickery
going o
I am also having severe performance problems using NFS-over-TCP on
qemu-0.8 with a Linux host and guest. I will be looking at this
today. My current theory is that the whole machine is going idle
before qemu decides to poll kernel ring buffers holding packets the
guest is transmitting, but if any
I've been playing around with Qemu a bit, and am doing development where
my rootfs is mounted through NFS and my kernel is on the host. I've had
to run it with:
qemu -kernel bzImage somefakerawimage
Where somefakerawimage was the smallest possible disk image. This was a
bit awkward.
A block
In message: <[EMAIL PROTECTED]>
Paul Brook <[EMAIL PROTECTED]> writes:
: > I think that you are missing the point. He's not saying that you have
: > to distribute the source (which is what that exemption is about).
: > He's saying that the license on a mere library cannot and should no
On Tue, Apr 11, 2006 at 11:58:07AM +0400, Brad Campbell wrote:
> Auke Kok wrote:
>
> I think you best re-read anything from Linus on that subject.
> What he has said is something derivative of the kernel.
>
> Now we have kqemu for linux, freebsd and windows and its all relatively the
> same code
On Tue, Apr 11, 2006 at 11:05:56AM -0400, Leonardo E. Reiter wrote:
> 1. virtual machine software _is not_ trivial. Not by any means. It
> took my company about 20 years to fully develop what became Win4Lin 9x,
> if you trace its history back to before Linux existed (product called
> 'Merge').
On 11 apr 2006, at 17:25, Jim C. Brown wrote:
Actually, the reason ATi and NVidia don't open source their graphics
drivers is because they are both afraid that as soon as as they do
that, the other one will sue them into oblivion based on software
patents.
See http://wiki.ffii.org/Smirl041025E
> I think that you are missing the point. He's not saying that you have
> to distribute the source (which is what that exemption is about).
> He's saying that the license on a mere library cannot and should not
> force applications linked with that library to become a derived work.
> And he's righ
In message: <[EMAIL PROTECTED]>
Paul Brook <[EMAIL PROTECTED]> writes:
: > 4. There is a slippery slope here -
:
: There's a slippery slope both ways. If you assume vital parts of your system
: are going to be closed source then why bother with open source at all. Just
: use Windows
> 4. There is a slippery slope here -
There's a slippery slope both ways. If you assume vital parts of your system
are going to be closed source then why bother with open source at all. Just
use Windows or HPUX.
> if Linux kernel policies can change
> to force all kernel-space binding to be G
In message: <[EMAIL PROTECTED]>
Sebastian Kaliszewski <[EMAIL PROTECTED]> writes:
: Auke Kok wrote:
: > no matter how you turn Linus' arguments, he doesn't like anything else
: > than ports from windows driver objects linked, and I can really agree
: > with that. Whatever the laywers
On Tue, Apr 11, 2006 at 05:14:59PM +0200, Jonas Maebe wrote:
>
> On 11 apr 2006, at 17:05, Leonardo E. Reiter wrote:
>
> >what if I am a hardware vendor in a desperately competitive market,
> >such as say, video cards. Releasing my source code to the driver
> >would mean giving up some IP th
In message: <[EMAIL PROTECTED]>
Sebastian Kaliszewski <[EMAIL PROTECTED]> writes:
: andrzej zaborowski wrote:
: > Now, whether using kqemu together with a linux kernel will still be
: > legal is a different issue, but here the question is whether the user
: > is breaking the law, not th
On 11 apr 2006, at 17:05, Leonardo E. Reiter wrote:
what if I am a hardware vendor in a desperately competitive market,
such as say, video cards. Releasing my source code to the driver
would mean giving up some IP that allows me to surpass the
capabilities of my competitor for a few weeks
Hi Auke,
First, let me apologize for not giving you proper credit for suggesting
the MODULE_LICENSE fix to Fabrice. But, without starting a flame war
here, I want to respectfully disagree with a couple of points you make:
1. virtual machine software _is not_ trivial. Not by any means. It
Auke Kok wrote:
no matter how you turn Linus' arguments, he doesn't like anything else
than ports from windows driver objects linked, and I can really agree
with that. Whatever the laywers say about it is moot - only judges
listen to them and Open Source doesn't listen to laywers (in generally)
andrzej zaborowski wrote:
Now, whether using kqemu together with a linux kernel will still be
legal is a different issue, but here the question is whether the user
is breaking the law, not the author.
And then GPL explicitly allows user to do anything (s)he wishes, including
(but not limited
On 10/04/06, Leonardo E. Reiter <[EMAIL PROTECTED]> wrote:
> No it's not! In fact, in the latest version, he explicitly gives it a
> commercial ("Proprietary") license. He also does not import any
> exported GPL symbols from the kernel. In fact, if your claim is true,
Legally, even without the "
Hello,
this is to inform you that I have extended the QEMU ARM emulation to
support coprocessor 14, as implemented in the Embedded ICE version
0b0010. This coprocessor implements the "debug communications channel",
which is usually used to communicate via a JTAG-based hardware debugger.
One such
Hi,
On Mon, 10 Apr 2006, Auke Kok wrote:
> I do not think that kqemu benefits from being closed source, and probably more
> people with me. People will pick an open implementation before any closed one,
> even industry, they're picking up faster than you think ;^)
>
> I did not agree with kqemu
> I do not think that kqemu benefits from being closed source, and probably more
> people with me.
Probably. But people got make for a living and I think that Fabrice
has every right to decide how to make it available. We all must be
thankfull that he give it away for free...
> People will pick a
Auke Kok wrote:
no matter how you turn Linus' arguments, he doesn't like anything else
than ports from windows driver objects linked, and I can really agree
I think you best re-read anything from Linus on that subject.
What he has said is something derivative of the kernel.
Now we have kqemu
Hello,
I tried the cvs version from about a week ago with the latest kqemu driver, but
the network problem still exists. I am using:
qemu -net nic -net tap,ifname=my-tap
under Win2k with a Gentoo guest. The network throughput is about 20 MB ( per
Minute ! ).
When I use qemu 0.7.2 with the tap pa
40 matches
Mail list logo
