On Wed, 2011-06-15 at 11:31 +0200, Jan Kiszka wrote: > On 2011-06-15 10:04, Jan Kiszka wrote: > > On 2011-06-15 02:54, Alex Williamson wrote: > >> On Tue, 2011-06-14 at 16:11 +0800, Flypen CloudMe wrote: > >>> Hi, > >>> > >>> I use Redhat Enterprise Linux 6, and use the KVM that is released by > >>> Redhat officially. The kernel version is 2.6.32-71.el6.x86_64. > >>> > >>> It seems that the IRQs are conflicted after reboot. The NIC and the > >>> SCSI controller have the same IRQ number. If I re-install the NIC > >>> driver, the IRQ number of the NIC will be assigned another value, then > >>> it can work normally. Do we have a way to let the NIC and the SCSI > >>> controller have different IRQ number in VM? Hmm, I'm still confused here. I went back and double checked, and as I thought, we disable the LSI SCSI controller in the RHEL6 KVM. So I'm curious what this device is. Is it an assigned SCSI controller or is there another one that we forgot to disable in RHEL or is this a different version of KVM? The config file or command line would be handy here. > >> I'll see if I can reproduce and figure anything out. Windows XP isn't a > >> guest we concentrate on, especially with device assignment. Are you > >> using an AMD or Intel host system? Does the same thing happen if you > >> run the XP guest on an IDE controller? It would be helpful to post the > >> guest configuration, command line used or libvirt xml. Also, you might > >> try latest upstream qemu-kvm to see if the problem still exists. I tested with an 82578DM e1000e NIC on an Intel host system, and it surprisingly worked just fine on the RHEL6.0 base. This is with a 32bit Windows XP SP3 install. The device supports MSI, but windows only seems to use it with INTx. I did have to remove the emulated rtl8139 or else I couldn't even boot due to BSODs in the guest. > > Nonsense, can't t make a difference as the PIIX3 resets the routing to > disable - which device-assignment does not deal with, but that's unrelated. Yep, someone has to write it at some point and device assignment will catch that. > Try assigning a different slot to the passed-through adapter and the > lsi. For me it helped to put the lsi on one slot behind the > auto-assigned (-device lsi,addr=5). > > I guess classic device assignment cannot support INTx sharing as the > kernel IRQ injection path does not inform user space about the device > state /wrt IRQs. Should be catch and reject this, or try to fix it up be > moving the assigned device around, Alex? I'm pretty sure we've looked at this path in the past and KVM will do the right thing with respect to shared INTx in the guest (ie. KVM will continue to assert the interrupt if it's been triggered by both assignment and userspace until both de-assert). Experimenting with a RHEL guest I can make an assigned e1000e and emulated e1000 share an interrupt. It works, but performance is terrible and the assigned device can get into a non-working state if the emulated device is removed. Perhaps there is still a path by which interrupts can get turned off for the assigned device. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
