Re: [Qemu-devel] MSI-X doesn't work when running Windows as guest

[Eduardo Habkost]

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.

-- 
Eduardo