Re: [dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

[Avi Kivity <avi@scylladb.com>]

On 10/01/2015 12:15 PM, Michael S. Tsirkin wrote:
> On Thu, Oct 01, 2015 at 11:52:26AM +0300, Avi Kivity wrote:
>> I still don't understand your objection to the patch:
>>
>>
>>      MSI messages are memory writes so any generic device capable
>>      of MSI is capable of corrupting kernel memory.
>>      This means that a bug in userspace will lead to kernel memory corruption
>>      and crashes.  This is something distributions can't support.
>>
>>
>> If a distribution feels it can't support this configuration, it can disable the
>> uio_pci_generic driver, or refuse to support tainted kernels.  If it feels it
>> can (and many distributions are starting to support dpdk), then you're just
>> denying it the ability to serve its users.
> I don't, and can't deny users anything.  I merely think upstream should
> avoid putting this driver in-tree.  By doing this, driver writers will
> be pushed to develop solutions that can't crash kernel.
>
> I pointed out one way to build it, there are sure to be more.

And I pointed out that your solution is unworkable.  It's easy to claim 
that a solution is around the corner, only no one was looking for it, 
but the reality is that kernel bypass has been a solution for years for 
high performance users, that it cannot be made safe without an iommu, 
and that iommus are not available everywhere; and even when they are 
some users prefer to avoid the performance penalty.

> As far as I could see, without this kind of motivation, people do not
> even want to try.

You are mistaken.  The problem is a lot harder than you think.

People didn't go and write userspace drivers because they were lazy.  
They wrote them because there was no other way.