Headsup: windows virtio networking does not work on current git

Qemu-devel Michael S. Tsirkin 3 participants 4 messages Feb 7, 2013 10 messages not in the archive virtio core

lore

Share & tools

lore

A message that is not in the archive (sent off-list or not yet received): 1359981484.1968.29.camel@localhost

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): 1360063865.1968.85.camel@localhost

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): 1360144040.1968.119.camel@localhost

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): 1360229050.1968.149.camel@localhost

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): 1360234419.1968.162.camel@localhost

Michael S. Tsirkin

author maintainer

2013-02-07 11:33 UTC #10 lore raw

Quoted 35 lines · Vadim Rozenfeld

Quoted 34 lines · Michael S. Tsirkin
Quoted 12 lines · Vadim Rozenfeld
Quoted 10 lines · Rusty Russell
Quoted 6 lines · Vadim Rozenfeld
Quoted 3 lines · Michael S. Tsirkin
On Tue, Feb 05, 2013 at 03:45:38PM +0400, Michael Tokarev wrote:
Is it really
Quoted 1 line
that bad that the config space size changed? Why it has this effect?
Because in this case it's hard to distinguish between resource's corruption and HW update.
But it's also true that if we'd incremented revid you'd have the same failure in this case, right?
Quoted 11 lines
It depends. If we have explicitly specified revision id in inf file and this id doesn't mach the new revision id, Windows will not try to load the "incompatible" driver, and finish up with "device driver not found" dialog.
Best regards,
Vadim.
Quoted 3 lines
Cheers,
Rusty.
Well that's all in theory, in practice it does not look like revision ID is specified in the NetKVM inf so this won't work?
From what I see this inf specifies:
NetKVM/wlh/netkvm.inf:%kvmnet6.DeviceDesc% = kvmnet6.ndi, PCI\VEN_1AF4&DEV_1000&SUBSYS_00011AF4
NetKVM/wxp/netkvm.inf:%kvmnet5.DeviceDesc% = kvmnet5.ndi, PCI\VEN_1AF4&DEV_1000&SUBSYS_00011AF4
NetKVM/wxp/netkvm2k.inf:%kvmnet5.DeviceDesc% = kvmnet5.ndi, PCI\VEN_1AF4&DEV_1000&SUBSYS_00011AF4

Quoted 5 lines

Quoted 2 lines
So we can tweak any of vendor device and subsystem id.
Unfortunately, it won't. Only balloon has revision id, specified as a part of device HW descriptor. But it's only because virtio doesn't use revision ids. Otherwise it differential will be there.

So your driver will load and attempt to work on rev=2 devices? If yes it's a bug. virtio spec specifies revision id as an ABI version. Linux driver does:

        if (pci_dev->revision != VIRTIO_PCI_ABI_VERSION) {
                printk(KERN_ERR "virtio_pci: expected ABI version %d, got %d\n",
                       VIRTIO_PCI_ABI_VERSION, pci_dev->revision);
                return -ENODEV;
        }

Quoted 11 lines

Quoted 10 lines
Changing subsystem vendor ID actually will be completely transparent to linux which for some reason looks at the subsystem device ID (why? no idea) but not the subsystem vendor ID. Of course this requires a valid vendor ID, getting this costs $3000 I think.
We could tweak device ID too but that might break some other guests which don't copy the crazy 'replace device id with subsystem device id' logic from Linux.

Apropos, would you guys like to start to copy your patches to [email protected]?
If you do, you might get some review and feedback, allowing us to catch such forward compatibility issues earlier.

Of course it's your project so entirely up to you.

Signature · 1 line

MST

Vadim Rozenfeld

2013-02-07 11:46 UTC #11 lore raw

Quoted 36 lines · Michael S. Tsirkin

Quoted 35 lines · Vadim Rozenfeld
Quoted 34 lines · Michael S. Tsirkin
Quoted 12 lines · Vadim Rozenfeld
Quoted 10 lines · Rusty Russell
Quoted 6 lines · Vadim Rozenfeld
Quoted 3 lines · Michael S. Tsirkin
On Tue, Feb 05, 2013 at 03:45:38PM +0400, Michael Tokarev wrote:
Is it really
Quoted 1 line
that bad that the config space size changed? Why it has this effect?
Because in this case it's hard to distinguish between resource's corruption and HW update.
But it's also true that if we'd incremented revid you'd have the same failure in this case, right?
Quoted 11 lines
It depends. If we have explicitly specified revision id in inf file and this id doesn't mach the new revision id, Windows will not try to load the "incompatible" driver, and finish up with "device driver not found" dialog.
Best regards,
Vadim.
Quoted 3 lines
Cheers,
Rusty.
Well that's all in theory, in practice it does not look like revision ID is specified in the NetKVM inf so this won't work?
From what I see this inf specifies:
NetKVM/wlh/netkvm.inf:%kvmnet6.DeviceDesc% = kvmnet6.ndi, PCI\VEN_1AF4&DEV_1000&SUBSYS_00011AF4
NetKVM/wxp/netkvm.inf:%kvmnet5.DeviceDesc% = kvmnet5.ndi, PCI\VEN_1AF4&DEV_1000&SUBSYS_00011AF4
NetKVM/wxp/netkvm2k.inf:%kvmnet5.DeviceDesc% = kvmnet5.ndi, PCI\VEN_1AF4&DEV_1000&SUBSYS_00011AF4

