All of lore.kernel.org
 help / color / mirror / Atom feed
* [Qemu-devel] MSI-X doesn't work when running Windows as guest
@ 2013-09-12  8:23 Gal Hammer
  2013-09-12  8:42 ` Michael S. Tsirkin
  0 siblings, 1 reply; 8+ messages in thread
From: Gal Hammer @ 2013-09-12  8:23 UTC (permalink / raw)
  To: qemu-devel; +Cc: mst

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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Qemu-devel] MSI-X doesn't work when running Windows as guest
  2013-09-12  8:23 [Qemu-devel] MSI-X doesn't work when running Windows as guest Gal Hammer
@ 2013-09-12  8:42 ` Michael S. Tsirkin
  2013-09-12 19:45   ` Eduardo Habkost
  0 siblings, 1 reply; 8+ messages in thread
From: Michael S. Tsirkin @ 2013-09-12  8:42 UTC (permalink / raw)
  To: Gal Hammer; +Cc: qemu-devel, Anthony Liguori, ehabkost

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?

Eduardo?
Anthony?

-- 
MST

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Qemu-devel] MSI-X doesn't work when running Windows as guest
  2013-09-12  8:42 ` Michael S. Tsirkin
@ 2013-09-12 19:45   ` Eduardo Habkost
  2013-09-12 21:03     ` Michael S. Tsirkin
  0 siblings, 1 reply; 8+ messages in thread
From: Eduardo Habkost @ 2013-09-12 19:45 UTC (permalink / raw)
  To: Michael S. Tsirkin; +Cc: Gal Hammer, qemu-devel, Anthony Liguori

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)? What exactly is missing on qemu64 that causes the above
problem?

-- 
Eduardo

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Qemu-devel] MSI-X doesn't work when running Windows as guest
  2013-09-12 19:45   ` Eduardo Habkost
@ 2013-09-12 21:03     ` Michael S. Tsirkin
  2013-09-13  4:14       ` Eduardo Habkost
  0 siblings, 1 reply; 8+ messages in thread
From: Michael S. Tsirkin @ 2013-09-12 21:03 UTC (permalink / raw)
  To: Eduardo Habkost; +Cc: Gal Hammer, qemu-devel, Anthony Liguori

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?

> 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.

> -- 
> Eduardo

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Qemu-devel] MSI-X doesn't work when running Windows as guest
  2013-09-12 21:03     ` Michael S. Tsirkin
@ 2013-09-13  4:14       ` Eduardo Habkost
  2013-09-13 12:22         ` Michael S. Tsirkin
  0 siblings, 1 reply; 8+ messages in thread
From: Eduardo Habkost @ 2013-09-13  4:14 UTC (permalink / raw)
  To: Michael S. Tsirkin; +Cc: Gal Hammer, qemu-devel, Anthony Liguori

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Qemu-devel] MSI-X doesn't work when running Windows as guest
  2013-09-13  4:14       ` Eduardo Habkost
@ 2013-09-13 12:22         ` Michael S. Tsirkin
  2013-09-13 12:31           ` Michael S. Tsirkin
  0 siblings, 1 reply; 8+ messages in thread
From: Michael S. Tsirkin @ 2013-09-13 12:22 UTC (permalink / raw)
  To: Eduardo Habkost; +Cc: Gal Hammer, qemu-devel, Anthony Liguori

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Qemu-devel] MSI-X doesn't work when running Windows as guest
  2013-09-13 12:22         ` Michael S. Tsirkin
@ 2013-09-13 12:31           ` Michael S. Tsirkin
  2013-09-13 13:33             ` Andreas Färber
  0 siblings, 1 reply; 8+ messages in thread
From: Michael S. Tsirkin @ 2013-09-13 12:31 UTC (permalink / raw)
  To: Eduardo Habkost; +Cc: Gal Hammer, qemu-devel, 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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Qemu-devel] MSI-X doesn't work when running Windows as guest
  2013-09-13 12:31           ` Michael S. Tsirkin
@ 2013-09-13 13:33             ` Andreas Färber
  0 siblings, 0 replies; 8+ messages in thread
From: Andreas Färber @ 2013-09-13 13:33 UTC (permalink / raw)
  To: Michael S. Tsirkin
  Cc: Gal Hammer, Hannes Reinecke, Eduardo Habkost, Anthony Liguori,
	qemu-devel

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2013-09-13 13:33 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-09-12  8:23 [Qemu-devel] MSI-X doesn't work when running Windows as guest Gal Hammer
2013-09-12  8:42 ` Michael S. Tsirkin
2013-09-12 19:45   ` Eduardo Habkost
2013-09-12 21:03     ` Michael S. Tsirkin
2013-09-13  4:14       ` Eduardo Habkost
2013-09-13 12:22         ` Michael S. Tsirkin
2013-09-13 12:31           ` Michael S. Tsirkin
2013-09-13 13:33             ` Andreas Färber

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.