Re: [PATCH v2 2/8] VMCI: dma dg: add MMIO access to registers
On Thu, Feb 03, 2022 at 05:12:31AM -0800, Jorgen Hansen wrote:
> Detect the support for MMIO access through examination of the length
> of the region requested in BAR1. If it is 256KB, the VMCI device
> supports MMIO access to registers.
>
> If MMIO access is supported, map the area of the region used for
> MMIO access (64KB size at offset 128KB).
>
> Add wrapper functions for accessing 32 bit register accesses through
> either MMIO or IO ports based on device configuration.
>
> Sending and receiving datagrams through iowrite8_rep/ioread8_rep is
> left unchanged for now, and will be addressed in a later change.
>
> Reviewed-by: Vishnu Dasa
> Signed-off-by: Jorgen Hansen
> ---
> drivers/misc/vmw_vmci/vmci_guest.c | 68 ++
> include/linux/vmw_vmci_defs.h | 12 ++
> 2 files changed, 62 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/misc/vmw_vmci/vmci_guest.c
> b/drivers/misc/vmw_vmci/vmci_guest.c
> index 1018dc77269d..38ee7ed32ab9 100644
> --- a/drivers/misc/vmw_vmci/vmci_guest.c
> +++ b/drivers/misc/vmw_vmci/vmci_guest.c
> @@ -45,6 +45,7 @@ static u32 vm_context_id = VMCI_INVALID_ID;
> struct vmci_guest_device {
> struct device *dev; /* PCI device we are attached to */
> void __iomem *iobase;
> + void __iomem *mmio_base;
>
> bool exclusive_vectors;
>
> @@ -89,6 +90,21 @@ u32 vmci_get_vm_context_id(void)
> return vm_context_id;
> }
>
> +static unsigned int vmci_read_reg(struct vmci_guest_device *dev, u32 reg)
> +{
> + if (dev->mmio_base != NULL)
> + return readl(dev->mmio_base + reg);
> + return ioread32(dev->iobase + reg);
> +}
> +
> +static void vmci_write_reg(struct vmci_guest_device *dev, u32 val, u32 reg)
> +{
> + if (dev->mmio_base != NULL)
> + writel(val, dev->mmio_base + reg);
> + else
> + iowrite32(val, dev->iobase + reg);
> +}
> +
> /*
> * VM to hypervisor call mechanism. We use the standard VMware naming
> * convention since shared code is calling this function as well.
> @@ -116,7 +132,7 @@ int vmci_send_datagram(struct vmci_datagram *dg)
> if (vmci_dev_g) {
> iowrite8_rep(vmci_dev_g->iobase + VMCI_DATA_OUT_ADDR,
>dg, VMCI_DG_SIZE(dg));
> - result = ioread32(vmci_dev_g->iobase + VMCI_RESULT_LOW_ADDR);
> + result = vmci_read_reg(vmci_dev_g, VMCI_RESULT_LOW_ADDR);
> } else {
> result = VMCI_ERROR_UNAVAILABLE;
> }
> @@ -384,7 +400,7 @@ static irqreturn_t vmci_interrupt(int irq, void *_dev)
> unsigned int icr;
>
> /* Acknowledge interrupt and determine what needs doing. */
> - icr = ioread32(dev->iobase + VMCI_ICR_ADDR);
> + icr = vmci_read_reg(dev, VMCI_ICR_ADDR);
> if (icr == 0 || icr == ~0)
> return IRQ_NONE;
>
> @@ -429,7 +445,8 @@ static int vmci_guest_probe_device(struct pci_dev *pdev,
> const struct pci_device_id *id)
> {
> struct vmci_guest_device *vmci_dev;
> - void __iomem *iobase;
> + void __iomem *iobase = NULL;
> + void __iomem *mmio_base = NULL;
> unsigned int capabilities;
> unsigned int caps_in_use;
> unsigned long cmd;
> @@ -445,16 +462,32 @@ static int vmci_guest_probe_device(struct pci_dev *pdev,
> return error;
> }
>
> - error = pcim_iomap_regions(pdev, 1 << 0, KBUILD_MODNAME);
> - if (error) {
> - dev_err(>dev, "Failed to reserve/map IO regions\n");
> - return error;
> + /*
> + * The VMCI device with mmio access to registers requests 256KB
> + * for BAR1. If present, driver will use new VMCI device
> + * functionality for register access and datagram send/recv.
> + */
> +
> + if (pci_resource_len(pdev, 1) == VMCI_WITH_MMIO_ACCESS_BAR_SIZE) {
> + dev_info(>dev, "MMIO register access is available\n");
> + mmio_base = pci_iomap_range(pdev, 1, VMCI_MMIO_ACCESS_OFFSET,
> + VMCI_MMIO_ACCESS_SIZE);
> + /* If the map fails, we fall back to IOIO access. */
> + if (!mmio_base)
> + dev_warn(>dev, "Failed to map MMIO register
> access\n");
> }
>
> - iobase = pcim_iomap_table(pdev)[0];
> + if (!mmio_base) {
> + error = pcim_iomap_regions(pdev, BIT(0), KBUILD_MODNAME);
> + if (error) {
> + dev_err(>dev, "Failed to reserve/map IO
> regions\n");
> + return error;
> + }
> + iobase = pcim_iomap_table(pdev)[0];
> + }
>
> - dev_info(>dev, "Found VMCI PCI device at %#lx, irq %u\n",
> - (unsigned long)iobase, pdev->irq);
> + dev_info(>dev, "Found VMCI PCI device at %#lx, %#lx, irq %u\n",
> + (unsigned long)iobase, (unsigned long)mmio_base, pdev->irq);
Why are you
Re: [PATCH v2 4/8] VMCI: dma dg: set OS page size
On Thu, Feb 03, 2022 at 05:12:33AM -0800, Jorgen Hansen wrote:
> Tell the device the page size used by the OS.
>
> Reviewed-by: Vishnu Dasa
> Signed-off-by: Jorgen Hansen
> ---
> drivers/misc/vmw_vmci/vmci_guest.c | 9 +
> include/linux/vmw_vmci_defs.h | 1 +
> 2 files changed, 10 insertions(+)
>
> diff --git a/drivers/misc/vmw_vmci/vmci_guest.c
> b/drivers/misc/vmw_vmci/vmci_guest.c
> index 5a99d8e27873..808680dc0820 100644
> --- a/drivers/misc/vmw_vmci/vmci_guest.c
> +++ b/drivers/misc/vmw_vmci/vmci_guest.c
> @@ -581,6 +581,15 @@ static int vmci_guest_probe_device(struct pci_dev *pdev,
> /* Let the host know which capabilities we intend to use. */
> vmci_write_reg(vmci_dev, caps_in_use, VMCI_CAPS_ADDR);
>
> + if (caps_in_use & VMCI_CAPS_DMA_DATAGRAM) {
> + uint32_t page_shift;
> +
> + /* Let the device know the size for pages passed down. */
> + vmci_write_reg(vmci_dev, PAGE_SHIFT, VMCI_GUEST_PAGE_SHIFT);
> + page_shift = vmci_read_reg(vmci_dev, VMCI_GUEST_PAGE_SHIFT);
> + dev_info(>dev, "Using page shift %d\n", page_shift);
Please do not print out debugging stuff like this to the kernel log.
When drivers are working properly, they are quiet.
thanks,
greg k-h
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3] drivers/virtio: Enable virtio mem for ARM64
On 04.02.22 15:04, Michael S. Tsirkin wrote: > On Fri, Feb 04, 2022 at 02:29:39PM +0100, David Hildenbrand wrote: >> On 04.02.22 14:24, Michael S. Tsirkin wrote: >>> On Wed, Jan 19, 2022 at 09:35:05AM +0100, David Hildenbrand wrote: On 19.01.22 08:46, Gavin Shan wrote: > Hi Michael, > > On 1/19/22 3:39 PM, Michael S. Tsirkin wrote: >> On Wed, Jan 19, 2022 at 09:05:51AM +0800, Gavin Shan wrote: >>> This enables virtio-mem device support by allowing to enable the >>> corresponding kernel config option (CONFIG_VIRTIO_MEM) on the >>> architecture. >>> >>> Signed-off-by: Gavin Shan >>> Acked-by: David Hildenbrand >>> Acked-by: Jonathan Cameron >>> Acked-by: Michael S. Tsirkin >>> --- >>> v3: Pick ack-by tags from Jonathan and Michael >>> --- >>> drivers/virtio/Kconfig | 7 --- >>> 1 file changed, 4 insertions(+), 3 deletions(-) >>> >>> diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig >>> index 34f80b7a8a64..74c8b0c7bc33 100644 >>> --- a/drivers/virtio/Kconfig >>> +++ b/drivers/virtio/Kconfig >>> @@ -106,7 +106,7 @@ config VIRTIO_BALLOON >>> config VIRTIO_MEM >>> tristate "Virtio mem driver" >>> default m >>> - depends on X86_64 >>> + depends on X86_64 || ARM64 >>> depends on VIRTIO >>> depends on MEMORY_HOTPLUG >>> depends on MEMORY_HOTREMOVE >>> @@ -116,8 +116,9 @@ config VIRTIO_MEM >>> This driver provides access to virtio-mem paravirtualized >>> memory >>> devices, allowing to hotplug and hotunplug memory. >>> >>> -This driver was only tested under x86-64, but should >>> theoretically >>> -work on all architectures that support memory hotplug and >>> hotremove. >>> +This driver was only tested under x86-64 and arm64, but should >>> +theoretically work on all architectures that support memory >>> hotplug >>> +and hotremove. >>> >> >> BTW isn't there a symbol saying "memory hotplug" that we can depend on? >> You mean depends on MEMORY_HOTPLUG depends on MEMORY_HOTREMOVE We still need a manual opt-in from architectures, because devil's in the detail. (e.g., memblock stuff we had to adjust) >>> >>> Is there any chance of documenting some of this here? The current comment >>> makes it >>> look like it's just a question of whitelisting an architecture. >> >> I can send a patch to add more details. > > oks so that will be a patch on top? Yes, it's independent of arm64 support. -- Thanks, David / dhildenb ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3] drivers/virtio: Enable virtio mem for ARM64
On Fri, Feb 04, 2022 at 02:29:39PM +0100, David Hildenbrand wrote: > On 04.02.22 14:24, Michael S. Tsirkin wrote: > > On Wed, Jan 19, 2022 at 09:35:05AM +0100, David Hildenbrand wrote: > >> On 19.01.22 08:46, Gavin Shan wrote: > >>> Hi Michael, > >>> > >>> On 1/19/22 3:39 PM, Michael S. Tsirkin wrote: > On Wed, Jan 19, 2022 at 09:05:51AM +0800, Gavin Shan wrote: > > This enables virtio-mem device support by allowing to enable the > > corresponding kernel config option (CONFIG_VIRTIO_MEM) on the > > architecture. > > > > Signed-off-by: Gavin Shan > > Acked-by: David Hildenbrand > > Acked-by: Jonathan Cameron > > Acked-by: Michael S. Tsirkin > > --- > > v3: Pick ack-by tags from Jonathan and Michael > > --- > > drivers/virtio/Kconfig | 7 --- > > 1 file changed, 4 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig > > index 34f80b7a8a64..74c8b0c7bc33 100644 > > --- a/drivers/virtio/Kconfig > > +++ b/drivers/virtio/Kconfig > > @@ -106,7 +106,7 @@ config VIRTIO_BALLOON > > config VIRTIO_MEM > > tristate "Virtio mem driver" > > default m > > - depends on X86_64 > > + depends on X86_64 || ARM64 > > depends on VIRTIO > > depends on MEMORY_HOTPLUG > > depends on MEMORY_HOTREMOVE > > @@ -116,8 +116,9 @@ config VIRTIO_MEM > > This driver provides access to virtio-mem paravirtualized > > memory > > devices, allowing to hotplug and hotunplug memory. > > > > -This driver was only tested under x86-64, but should > > theoretically > > -work on all architectures that support memory hotplug and > > hotremove. > > +This driver was only tested under x86-64 and arm64, but should > > +theoretically work on all architectures that support memory > > hotplug > > +and hotremove. > > > > BTW isn't there a symbol saying "memory hotplug" that we can depend on? > > >> > >> You mean > >> > >>depends on MEMORY_HOTPLUG > >>depends on MEMORY_HOTREMOVE > >> > >> We still need a manual opt-in from architectures, because devil's in the > >> detail. (e.g., memblock stuff we had to adjust) > > > > Is there any chance of documenting some of this here? The current comment > > makes it > > look like it's just a question of whitelisting an architecture. > > I can send a patch to add more details. oks so that will be a patch on top? > -- > Thanks, > > David / dhildenb ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3] drivers/virtio: Enable virtio mem for ARM64
On 04.02.22 14:24, Michael S. Tsirkin wrote: > On Wed, Jan 19, 2022 at 09:35:05AM +0100, David Hildenbrand wrote: >> On 19.01.22 08:46, Gavin Shan wrote: >>> Hi Michael, >>> >>> On 1/19/22 3:39 PM, Michael S. Tsirkin wrote: On Wed, Jan 19, 2022 at 09:05:51AM +0800, Gavin Shan wrote: > This enables virtio-mem device support by allowing to enable the > corresponding kernel config option (CONFIG_VIRTIO_MEM) on the > architecture. > > Signed-off-by: Gavin Shan > Acked-by: David Hildenbrand > Acked-by: Jonathan Cameron > Acked-by: Michael S. Tsirkin > --- > v3: Pick ack-by tags from Jonathan and Michael > --- > drivers/virtio/Kconfig | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig > index 34f80b7a8a64..74c8b0c7bc33 100644 > --- a/drivers/virtio/Kconfig > +++ b/drivers/virtio/Kconfig > @@ -106,7 +106,7 @@ config VIRTIO_BALLOON > config VIRTIO_MEM > tristate "Virtio mem driver" > default m > - depends on X86_64 > + depends on X86_64 || ARM64 > depends on VIRTIO > depends on MEMORY_HOTPLUG > depends on MEMORY_HOTREMOVE > @@ -116,8 +116,9 @@ config VIRTIO_MEM >This driver provides access to virtio-mem paravirtualized > memory >devices, allowing to hotplug and hotunplug memory. > > - This driver was only tested under x86-64, but should theoretically > - work on all architectures that support memory hotplug and hotremove. > + This driver was only tested under x86-64 and arm64, but should > + theoretically work on all architectures that support memory hotplug > + and hotremove. > BTW isn't there a symbol saying "memory hotplug" that we can depend on? >> >> You mean >> >> depends on MEMORY_HOTPLUG >> depends on MEMORY_HOTREMOVE >> >> We still need a manual opt-in from architectures, because devil's in the >> detail. (e.g., memblock stuff we had to adjust) > > Is there any chance of documenting some of this here? The current comment > makes it > look like it's just a question of whitelisting an architecture. I can send a patch to add more details. -- Thanks, David / dhildenb ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3] drivers/virtio: Enable virtio mem for ARM64
On Wed, Jan 19, 2022 at 09:35:05AM +0100, David Hildenbrand wrote: > On 19.01.22 08:46, Gavin Shan wrote: > > Hi Michael, > > > > On 1/19/22 3:39 PM, Michael S. Tsirkin wrote: > >> On Wed, Jan 19, 2022 at 09:05:51AM +0800, Gavin Shan wrote: > >>> This enables virtio-mem device support by allowing to enable the > >>> corresponding kernel config option (CONFIG_VIRTIO_MEM) on the > >>> architecture. > >>> > >>> Signed-off-by: Gavin Shan > >>> Acked-by: David Hildenbrand > >>> Acked-by: Jonathan Cameron > >>> Acked-by: Michael S. Tsirkin > >>> --- > >>> v3: Pick ack-by tags from Jonathan and Michael > >>> --- > >>> drivers/virtio/Kconfig | 7 --- > >>> 1 file changed, 4 insertions(+), 3 deletions(-) > >>> > >>> diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig > >>> index 34f80b7a8a64..74c8b0c7bc33 100644 > >>> --- a/drivers/virtio/Kconfig > >>> +++ b/drivers/virtio/Kconfig > >>> @@ -106,7 +106,7 @@ config VIRTIO_BALLOON > >>> config VIRTIO_MEM > >>> tristate "Virtio mem driver" > >>> default m > >>> - depends on X86_64 > >>> + depends on X86_64 || ARM64 > >>> depends on VIRTIO > >>> depends on MEMORY_HOTPLUG > >>> depends on MEMORY_HOTREMOVE > >>> @@ -116,8 +116,9 @@ config VIRTIO_MEM > >>>This driver provides access to virtio-mem paravirtualized > >>> memory > >>>devices, allowing to hotplug and hotunplug memory. > >>> > >>> - This driver was only tested under x86-64, but should theoretically > >>> - work on all architectures that support memory hotplug and hotremove. > >>> + This driver was only tested under x86-64 and arm64, but should > >>> + theoretically work on all architectures that support memory hotplug > >>> + and hotremove. > >>> > >> > >> BTW isn't there a symbol saying "memory hotplug" that we can depend on? > >> > > You mean > > depends on MEMORY_HOTPLUG > depends on MEMORY_HOTREMOVE > > We still need a manual opt-in from architectures, because devil's in the > detail. (e.g., memblock stuff we had to adjust) Is there any chance of documenting some of this here? The current comment makes it look like it's just a question of whitelisting an architecture. > -- > Thanks, > > David / dhildenb ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
