similar to: [PATCH] virtio_pci_modern: validate features

This is just repost of all patches with fixups squashed in - convenient if you just want to remove old ones from queue and apply new ones. I also tweaked commit log for patch "virtio_pci: modern driver" I also included Gerd's tag: Tested-by: Gerd Hoffmann <kraxel at redhat.com> You can find it all before the rebase -i --autosquash in my tree:

This is just repost of all patches with fixups squashed in - convenient if you just want to remove old ones from queue and apply new ones. I also tweaked commit log for patch "virtio_pci: modern driver" I also included Gerd's tag: Tested-by: Gerd Hoffmann <kraxel at redhat.com> You can find it all before the rebase -i --autosquash in my tree:

This is just the full patchset reposted with fixups in correct order, before squashing them. I also tweaked commit log for patch "virtio_pci: modern driver" I also included Gerd's tag: Tested-by: Gerd Hoffmann <kraxel at redhat.com> You can find it all before the rebase -i --autosquash in my tree: git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git virtio-next

This is just the full patchset reposted with fixups in correct order, before squashing them. I also tweaked commit log for patch "virtio_pci: modern driver" I also included Gerd's tag: Tested-by: Gerd Hoffmann <kraxel at redhat.com> You can find it all before the rebase -i --autosquash in my tree: git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git virtio-next

Lightly tested against qemu. One thing *not* implemented here is separate mappings for descriptor/avail/used rings. That's nice to have, will be done later after we have core support. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/virtio/virtio_pci_common.h | 29 +- drivers/virtio/virtio_pci_common.c | 13 +- drivers/virtio/virtio_pci_modern.c | 645

Lightly tested against qemu. One thing *not* implemented here is separate mappings for descriptor/avail/used rings. That's nice to have, will be done later after we have core support. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/virtio/virtio_pci_common.h | 29 +- drivers/virtio/virtio_pci_common.c | 13 +- drivers/virtio/virtio_pci_modern.c | 645

Changes since v2: handling for devices without config space (e.g. rng) reduce # of mappings for VQs These patches seem to work fine on my virtio-1.0 qemu branch. There haven't been any bugs since v2: just minor cleanups and enhancements. QEMU side is still undergoing polishing, but is already testable. Rusty, what do you think? Let's merge these for 3.20? Also - will you be doing that

Changes since v2: handling for devices without config space (e.g. rng) reduce # of mappings for VQs These patches seem to work fine on my virtio-1.0 qemu branch. There haven't been any bugs since v2: just minor cleanups and enhancements. QEMU side is still undergoing polishing, but is already testable. Rusty, what do you think? Let's merge these for 3.20? Also - will you be doing that

QEMU wants it, so why not? Trust, but verify. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> --- include/uapi/linux/virtio_pci.h | 30 ++++++++++++++++++ drivers/virtio/virtio_pci_modern.c | 63 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 93 insertions(+) diff --git a/include/uapi/linux/virtio_pci.h b/include/uapi/linux/virtio_pci.h index 28c2ce0..5d546c6 100644

QEMU wants it, so why not? Trust, but verify. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> --- include/uapi/linux/virtio_pci.h | 30 ++++++++++++++++++ drivers/virtio/virtio_pci_modern.c | 63 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 93 insertions(+) diff --git a/include/uapi/linux/virtio_pci.h b/include/uapi/linux/virtio_pci.h index 28c2ce0..5d546c6 100644

This should allow testing when QEMU gets VIRTIO_PCI_CAP_PCI_CFG support, but I'm pretty sure we should never allow these patches upstream. Tested with lguest (in virtio-next), which supports VIRTIO_PCI_CAP_PCI_CFG. Rusty Russell (2): virtio_pci: abstract all MMIO accesses. virtio: Introducing virtio_pci.no_mmio, the worst boot option in history. drivers/virtio/virtio_pci_common.c |

This should allow testing when QEMU gets VIRTIO_PCI_CAP_PCI_CFG support, but I'm pretty sure we should never allow these patches upstream. Tested with lguest (in virtio-next), which supports VIRTIO_PCI_CAP_PCI_CFG. Rusty Russell (2): virtio_pci: abstract all MMIO accesses. virtio: Introducing virtio_pci.no_mmio, the worst boot option in history. drivers/virtio/virtio_pci_common.c |

Move resource allocation from common code to legacy and modern code. Only request resources actually used, i.e. bar0 in legacy mode and the bar(s) specified by capabilities in modern mode. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/virtio/virtio_pci_common.c | 7 ------- drivers/virtio/virtio_pci_common.h | 2 ++ drivers/virtio/virtio_pci_legacy.c | 13 ++++++++++++-

Move resource allocation from common code to legacy and modern code. Only request resources actually used, i.e. bar0 in legacy mode and the bar(s) specified by capabilities in modern mode. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/virtio/virtio_pci_common.c | 7 ------- drivers/virtio/virtio_pci_common.h | 2 ++ drivers/virtio/virtio_pci_legacy.c | 13 ++++++++++++-

Move resource allocation from common code to legacy and modern code. Only request resources actually used, i.e. bar0 in legacy mode and the bar(s) specified by capabilities in modern mode. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/virtio/virtio_pci_common.c | 7 ------- drivers/virtio/virtio_pci_common.h | 2 ++ drivers/virtio/virtio_pci_legacy.c | 13 ++++++++++++-

Move resource allocation from common code to legacy and modern code. Only request resources actually used, i.e. bar0 in legacy mode and the bar(s) specified by capabilities in modern mode. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/virtio/virtio_pci_common.c | 7 ------- drivers/virtio/virtio_pci_common.h | 2 ++ drivers/virtio/virtio_pci_legacy.c | 13 ++++++++++++-

On 2019/11/5 ??5:37, Zhu Lingshan wrote: > This commit introduced ifcvf_base layer, which handles hardware > operations and configurations. It looks like the PCI layout is pretty similar to virtio. Can we reuse e.g virtio_pci_modern_probe() (or helpers in virtio_pci_modern.c) to do the probing? > > Signed-off-by: Zhu Lingshan <lingshan.zhu at intel.com> > --- >

This is on top of 3.19 master + my bugfix patches, and adds virtio 1.0 support to virtio pci. This is 3.20 material I think. Would like to get feedback on s390 change as it's untested. Michael S Tsirkin (2): pci: add pci_iomap_range s390: add pci_iomap_range Michael S. Tsirkin (2): virtio_pci: modern driver virtio_pci: macros for PCI layout offsets. Rusty Russell (1): virtio-pci:

This is on top of 3.19 master + my bugfix patches, and adds virtio 1.0 support to virtio pci. This is 3.20 material I think. Would like to get feedback on s390 change as it's untested. Michael S Tsirkin (2): pci: add pci_iomap_range s390: add pci_iomap_range Michael S. Tsirkin (2): virtio_pci: modern driver virtio_pci: macros for PCI layout offsets. Rusty Russell (1): virtio-pci:

To add a bit of vendor flexibility with various virtio based devices, allow the caller to check for a different device id. This adds a function pointer field to struct virtio_pci_modern_device to specify an override device id check. If defined by the driver, this function will be called to check that the PCI device is the vendor's expected device, and will return the found device id to be