Re: Why doesn't Intel e1000 NIC work correctly in Windows XP?

[Alex Williamson <alex.williamson@redhat.com>]

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