Quoted 7 lines

Quoted 5 lines
Quoted 2 lines
So we can tweak any of vendor device and subsystem id.
Unfortunately, it won't. Only balloon has revision id, specified as a part of device HW descriptor. But it's only because virtio doesn't use revision ids. Otherwise it differential will be there.
So your driver will load and attempt to work on rev=2 devices?

All virtio-win drivers (net, serial, block, and scsi), except for balloon will.

Quoted 30 lines

If yes it's a bug. virtio spec specifies revision id as an ABI version. Linux driver does:
        if (pci_dev->revision != VIRTIO_PCI_ABI_VERSION) {
                printk(KERN_ERR "virtio_pci: expected ABI version %d, got %d\n",
                       VIRTIO_PCI_ABI_VERSION, pci_dev->revision);
                return -ENODEV;
        }
Quoted 11 lines
Quoted 10 lines
Changing subsystem vendor ID actually will be completely transparent to linux which for some reason looks at the subsystem device ID (why? no idea) but not the subsystem vendor ID. Of course this requires a valid vendor ID, getting this costs $3000 I think.
We could tweak device ID too but that might break some other guests which don't copy the crazy 'replace device id with subsystem device id' logic from Linux.
Apropos, would you guys like to start to copy your patches to [email protected]?
If you do, you might get some review and feedback, allowing us to catch such forward compatibility issues earlier.
Of course it's your project so entirely up to you.

Yan Vugenfirer

2013-02-07 13:02 UTC #12 lore raw

Quoted 39 lines · Vadim Rozenfeld

Quoted 38 lines · Michael S. Tsirkin
Quoted 37 lines · Vadim Rozenfeld
Quoted 36 lines · Michael S. Tsirkin
Quoted 12 lines · Vadim Rozenfeld
Quoted 10 lines · Rusty Russell
Quoted 6 lines · Vadim Rozenfeld
Quoted 3 lines · Michael S. Tsirkin
On Tue, Feb 05, 2013 at 03:45:38PM +0400, Michael Tokarev wrote:
Is it really
Quoted 1 line
that bad that the config space size changed? Why it has this effect?
Because in this case it's hard to distinguish between resource's corruption and HW update.
But it's also true that if we'd incremented revid you'd have the same failure in this case, right?
Quoted 11 lines
It depends. If we have explicitly specified revision id in inf file and this id doesn't mach the new revision id, Windows will not try to load the "incompatible" driver, and finish up with "device driver not found" dialog.
Best regards,
Vadim.
Quoted 3 lines
Cheers,
Rusty.
Well that's all in theory, in practice it does not look like revision ID is specified in the NetKVM inf so this won't work?
From what I see this inf specifies:
NetKVM/wlh/netkvm.inf:%kvmnet6.DeviceDesc% = kvmnet6.ndi, PCI\VEN_1AF4&DEV_1000&SUBSYS_00011AF4
NetKVM/wxp/netkvm.inf:%kvmnet5.DeviceDesc% = kvmnet5.ndi, PCI\VEN_1AF4&DEV_1000&SUBSYS_00011AF4
NetKVM/wxp/netkvm2k.inf:%kvmnet5.DeviceDesc% = kvmnet5.ndi, PCI\VEN_1AF4&DEV_1000&SUBSYS_00011AF4
So we can tweak any of vendor device and subsystem id.

Quoted 18 lines

Quoted 5 lines
Quoted 3 lines
Unfortunately, it won't. Only balloon has revision id, specified as a part of device HW descriptor. But it's only because virtio doesn't use revision ids. Otherwise it differential will be there.
So your driver will load and attempt to work on rev=2 devices?
All virtio-win drivers (net, serial, block, and scsi), except for balloon will.
Quoted 9 lines
If yes it's a bug. virtio spec specifies revision id as an ABI version. Linux driver does:
       if (pci_dev->revision != VIRTIO_PCI_ABI_VERSION) {
               printk(KERN_ERR "virtio_pci: expected ABI version %d, got %d\n",
                      VIRTIO_PCI_ABI_VERSION, pci_dev->revision);
               return -ENODEV;
       }

