Re: [dpdk-dev] [PATCH] VFIO: Avoid to enable vfio while the module not loaded

["Qiu, Michael" <michael.qiu@intel.com>]

On 12/4/2014 9:12 PM, Burakov, Anatoly wrote:
> Hi Michael
>
>> When vfio module is not loaded when kernel support vfio feature, the
>> routine still try to open the container to get file description.
>>
>> This action is not safe, and of cause got error messages:
>>
>> EAL: Detected 40 lcore(s)
>> EAL:   unsupported IOMMU type!
>> EAL: VFIO support could not be initialized
>> EAL: Setting up memory...
>>
>> This may make user confuse, this patch make it reasonable and much more
>> soomth to user.
>  Not sure I agree with the premise of this patch.
>
> First of all, if VFIO driver is not enabled, the container file would not be present and you would get a different error (namely, "cannot open VFIO container", in pci_vfio_get_container_fd()). If you have a container file,  that means VFIO driver is loaded, so I'm not sure why you get the "unsupported IOMMU type" error. I suppose it could happen when vfio is loaded but vfio_iommu_type1 isn't?

But indeed, when try to unload both vfio and vfio_iommu_type1,
/dev/vfio/vfio still there, I'm also surprise.

My ENV is fedora20, kernel version 3.6.7-200 X86_64.

Believe or not, you can have a try, it seems a kernel issue.

When you unload both two modules, then open /dev/vfio/vfio, you will
find it can be opened with no errors(but this time both two modules
loaded automatically, strange enough)

Also you can use ioctl to get API Version. But when you try to get the
iommu type, it will return a "0" not expect value of  '1'.

Then you can shutdown DPDK, reopen like test-pmd, all works fine :)

I will take a deep look at in the kernel side, to find out why this happens.

Thanks,
Michael
> And even then, this error is harmless and doesn't do anything, so I'm not sure what this patch is supposed to fix. The error messages tells the user exactly what happens.
>  
> Thanks,
> Anatoly 
>