25.02.2013 10:19, Daniel Dickinson wrote: > On 25/02/13 12:53 AM, Michael Tokarev wrote: > [snip] >> Note that this is unlikely a regression, since these drivers aren't used >> with 0.12 version of qemu-kvm - it just does not provide necessary virtual >> devices for these drivers to run. > > Even the network ones? Not sure how the network was working then > because I had libvirt set to virtio, and the virtio drivers on the guest.
No, network drivers (netkvm) are obviously being used. I was referring to display (qxl) and baloon drivers. >> One better candidate is rtl8139 instead of ne2k. >> >> e1000 needs drivers from intel for this card, the ones which come with >> winXP wont work as these are too old. > > Yeah, I used intel's driver. Is rtl8139 in XP? I thought it wasn't, > which is why I did ne2k. rtl8139 is supported in XP out of the box. >> Now that's, again, an interesting point. So, did you actually try other >> NICs? You said you tried e1000, and it didn't work - I assumed it had >> the same problem as virtio one. But now you're saying it does not work >> at all? > > Sorry, that's me not being clear. It was the same problem as virtio (no > DHCP). Ah ok. So, again, I somehow fail to see how this can be a problem. These drivers (from spice-guest-tools-0.52.exe) don't modify/substitute windows network components except of the device drivers themselves - in this case it is about netkvm.sys. All layers below that remains the same, and e1000 drivers are not touched either. So network functionality should not be affected. Well. If it really is a bug in qemu, it might be some code path which is executed when we install additional driver (f.e. vioser, or something else), and it does something in qemu which "damages" the network part. >>> will also try removing all ethernet drivers, shutting down the VM, and >>> making only the offending NIC remain (the macvtap ones work). >> >> Oww. This is even more interesting. There's no need to remove other >> vNICs really, -- it was my (wrong) guess, I thought maybe win behaves >> somehow differently when it has more than one NIC and thus enables >> some sort of router/firewall mode. >> >> But the diff. between macvtap and bridge vNICs is very good point. It >> means more things to try, maybe there are several issues present. >> >> What might also be useful is to try configuring network manually and >> checking if it is only dhcp or whole thing which is at problem. I >> already asked you to do so in the previous email. > > Sorry, forgot. I will have to create a new VM in a bad state to get > test that. Please try it. Because... >> I'll try to play with all this, now there's finally quite something to >> play with. Good job! ...because I can't reproduce the issue still, no matter if I start with XP sp3 or sp1, no matter if I install to virtio right away or if I change it later, no matter if I use older version of virtio drivers first and so on -- it always Just Works for me. Maybe these 3 additional NICs in the guest is the key point of this, I dunno. At least it isn't easy for me to recreate your a bit complex setup here. But the more we dig into this, the more it becomes a problem of drivers on the windows side. I used windows in the past, but I'm not in any way an expert in its drivers area, I don't know how it all works. Maybe it is better if you ask more knowlegeable people about this. Mailing to qemu-u...@nongnu.org might be appropriate for this. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
