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

[Andreas Färber]

Am 13.09.2013 14:31, schrieb Michael S. Tsirkin:
> On Fri, Sep 13, 2013 at 03:22:01PM +0300, Michael S. Tsirkin wrote:
>> 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.
> 
> Thinking back I think it's the CPU model that does it.
> Gal, could you please try adding -cpu qemu64,model=6?

Or try git://github.com/afaerber/qemu-cpu.git qom-cpu branch, which has
Eduardo's model=6 patch already. (Please keep me in the loop.)

Andreas

> Also please try -cpu kvm64,model=2.
> 
> 
>>> -- 
>>> Eduardo
> 


-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg