Parav Pandit
2023-Oct-26 12:40 UTC
[PATCH V1 vfio 9/9] vfio/virtio: Introduce a vfio driver over virtio devices
> From: Michael S. Tsirkin <mst at redhat.com> > Sent: Thursday, October 26, 2023 5:42 PM > > On Thu, Oct 26, 2023 at 03:08:12PM +0300, Yishai Hadas wrote: > > > > Makes sense ? > > > So do I understand correctly that virtio dictates the subsystem > > > device ID for all subsystem vendor IDs that implement a legacy > > > virtio interface? Ok, but this device didn't actually implement a > > > legacy virtio interface. The device itself is not tranistional, > > > we're imposing an emulated transitional interface onto it. So did > > > the subsystem vendor agree to have their subsystem device ID managed > > > by the virtio committee or might we create conflicts? I imagine we > > > know we don't have a conflict if we also virtualize the subsystem vendor ID. > > > > > The non transitional net device in the virtio spec defined as the > > below tuple. > > T_A: VID=0x1AF4, DID=0x1040, Subsys_VID=FOO, Subsys_DID=0x40. > > > > And transitional net device in the virtio spec for a vendor FOO is > > defined > > as: > > T_B: VID=0x1AF4,DID=0x1000,Subsys_VID=FOO, subsys_DID=0x1 > > > > This driver is converting T_A to T_B, which both are defined by the > > virtio spec. > > Hence, it does not conflict for the subsystem vendor, it is fine. > > You are talking about legacy guests, what 1.X spec says about them is much less > important than what guests actually do. > Check the INF of the open source windows drivers and linux code, at least.Linux legacy guest has, static struct pci_device_id virtio_pci_id_table[] = { { 0x1af4, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 }, { 0 }, }; Followed by an open coded driver check for 0x1000 to 0x103f range. Do you mean windows driver expects specific subsystem vendor id of 0x1af4?
Michael S. Tsirkin
2023-Oct-26 13:15 UTC
[PATCH V1 vfio 9/9] vfio/virtio: Introduce a vfio driver over virtio devices
On Thu, Oct 26, 2023 at 12:40:04PM +0000, Parav Pandit wrote:> > From: Michael S. Tsirkin <mst at redhat.com> > > Sent: Thursday, October 26, 2023 5:42 PM > > > > On Thu, Oct 26, 2023 at 03:08:12PM +0300, Yishai Hadas wrote: > > > > > Makes sense ? > > > > So do I understand correctly that virtio dictates the subsystem > > > > device ID for all subsystem vendor IDs that implement a legacy > > > > virtio interface? Ok, but this device didn't actually implement a > > > > legacy virtio interface. The device itself is not tranistional, > > > > we're imposing an emulated transitional interface onto it. So did > > > > the subsystem vendor agree to have their subsystem device ID managed > > > > by the virtio committee or might we create conflicts? I imagine we > > > > know we don't have a conflict if we also virtualize the subsystem vendor ID. > > > > > > > The non transitional net device in the virtio spec defined as the > > > below tuple. > > > T_A: VID=0x1AF4, DID=0x1040, Subsys_VID=FOO, Subsys_DID=0x40. > > > > > > And transitional net device in the virtio spec for a vendor FOO is > > > defined > > > as: > > > T_B: VID=0x1AF4,DID=0x1000,Subsys_VID=FOO, subsys_DID=0x1 > > > > > > This driver is converting T_A to T_B, which both are defined by the > > > virtio spec. > > > Hence, it does not conflict for the subsystem vendor, it is fine. > > > > You are talking about legacy guests, what 1.X spec says about them is much less > > important than what guests actually do. > > Check the INF of the open source windows drivers and linux code, at least. > > Linux legacy guest has, > > static struct pci_device_id virtio_pci_id_table[] = { > { 0x1af4, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 }, > { 0 }, > }; > Followed by an open coded driver check for 0x1000 to 0x103f range. > Do you mean windows driver expects specific subsystem vendor id of 0x1af4?Look it up, it's open source.