lkml.org 
[lkml]   [2013]   [Jul]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH] uio: uio_pci_generic: Add support for MSI interrupts
    On Thu, Jul 04, 2013 at 09:35:00AM -0700, Guenter Roeck wrote:
    > On Thu, Jul 04, 2013 at 05:34:12PM +0300, Michael S. Tsirkin wrote:
    > > On Thu, Jul 04, 2013 at 07:25:23AM -0700, Guenter Roeck wrote:
    > > > On Thu, Jul 04, 2013 at 10:20:23AM +0300, Michael S. Tsirkin wrote:
    > > > > On Thu, Jun 27, 2013 at 10:00:52AM -0700, Guenter Roeck wrote:
    > > > > > On Thu, Jun 27, 2013 at 10:45:01AM +0300, Michael S. Tsirkin wrote:
    > > > > > > On Wed, Jun 26, 2013 at 03:30:23PM -0700, Guenter Roeck wrote:
    > > > > > > > Enable support for MSI interrupts if the device supports it.
    > > > > > > > Since MSI interrupts are edge triggered, it is no longer necessary to
    > > > > > > > disable interrupts in the kernel and re-enable them from user-space.
    > > > > > > > Instead, clearing the interrupt condition in the user space application
    > > > > > > > automatically re-enables the interrupt.
    > > > > > > >
    > > > > > > > Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    > > > > > > > ---
    > > > > > > > An open question is if we can just do this unconditionally
    > > > > > > > or if there should be some flag to enable it. A module parameter, maybe ?
    > > > > > >
    > > > > > > NACK
    > > > > > >
    > > > > > > UIO is for devices that don't do memory writes.
    > > > > > > Anything that can do writes must be protected by an IOMMU
    > > > > > > and/or have a secure kernel driver, not a UIO stub.
    > > > > > >
    > > > > > > MSI is done by memory writes so if userspace
    > > > > > > controls the device it can trick it to write
    > > > > > > anywhere in memory.
    > > > > > >
    > > > > > Just out of curiosity: Since MSI support is mandatory for all PCIE devices,
    > > > > > isn't that possible anyway, even if MSI is not enabled by the kernel ?
    > > > > > All one would need to do is to enable MSI from user space; after all,
    > > > > > the chip configuration space is writable.
    > > > > >
    > > > > > Thanks,
    > > > > > Guenter
    > > > >
    > > > > If a device has capability to do writes, sure. So don't do this then :)
    > > > >
    > > > Not an option. I need to use MSI.
    > > >
    > > > Not that it matters anymore - turns out it was better writing a specific driver
    > > > for my devices anyway; I needed to be able to disable chip interrupts before
    > > > unloading the driver. But why is it then a reason to NACK this patch ?
    > >
    > > There seem to be two cases - either you can't access the device -
    > > and the uio driver is not useful - or you can, and it's not safe.
    > > In both cases the patch does not seem to bring about anything
    > > except user confusion ...
    > >
    > Sounds like claiming that supporting MSI would cause some kind of confusion.
    > Not sure if I can follow that logic.
    >
    > Actually, it simplifies the user space code a lot. Since MSI interrupts are edge
    > triggered and queued, it is not necessary to disable the interrupts, and all
    > user space has to do is to remove the interrupt reason. Works quite nicely for
    > our devices.
    >
    > As I said, I don't really care too much anymore if this patch is rejected, but
    > the reasons for the rejection are kind of weak.
    >
    > > > Besides, doesn't one have to be root anyway to perform such activities,
    > > > which could then be more easily accomplished by writing into /dev/mem ?
    > > >
    > > > Thanks,
    > > > Guenter
    > >
    > > root might not be able to write into /dev/mem.
    > >
    > I don't really want to try, but at least it is marked rw for root.
    >
    > Guenter

    Yes but mechanisms such as selinux can still block it.

    --
    MST


    \
     
     \ /
      Last update: 2013-07-07 10:41    [W:2.504 / U:0.104 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site