Re: [Qemu-devel] Windows 2000 issues questions
On Mon, Apr 10, 2006 at 08:16:17PM +0400, Brad Campbell wrote: 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? Just to back up what Leo said.. I have his %16 -win2k-hack patch installed (which is required as you need to add the delay to DMA IO also) and if I leave -win2k-hack enabled I find very little performance degradation.. in addition to it enabling windows update to work. I'm sure it's either slowing down the VM or wasting cpu cycles, but it does work and does not knock things about noticeably (and I test on a PIII-M 1Ghz running at 750Mhz to give kinda worst case performance testing) I do recall not having these issues with an async-io patch installed, but the last async-io patch I used changed the virtual ide controller and made all my vm's useless. I'm somewhat reticent to install another patch that is going to require me to re-install all my vm's.. but if there is one floating about that does not change the virtual hardware and is pretty self contained I'd be more than happy to run it through my test suite. I'd be happy to test a patch that changes the virtual IDE controller to one that works better, since I can't seem to get a win2k vm installed and updated at all anyway ;) ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Windows 2000 issues questions
Troy, Fabrice just committed it to CVS yesterday. If you use the -win2k-hack option now, it should work fine from the CVS version. You should use the -win2k-hack _always_, even if you are not installing to get reliable Windows 2000 operation on the CVS version of QEMU, especially if you are using -kernel-kqemu. - Leo Reiter Troy Benjegerdes wrote: I'd be happy to test a patch that changes the virtual IDE controller to one that works better, since I can't seem to get a win2k vm installed and updated at all anyway ;) -- 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
[Qemu-devel] Windows 2000 issues questions
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
Re: [Qemu-devel] Windows 2000 issues questions
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
Re: [Qemu-devel] Windows 2000 issues questions
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? Just to back up what Leo said.. I have his %16 -win2k-hack patch installed (which is required as you need to add the delay to DMA IO also) and if I leave -win2k-hack enabled I find very little performance degradation.. in addition to it enabling windows update to work. I'm sure it's either slowing down the VM or wasting cpu cycles, but it does work and does not knock things about noticeably (and I test on a PIII-M 1Ghz running at 750Mhz to give kinda worst case performance testing) I do recall not having these issues with an async-io patch installed, but the last async-io patch I used changed the virtual ide controller and made all my vm's useless. I'm somewhat reticent to install another patch that is going to require me to re-install all my vm's.. but if there is one floating about that does not change the virtual hardware and is pretty self contained I'd be more than happy to run it through my test suite. Brad -- Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. -- Douglas Adams ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