We can add it from next release. Provided that everyone understand the consequences especially for boot devices (virtio-block and virtio-scsi).

Quoted 23 lines

Quoted 21 lines
Quoted 12 lines
Quoted 11 lines
Changing subsystem vendor ID actually will be completely transparent to linux which for some reason looks at the subsystem device ID (why? no idea) but not the subsystem vendor ID. Of course this requires a valid vendor ID, getting this costs $3000 I think.
We could tweak device ID too but that might break some other guests which don't copy the crazy 'replace device id with subsystem device id' logic from Linux.
Apropos, would you guys like to start to copy your patches to [email protected]?
If you do, you might get some review and feedback, allowing us to catch such forward compatibility issues earlier.
Of course it's your project so entirely up to you.

Michael S. Tsirkin

author maintainer

2013-02-07 13:10 UTC #13 lore raw

Quoted 54 lines · Yan Vugenfirer

Quoted 51 lines · Vadim Rozenfeld
Quoted 36 lines · Michael S. Tsirkin
Quoted 35 lines · Vadim Rozenfeld
Quoted 34 lines · Michael S. Tsirkin
Quoted 12 lines · Vadim Rozenfeld
Quoted 10 lines · Rusty Russell
Quoted 6 lines · Vadim Rozenfeld
Quoted 3 lines · Michael S. Tsirkin
On Tue, Feb 05, 2013 at 03:45:38PM +0400, Michael Tokarev wrote:
Is it really
Quoted 1 line
that bad that the config space size changed? Why it has this effect?
Because in this case it's hard to distinguish between resource's corruption and HW update.
But it's also true that if we'd incremented revid you'd have the same failure in this case, right?
Quoted 11 lines
It depends. If we have explicitly specified revision id in inf file and this id doesn't mach the new revision id, Windows will not try to load the "incompatible" driver, and finish up with "device driver not found" dialog.
Best regards,
Vadim.
Quoted 3 lines
Cheers,
Rusty.
Well that's all in theory, in practice it does not look like revision ID is specified in the NetKVM inf so this won't work?
From what I see this inf specifies:
NetKVM/wlh/netkvm.inf:%kvmnet6.DeviceDesc% = kvmnet6.ndi, PCI\VEN_1AF4&DEV_1000&SUBSYS_00011AF4
NetKVM/wxp/netkvm.inf:%kvmnet5.DeviceDesc% = kvmnet5.ndi, PCI\VEN_1AF4&DEV_1000&SUBSYS_00011AF4
NetKVM/wxp/netkvm2k.inf:%kvmnet5.DeviceDesc% = kvmnet5.ndi, PCI\VEN_1AF4&DEV_1000&SUBSYS_00011AF4
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
So we can tweak any of vendor device and subsystem id.
Unfortunately, it won't. Only balloon has revision id, specified as a part of device HW descriptor. But it's only because virtio doesn't use revision ids. Otherwise it differential will be there.
So your driver will load and attempt to work on rev=2 devices?
All virtio-win drivers (net, serial, block, and scsi), except for balloon will.
Quoted 3 lines
If yes it's a bug. virtio spec specifies revision id as an ABI version. Linux driver does:

Quoted 9 lines

Quoted 6 lines
Quoted 6 lines
       if (pci_dev->revision != VIRTIO_PCI_ABI_VERSION) {
               printk(KERN_ERR "virtio_pci: expected ABI version %d, got %d\n",
                      VIRTIO_PCI_ABI_VERSION, pci_dev->revision);
               return -ENODEV;
       }
We can add it from next release. Provided that everyone understand the consequences especially for boot devices (virtio-block and virtio-scsi).

Same as Linux - guest won't boot.

Quoted 23 lines

Quoted 23 lines
Quoted 21 lines
Quoted 12 lines
Quoted 11 lines
Changing subsystem vendor ID actually will be completely transparent to linux which for some reason looks at the subsystem device ID (why? no idea) but not the subsystem vendor ID. Of course this requires a valid vendor ID, getting this costs $3000 I think.
We could tweak device ID too but that might break some other guests which don't copy the crazy 'replace device id with subsystem device id' logic from Linux.
Apropos, would you guys like to start to copy your patches to [email protected]?
If you do, you might get some review and feedback, allowing us to catch such forward compatibility issues earlier.
Of course it's your project so entirely up to you.