24.02.2013 10:25, Daniel Dickinson wrote: > I have started the process of recreating the VM on this (incomplete, > still SP1, unactivated Windows) instance I have used ne2k drivers and > left the CPU type blank in virt-manager (XP reports this as QEMU Virtual > CPU version 1.1.2) and used the 'Microsoft ACPI-compliant system' > instead of something about SMP multiprocessor ACPI system (I can look up > the exact name if needed, but the system type is different is the upshot).
Um. That's several misunderstandings really. The ACPI vs non-ACPI HAL (hardware abstraction layer) is very important difference indeed, we should use acpi-aware one these days, incl. winXP. Non-acpi variant receives _significantly_ less testing and is much more difficult to deal with. ne2k is also one of the less tested components, but it does not matter: the only significant difference (question) is whenever the issue is virtio-net-specific (in this case just _changing_ NIC type to anything non-virtio will be enough) or it is somewhere deeper. > I'm thinking based on the other bug that was reported and eventually > closed due to unreproducible and no more information, that the issue was That bugreport has been closed because we found and _fixed_ the actual bug in qemu-kvm in its non-acpi part. I remember that story very well because I spent several weeks with it. > the CPU type, whic affected the XP drivers that got installed, and some > system types that XP detects because of the configuration work with KVM > and others don't. No, this is not the case. CPU type has nothing to do with that, and the (NIC) drivers are the same too. Only "machine" type is what make the difference there, so that whole driver stack on win side is different in its lower component (the HAL), and it iteracts differently with the (virtual) harware too, even with different part of that hardware. > Bottom line is that manually specifying the cpu type is a bad idea with > XP (but other things need to be manually specified, like virtio if you > want paravirtualized speed). You can change CPU type of a guest (be it winXP or win2k or any other win machine (or non-win) OS) at will, the only key is to keep cpu feature flags which are essential for the software inside. For example, you can't mask `lm' (long mode, essentially 64bit support) bit of the CPU if you run a 64-bit guest, since it will fail to boot. You probably can't mask cmov flag, but I'm not sure whenever winXP uses it or not, and it may load a slightly different kernel if cmov is non-present. And so on. What CPU type _may_ be used for in win is to be counted in the activation mechanism. I never tried this, since I always use VL version of windows, which don't require activation. But this is not our case either. FWIW, you can reach me on irc - freenode or oftc, I'm `mjt' there. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
