On Thu, Oct 08, 2015 at 10:41:53AM +0300, Michael S. Tsirkin wrote:
> On Thu, Oct 08, 2015 at 07:19:13AM +0300, Gleb Natapov wrote:
> > Well
> > the alternative is to add /dev/vfio/nommu like you've said, but what
> > would be the difference between this and uio eludes me.
>
> Are you familiar with vfio that you ask such a question?
>
Yes, I do and I do not see anything of value that vfio can add to nommu
setup besides complexity, but I do see why it will have to have special
interface not applicable to regular vfio (hint: there is not HW to translate
virtual address to physical) and why it will have to be accessible to
root user only.
> Here's the vfio pci code:
>
> $ wc -l drivers/vfio/pci/*
> 27 drivers/vfio/pci/Kconfig
> 4 drivers/vfio/pci/Makefile
> 1217 drivers/vfio/pci/vfio_pci.c
> 1602 drivers/vfio/pci/vfio_pci_config.c
> 675 drivers/vfio/pci/vfio_pci_intrs.c
> 92 drivers/vfio/pci/vfio_pci_private.h
> 238 drivers/vfio/pci/vfio_pci_rdwr.c
> 3855 total
>
> There's some code dealing with iommu groups in
> drivers/vfio/pci/vfio_pci.c,
> but most of it is validating input and
> presenting a consistent interface to userspace.
>
What is has to do with the patch series in question? Non patched
uio_generic code does not validate input. If you think it should by all
means write the code (don't break existing use cases while doing so),
but the patch under discussion does not even access pci device from
userspace, so it will not be affected by said filtering.
> This is exactly what's missing here.
It is not missing in this patch series, it is missing from upstream
code. I do not remember this been an issue when uio_generic was accepted
into the kernel. The reason was because it meant to be accessible by root
only. VFIO was designed to be used by regular user from ground up, so
obviously unrestricted access to pci space was out of the question.
Different use cases lead to different designs, how surprising.
>
> There's also drivers/vfio/virqfd.c which deals
> with sending interrupts over eventfds correctly.
>
As opposite to this patch that deals with them incorrectly? In what way?
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
