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
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel