[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1444167707.4059.88.camel@redhat.com>
Date: Tue, 06 Oct 2015 15:41:47 -0600
From: Alex Williamson <alex.williamson@...hat.com>
To: Stephen Hemminger <stephen@...workplumber.org>
Cc: Avi Kivity <avi@...lladb.com>,
"Michael S. Tsirkin" <mst@...hat.com>,
Vlad Zolotarov <vladz@...udius-systems.com>,
Greg KH <gregkh@...uxfoundation.org>,
linux-kernel@...r.kernel.org, hjk@...sjkoch.de, corbet@....net,
bruce.richardson@...el.com, avi@...udius-systems.com,
gleb@...udius-systems.com, alexander.duyck@...il.com
Subject: Re: [PATCH v3 2/3] uio_pci_generic: add MSI/MSI-X support
On Tue, 2015-10-06 at 22:32 +0100, Stephen Hemminger wrote:
> On Tue, 06 Oct 2015 12:51:20 -0600
> Alex Williamson <alex.williamson@...hat.com> wrote:
>
> > Of course this is entirely unsafe and this no-iommu driver should taint
> > the kernel, but it at least standardizes on one userspace API and you're
> > already doing completely unsafe things with uio. vfio should be
> > enlightened at least to the point that it allows only privileged users
> > access to devices under such a (lack of) iommu
>
> I agree with the design, but not with the taint argument.
> (Unless you want to taint any and all use of UIO drivers which can
> already do this).
Yes, actually, if the bus master bit gets enabled all bets are off. I
don't see how that leaves a supportable kernel, so we might as well
taint it. Isn't this exactly why we taint for proprietary drivers, we
have no idea what it has mucked with in kernel space. This just moves
the proprietary driver out to userspace without an iommu to protect the
host. Thanks,
Alex
--
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