Re: [Qemu-devel] Windows 2000 issues questions

["Leonardo E. Reiter" <lreiter@win4lin.com>]

Hetz,

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
> "competitors"..
> 
> 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,
> Hetz
> --
> Visit my blog (hebrew) for things that (sometimes) matter:
>  http://wp.dad-answers.com
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

-- 
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
http://www.win4lin.com