[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] MSI-X doesn't work when running Windows as guest
From: |
Michael S. Tsirkin |
Subject: |
Re: [Qemu-devel] MSI-X doesn't work when running Windows as guest |
Date: |
Fri, 13 Sep 2013 15:22:01 +0300 |
On Fri, Sep 13, 2013 at 01:14:43AM -0300, Eduardo Habkost wrote:
> On Fri, Sep 13, 2013 at 12:03:40AM +0300, Michael S. Tsirkin wrote:
> > On Thu, Sep 12, 2013 at 04:45:01PM -0300, Eduardo Habkost wrote:
> > > On Thu, Sep 12, 2013 at 11:42:17AM +0300, Michael S. Tsirkin wrote:
> > > > On Thu, Sep 12, 2013 at 11:23:46AM +0300, Gal Hammer wrote:
> > > > > Hi,
> > > > >
> > > > > I've notice that the virtio-serial Windows' driver doesn't use MSI-X
> > > > > vectors when running using upstream qemu or
> > > > > qemu-kvm-1.2.2-13.fc18.x86_64. The same VM works with MSI-X when
> > > > > using qemu-kvm-0.12.1.2-2.355.el6.x86_64.
> > > > >
> > > > > From what I saw, Windows is trying to enable MSI-X by writing a 2
> > > > > bytes value to device's PCI-config address 66h.
> > > > >
> > > > > So when everything works well the flow goes like this:
> > > > >
> > > > > pci_default_write_config value: 8000 len: 2
> > > > > pci_default_write_config value: 1 len: 2
> > > > > msix_enabled 0 (67)
> > > > > pci_default_write_config value: e107 len: 2
> > > > > pci_default_write_config value: 1 len: 2
> > > > > msix_enabled 0 (67)
> > > > > pci_default_write_config value: 8001 len: 2
> > > > > msix_enabled 1 (67)
> > > > >
> > > > > But on upstream it goes:
> > > > >
> > > > > pci_default_write_config addr: 66 value: 8000 size: 2
> > > > > pci_default_write_config addr: 66 value: 1 size: 2
> > > > > msix_enabled 0 (67)
> > > > > pci_default_write_config addr: 66 value: e307 size: 2 (NOTE: Value
> > > > > is diffrent!).
> > > > > pci_default_write_config addr: 66 value: 1 size: 2
> > > > > msix_enabled 0 (67)
> > > > >
> > > > > (NOTE: Missing the write of 8001).
> > > > >
> > > > > My qemu's command line:
> > > > >
> > > > > ---< snip >---
> > > > >
> > > > > /usr/bin/qemu-kvm -m 1G -smp 2 -enable-kvm -usb -device usb-tablet \
> > > > > -device
> > > > > ide-drive,drive=drive-virtio0-0-0,id=virtio0-0-0,bootindex=1 \
> > > > > -drive
> > > > > file=win7_32_viorng.qcow2,if=none,id=drive-virtio0-0-0,format=qcow2,werror=stop,rerror=stop,cache=none
> > > > > \
> > > > > -monitor stdio \
> > > > > -vga qxl -spice id=on,disable-ticketing,port=5903 \
> > > > > -device virtio-serial-pci,id=virtio-serial0,vectors=2 \
> > > > > -chardev spicevmc,id=spicechannel0,name=vdagent
> > > > >
> > > > > ---< snip >---
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Gal.
> > > >
> > > >
> > > > So it's a known change from qemu-kvm to qemu.
> > > > With qemu-kvm the default cpu was kvm64.
> > > > With qemu the default cpu is qemu64 even if you use -enable-kvm.
> > > >
> > > > Not an issue for libvirt as that specifies -cpu,
> > > > but will be an issue for command-line users.
> > > >
> > > > Maybe we should change the default for new machine types and when
> > > > -enable-kvm is specified?
> > >
> > > What about simply making qemu64 as good as kvm64 (on newer
> > > machine-types)?
> >
> > This will likely mean extending tcg to emulate more CPU
> > features. Do you want to spend cycles on this?
>
> Why? Features that are not supported by TCG are automatically removed on
> from CPUID on X86CPU initialization.
>
> >
> > > What exactly is missing on qemu64 that causes the above
> > > problem?
> >
> > I remember windows checks that cpu is modern enough
> > to enable msi-x.
> > Dont' remember the exact details.
>
> It would be interesting to find out what exactly is necessary to make
> this work. Adding new feature bits to qemu64 should be harmless for TCG,
> but increasing family/model too much without adding new features may
> require a little more testing to check if guests don't get confused.
That's why I'm saying switching to kvm64 is easier.
> --
> Eduardo