[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5614339A.4080007@cloudius-systems.com>
Date: Tue, 6 Oct 2015 23:48:26 +0300
From: Vlad Zolotarov <vladz@...udius-systems.com>
To: "Michael S. Tsirkin" <mst@...hat.com>
Cc: linux-kernel@...r.kernel.org, hjk@...sjkoch.de, corbet@....net,
gregkh@...uxfoundation.org, bruce.richardson@...el.com,
avi@...udius-systems.com, gleb@...udius-systems.com,
stephen@...workplumber.org, alexander.duyck@...il.com
Subject: Re: [PATCH v5 0/4] uio: add MSI/MSI-X support to uio_pci_generic
driver
On 10/06/15 23:35, Vlad Zolotarov wrote:
>
>
> On 10/06/15 21:27, Michael S. Tsirkin wrote:
>> On Tue, Oct 06, 2015 at 08:17:35PM +0300, Vlad Zolotarov wrote:
>>> This series add support for MSI and MSI-X interrupts to
>>> uio_pci_generic driver.
>>>
>>> Currently uio_pci_generic demands INT#x interrupts source be
>>> available. However
>>> there are devices that simply don't have INT#x capability, for
>>> instance SR-IOV
>>> VF devices that simply don't have INT#x capability. For such devices
>>> uio_pci_generic will simply fail (more specifically its probe() will
>>> fail).
>>>
>>> When IOMMU is either not available (e.g. Amazon EC2) or not
>>> acceptable due to
>>> performance overhead and thus VFIO is not an option users that develop
>>> user-space drivers are left without any option but to develop some
>>> proprietary
>>> UIO drivers (e.g. igb_uio driver in Intel's DPDK) just to be able to
>>> use UIO
>>> infrastructure.
>>>
>>> This series provides a generic solution for this problem while
>>> preserving the
>>> original behaviour for devices for which the original
>>> uio_pci_generic had worked
>>> before (i.e. INT#x will be used by default).
>>>
>>> New in v5:
>>> - Expanded the commitlog on PATCH1.
>> Looks like you didn't attempt to address any of my review comments.
>> I don't intend to review this until you do.
>
> So far there hasn't been any comments related to the code in these
> patches from your side but rather comments about the general flaws of
> the current uio_pci_generic in particular and UIO in general that have
> nothing to do with this series. Therefore obviously there was nothing
> to address.
> If u have any comments related to _THIS_ series I'd be glad to
> address. So far I was under the strong impression that u develop an
> obviously theoretical discussion about "nice to have fixed" stuff in
> UIO, which was obvious to everybody on this thread had nothing to do
> with this patch series.
>
> Could it be that I've got u wrong? If so, could u, pls., clarify what
> u'd like me to fix in these patches exactly and why?
I beg my pardon, there was one relevant comment of yours - to split the
bars mapping into a separate patch. And this has been addressed. ;)
>
> thanks,
> vlad
>
>>
>>> New in v4:
>>> - Use portable __u32 and __s32 types from asm/types.h for
>>> defining uio_pci_generic_irq_set fields.
>>> - Use proper _IO macros for defining read and write ioctl()
>>> commands.
>>> - Moved bars mapping setting into a separate patch.
>>> - Update uio_pci_generic example in uio-howto.tmpl.
>>>
>>> New in v3:
>>> - Add __iomem qualifier to temp buffer receiving ioremap value.
>>> New in v2:
>>> - Added #include <linux/uaccess.h> to uio_pci_generic.c
>>>
>>>
>>> Vlad Zolotarov (4):
>>> uio: add ioctl support
>>> uio_pci_generic: properly initialize PCI bars mappings towards UIO
>>> uio_pci_generic: add MSI/MSI-X support
>>> Documentation: update uio-howto
>>>
>>> Documentation/DocBook/uio-howto.tmpl | 139 ++++++++++--
>>> drivers/uio/uio.c | 15 ++
>>> drivers/uio/uio_pci_generic.c | 409
>>> +++++++++++++++++++++++++++++++++--
>>> include/linux/uio_driver.h | 3 +
>>> include/uapi/linux/uio_pci_generic.h | 51 +++++
>>> 5 files changed, 574 insertions(+), 43 deletions(-)
>>> create mode 100644 include/uapi/linux/uio_pci_generic.h
>>>
>>> --
>>> 2.1.0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists