On Oct 6, 2015 12:55 AM, "Michael S. Tsirkin" <mst at redhat.com> wrote: > > On Thu, Oct 01, 2015 at 11:33:06AM +0300, Michael S. Tsirkin wrote: > > Just forwarding events is not enough to make a valid driver. > > What is missing is a way to access the device in a safe way. > > Thinking about it some more, maybe some devices don't do DMA, and merely > signal events with MSI/MSI-X. > > The fact you mention igb_uio in the cover letter seems to hint that this > isn't the case, and that the real intent is to abuse it for DMA-capable > devices, but still ... > > If we assume such a simple device, we need to block userspace from > tweaking at least the MSI control and the MSI-X table. > And changing BARs might make someone else corrupt the MSI-X > table, so we need to block it from changing BARs, too. > > Things like device reset will clear the table. I guess this means we > need to track access to reset, too, make sure we restore the > table to a sane config. > > PM capability can be used to reset things tooI think. Better be > careful about that. > > And a bunch of devices could be doing weird things that need > to be special-cased. > > All of this is what VFIO is already dealing with. > > Maybe extending VFIO for this usecase, or finding another way to share > code might be a better idea than duplicating the code within uio?
How about instead of trying to invent the wheel just go and attack the problem directly just like i've proposed already a few times in the last days: instead of limiting the UIO limit the users that are allowed to use UIO to privileged users only (e.g. root). This would solve all clearly unresolvable issues u are raising here all together, wouldn't it? > > -- > MST
