From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37433) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VKTVI-0003kF-Vc for qemu-devel@nongnu.org; Fri, 13 Sep 2013 09:33:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VKTVD-00086i-2U for qemu-devel@nongnu.org; Fri, 13 Sep 2013 09:33:44 -0400 Received: from cantor2.suse.de ([195.135.220.15]:56782 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VKTVC-00086R-PT for qemu-devel@nongnu.org; Fri, 13 Sep 2013 09:33:38 -0400 Message-ID: <5233142E.4090904@suse.de> Date: Fri, 13 Sep 2013 15:33:34 +0200 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <52317A12.10206@redhat.com> <20130912084217.GB18836@redhat.com> <20130912194501.GC2840@otherpad.lan.raisama.net> <20130912210340.GA26151@redhat.com> <20130913041443.GD2840@otherpad.lan.raisama.net> <20130913122201.GA29092@redhat.com> <20130913123029.GA29506@redhat.com> In-Reply-To: <20130913123029.GA29506@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] MSI-X doesn't work when running Windows as guest List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Gal Hammer , Hannes Reinecke , Eduardo Habkost , Anthony Liguori , qemu-devel@nongnu.org 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 MS= I-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: Valu= e >>>>>>> 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-table= t \ >>>>>>> -device >>>>>>> ide-drive,drive=3Ddrive-virtio0-0-0,id=3Dvirtio0-0-0,bootindex=3D= 1 \ >>>>>>> -drive file=3Dwin7_32_viorng.qcow2,if=3Dnone,id=3Ddrive-v= irtio0-0-0,format=3Dqcow2,werror=3Dstop,rerror=3Dstop,cache=3Dnone >>>>>>> \ >>>>>>> -monitor stdio \ >>>>>>> -vga qxl -spice id=3Don,disable-ticketing,port=3D5903 \ >>>>>>> -device virtio-serial-pci,id=3Dvirtio-serial0,vectors=3D2= \ >>>>>>> -chardev spicevmc,id=3Dspicechannel0,name=3Dvdagent >>>>>>> >>>>>>> ---< 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 T= CG, >>> 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. >=20 > Thinking back I think it's the CPU model that does it. > Gal, could you please try adding -cpu qemu64,model=3D6? Or try git://github.com/afaerber/qemu-cpu.git qom-cpu branch, which has Eduardo's model=3D6 patch already. (Please keep me in the loop.) Andreas > Also please try -cpu kvm64,model=3D2. >=20 >=20 >>> --=20 >>> Eduardo >=20 --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg