Hi,
Here are the command line:
/usr/bin/qemu-kvm -S -M rhel6.0.0 -enable-kvm -m 2048 -smp
2,sockets=1,cores=2,threads=1 \
-name winxp -uuid 23cd2751-8a30-dd34-db47-bfc8c76ccadb -nodefconfig
-nodefaults \
-chardev socket,id=monitor,path=/var/lib/libvirt/qemu/winxp.monitor,server,nowait
-mon chardev=monitor,mode=readline \
-rtc base=localtime -boot c -device lsi,id=scsi0,bus=pci.0,addr=0x5
-device lsi,id=scsi1,bus=pci.0,addr=0x6 \
-device lsi,id=scsi2,bus=pci.0,addr=0x7 -device
lsi,id=scsi3,bus=pci.0,addr=0x8 \
-drive file=/mnt/vmdisk/winxp.disk,if=none,id=drive-ide0-0-0,boot=on,format=raw,cache=none
\
-device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 \
-drive file=/mnt/vmdisk/virtio-win-1.1.16.vfd,if=none,id=drive-fdc0-0-0,format=raw,cache=none\
-global isa-fdc.driveA=drive-fdc0-0-0 -drive
file=/dev/sd1,if=none,id=drive-scsi0-0-0,format=raw,cache=none \
-device scsi-disk,bus=scsi0.0,scsi-id=0,drive=drive-scsi0-0-0,id=scsi0-0-0 \
-drive file=/dev/sdb,if=none,id=drive-scsi0-0-1,format=raw,cache=none \
-device scsi-disk,bus=scsi0.0,scsi-id=1,drive=drive-scsi0-0-1,id=scsi0-0-1 \
-drive file=/dev/sdc,if=none,id=drive-scsi0-0-2,format=raw,cache=none \
-device scsi-disk,bus=scsi0.0,scsi-id=2,drive=drive-scsi0-0-2,id=scsi0-0-2 \
-drive file=/dev/sdd,if=none,id=drive-scsi0-0-3,format=raw,cache=none \
-device scsi-disk,bus=scsi0.0,scsi-id=3,drive=drive-scsi0-0-3,id=scsi0-0-3 \
-drive file=/dev/sde,if=none,id=drive-scsi0-0-4,format=raw,cache=none \
-device scsi-disk,bus=scsi0.0,scsi-id=4,drive=drive-scsi0-0-4,id=scsi0-0-4 \
-drive file=/dev/sdf,if=none,id=drive-scsi3-0-0,format=raw,cache=none \
-device scsi-disk,bus=scsi3.0,scsi-id=0,drive=drive-scsi3-0-0,id=scsi3-0-0 \
-drive file=/mnt/vmdisk/D/1,if=none,id=drive-scsi0-0-6,format=raw,cache=none \
-device scsi-disk,bus=scsi0.0,scsi-id=6,drive=drive-scsi0-0-6,id=scsi0-0-6 \
-chardev pty,id=serial0 -device isa-serial,chardev=serial0 -usb \
-vnc 0.0.0.0:0 -k en-us -vga vmware -device
pci-assign,host=02:00.0,id=hostdev0,configfd=18,bus=pci.0,addr=0x3 \
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4
The NIC and one SCSI controller (slot 7) has the same IRQ. The
performance in XP is really bad. When writing traffic to the drive,
the NIC can't be accessed, and ping will be also timeout.
If I let the NIC has the different IRQ number, then everything is OK.
Is it related to INTx model for XP?
We rebuild the QEMU, and add the LSI SCSI controller support. Why does
RHEL6 removes its support? Is this controller too old? Are there any
emulated SCSI devices to replace it?
Thanks,
flypen
On Thu, Jun 16, 2011 at 2:42 AM, Alex Williamson
<alex.williamson@xxxxxxxxxx> wrote:
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
