[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Windows 2000 issues questions

From: Leonardo E. Reiter
Subject: Re: [Qemu-devel] Windows 2000 issues questions
Date: Mon, 10 Apr 2006 11:37:13 -0400
User-agent: Mozilla Thunderbird 1.0.7 (X11/20051013)


persumably asynchronous I/O in the IDE device will solve the disk full issue. Basically that is what the win2k-hack emulates, in its simplest form. Asynchronous I/O will do this for real, as well as probably improve the feel of the VM. If you use the win2k-hack patch I posted a while back, performance is seriously improved, to the point where there is very little degradation - and it works very well. It also looks like with KQEMU 1.3.0, you need to use -win2k-hack always, especially if you want to run Windows update, or the symptom returns. There are several competing asynch I/O patches floating around. IMHO, each has its merits. For example, the UNIX-style async I/O patch is probably much cleaner and more efficient, but a pthread-based one is much more portable in its basic state (i.e. to Windows hosts, etc.) If I had my way, there would be an async I/O patch that uses either UNIX-style async I/O or Windows-style I/O, compiled conditionally of course based on the host platform. Threads make debugging very difficult in general, so a non-thread approach would be my preference. But Fabrice is the one who will accept or reject such patches, and I know he has this issue on his short TODO list based on an email he sent a while back, so we'll have to see what he decides. It's also on my TODO list to come up with a clean multi-platform async I/O patch that is not thread-based, but with my limited time this is not something I can work on very soon. Besides, there are already others out there who have done something similar, albeit merged with other IDE patches, which sometimes makes it difficult to test independently.

The service pack kludge is a different story. With KQEMU, you can go straight from no service packs to SP4 if you want (with or without -kernel-kqemu). Without kqemu (and on non-x86/x86_64 platforms), you have to install the service packs in sequence, which is a pain of course. I did some investigation of this a long time ago, including scanning through countless pages of Windows update logs, etc. The best I could guess was some timing issue (not related to -win2k-hack), or perhaps some math precision issue. A solution did not appear obvious otherwise I would have fixed it. When KQEMU came out, this became a moot point on x86/x86_64 architectures at least. I understand that this is still a problem without KQEMU or on architectures where you can't use KQEMU. Thankfully Fabrice has emulation correctness on his short-list as well ;)

- Leo Reiter

Hetz Ben Hamo wrote:
I'm sorry to bring this issues back from the dead:

* Full disk issues
* Service pack issues

I Do know that both these issues have been dealt before, but yet,
there is no "fix" from the QEMU application itself, compared to the

One thing that I don't understand is: are these issues related to DMA
implementation in QEMU or rather to a specific chipset implementation?

Also, would a replacement BIOS (like an old commercial BIOS) help with
this issues?

Neither VMWare nor VirtualPC have those problems (nor Bochs), so I was
wondering, if the tablet issues were solved with so many people
helping, perhaps this issue could be solved without all the win2k-hack
or service pack "kludge" that happends today regarding win2k..

Thanks a lot,
Visit my blog (hebrew) for things that (sometimes) matter:


Qemu-devel mailing list

Leonardo E. Reiter
Vice President of Product Development, CTO

Win4Lin, Inc.
Virtual Computing from Desktop to Data Center
Main: +1 512 339 7979
Fax: +1 512 532 6501

reply via email to

[Prev in Thread] Current Thread [Next in Thread]