From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51384) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VKSUo-0008WN-T1 for qemu-devel@nongnu.org; Fri, 13 Sep 2013 08:29:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VKSUi-0005k7-TW for qemu-devel@nongnu.org; Fri, 13 Sep 2013 08:29:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:26260) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VKSUi-0005k0-LV for qemu-devel@nongnu.org; Fri, 13 Sep 2013 08:29:04 -0400 Date: Fri, 13 Sep 2013 15:31:11 +0300 From: "Michael S. Tsirkin" Message-ID: <20130913123029.GA29506@redhat.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130913122201.GA29092@redhat.com> 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: Eduardo Habkost Cc: Gal Hammer , qemu-devel@nongnu.org, Anthony Liguori 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? Also please try -cpu kvm64,model=2. > > -- > > Eduardo