similar to: No subject

Here's an updated vesion. I'm alternating between updating the spec and the driver, spec update to follow. Compiled only. Posting here for early feedback, and to allow Sasha to proceed with his "kvm tool" work. Changes from v2: address comments by Rusty bugfixes by Sasha Changes from v1: Updated to match v3 of the spec, see: todo: split core changes out Signed-off-by:

Here's an updated vesion. I'm alternating between updating the spec and the driver, spec update to follow. Compiled only. Posting here for early feedback, and to allow Sasha to proceed with his "kvm tool" work. Changes from v2: address comments by Rusty bugfixes by Sasha Changes from v1: Updated to match v3 of the spec, see: todo: split core changes out Signed-off-by:

Add a flexible mechanism to specify virtio configuration layout, using pci vendor-specific capability. A separate capability is used for each of common, device specific and data-path accesses. Warning: compiled only. This patch also needs to be split up, pci_iomap changes also need arch updates for non-x86. There might also be more spec changes. Posting here for early feedback, and to allow

Add a flexible mechanism to specify virtio configuration layout, using pci vendor-specific capability. A separate capability is used for each of common, device specific and data-path accesses. Warning: compiled only. This patch also needs to be split up, pci_iomap changes also need arch updates for non-x86. There might also be more spec changes. Posting here for early feedback, and to allow

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

Since PCI is little endian, 8-bit access might work, but the spec section is very clear on this: 4.1.3.1 Driver Requirements: PCI Device Layout The driver MUST access each field using the ?natural? access method, i.e. 32-bit accesses for 32-bit fields, 16-bit accesses for 16-bit fields and 8-bit accesses for 8-bit fields. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au>

Since PCI is little endian, 8-bit access might work, but the spec section is very clear on this: 4.1.3.1 Driver Requirements: PCI Device Layout The driver MUST access each field using the ?natural? access method, i.e. 32-bit accesses for 32-bit fields, 16-bit accesses for 16-bit fields and 8-bit accesses for 8-bit fields. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au>

Signed-off-by: Christoph Hellwig <hch at lst.de> --- drivers/virtio/virtio_pci_common.c | 5 ++--- drivers/virtio/virtio_pci_common.h | 2 -- drivers/virtio/virtio_pci_legacy.c | 2 +- drivers/virtio/virtio_pci_modern.c | 2 +- include/uapi/linux/virtio_pci.h | 2 +- 5 files changed, 5 insertions(+), 8 deletions(-) diff --git a/drivers/virtio/virtio_pci_common.c

Pertti Kellomäki wrote: > John Criswell kirjoitti: > >> So, let me see if I understand this right: >> >> First, it sounds like you're programming on the bare processor, so your >> I/O instructions are either special processor instructions or volatile >> loads/stores to special memory locations. >> > > Yes. In more detail, instruction

We don't really need struct virtio_pci_vq_info, as most field in there are redundant: - the vq backpointer is not strictly neede to start with - the entry in the vqs list is not needed - the generic virtqueue already has list, we only need to check if it has a callback to get the same semantics - we can use a simple array to look up the MSI-X vec if needed. - That simple array now

We don't really need struct virtio_pci_vq_info, as most field in there are redundant: - the vq backpointer is not strictly neede to start with - the entry in the vqs list is not needed - the generic virtqueue already has list, we only need to check if it has a callback to get the same semantics - we can use a simple array to look up the MSI-X vec if needed. - That simple array now

On Tue, Feb 07, 2017 at 03:17:02PM +0800, Jason Wang wrote: > The check is still there. Meh, I could swear I fixed it up. Here is an updated version: --- >From bf5e3b7fd272aea32388570503f00d0ab592fc2a Mon Sep 17 00:00:00 2001 From: Christoph Hellwig <hch at lst.de> Date: Wed, 25 Jan 2017 13:40:21 +0100 Subject: virtio_pci: remove struct virtio_pci_vq_info We don't really need

Virtio drivers should map the part of the BAR they need, not necessarily all of it. Cc: Bjorn Helgaas <bhelgaas at google.com> Cc: linux-pci at vger.kernel.org Acked-by: Arnd Bergmann <arnd at arndb.de> Signed-off-by: Michael S. Tsirkin <mst at redhat.com> Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> --- Bjorn, can you please ack this for merging through the

Virtio drivers should map the part of the BAR they need, not necessarily all of it. Cc: Bjorn Helgaas <bhelgaas at google.com> Cc: linux-pci at vger.kernel.org Acked-by: Arnd Bergmann <arnd at arndb.de> Signed-off-by: Michael S. Tsirkin <mst at redhat.com> Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> --- Bjorn, can you please ack this for merging through the

From: Michael S Tsirkin <mst at redhat.com> Virtio drivers should map the part of the range they need, not necessarily all of it. They also need non-cacheable mapping even for prefetchable BARs. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> --- include/asm-generic/pci_iomap.h | 5 +++++ lib/pci_iomap.c

From: Michael S Tsirkin <mst at redhat.com> Virtio drivers should map the part of the range they need, not necessarily all of it. They also need non-cacheable mapping even for prefetchable BARs. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> --- include/asm-generic/pci_iomap.h | 5 +++++ lib/pci_iomap.c

This implements optional MSI-X support in virtio_pci. MSI-X is used whenever the host supports at least 2 MSI-X vectors: 1 for configuration changes and 1 for virtqueues. Per-virtqueue vectors are allocated if enough vectors available. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/virtio/virtio_pci.c | 227 +++++++++++++++++++++++++++++++++++++++----

This implements optional MSI-X support in virtio_pci. MSI-X is used whenever the host supports at least 2 MSI-X vectors: 1 for configuration changes and 1 for virtqueues. Per-virtqueue vectors are allocated if enough vectors available. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/virtio/virtio_pci.c | 227 +++++++++++++++++++++++++++++++++++++++----

This implements optional MSI-X support in virtio_pci. MSI-X is used whenever the host supports at least 2 MSI-X vectors: 1 for configuration changes and 1 for virtqueues. Per-virtqueue vectors are allocated if enough vectors available. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/virtio/virtio_pci.c | 227 +++++++++++++++++++++++++++++++++++++++----