[dpdk-dev] [Question] How pmd virtio works without UIO?

[Xie, Huawei]

On 12/23/2015 10:57 AM, Yuanhan Liu wrote:
> On Wed, Dec 23, 2015 at 10:41:57AM +0800, Peter Xu wrote:
>> On Wed, Dec 23, 2015 at 10:01:35AM +0800, Yuanhan Liu wrote:
>>> On Tue, Dec 22, 2015 at 05:56:41PM +0800, Peter Xu wrote:
>>>> On Tue, Dec 22, 2015 at 04:32:46PM +0800, Yuanhan Liu wrote:
>>>>> Actually, you are right. I mentioned in the last email that this is
>>>>> for configuration part. To answer your question in this email, you
>>>>> will not be able to go that further (say initiating virtio pmd) if
>>>>> you don't unbind the origin virtio-net driver, and bind it to igb_uio
>>>>> (or something similar).
>>>>>
>>>>> The start point is from rte_eal_pci_scan, where the sub-function
>>>>> pci_san_one just initates a DPDK bond driver.
>>>> I am not sure whether I do understand your meaning correctly
>>>> (regarding "you willl not be able to go that furture"): The problem
>>>> is that, we _can_ run testpmd without unbinding the ports and bind
>>>> to UIO or something. What we need to do is boot the guest, reserve
>>>> huge pages, and run testpmd (keeping its kernel driver as
>>>> "virtio-pci"). In pci_scan_one():
>>>>
>>>> 	if (!ret) {
>>>> 		if (!strcmp(driver, "vfio-pci"))
>>>> 			dev->kdrv = RTE_KDRV_VFIO;
>>>> 		else if (!strcmp(driver, "igb_uio"))
>>>> 			dev->kdrv = RTE_KDRV_IGB_UIO;
>>>> 		else if (!strcmp(driver, "uio_pci_generic"))
>>>> 			dev->kdrv = RTE_KDRV_UIO_GENERIC;
>>>> 		else
>>>> 			dev->kdrv = RTE_KDRV_UNKNOWN;
>>>> 	} else
>>>> 		dev->kdrv = RTE_KDRV_UNKNOWN;
>>>>
>>>> I think it should be going to RTE_KDRV_UNKNOWN
>>>> (driver=="virtio-pci") here.
>>> Sorry, I simply overlook that. I was thinking it will quit here for
>>> the RTE_KDRV_UNKNOWN case.
>>>
>>>> I tried to run IO and it could work,
>>>> but I am not sure whether it is safe, and how.
>>> I also did a quick test then, however, with the virtio 1.0 patchset
>>> I sent before, which sets the RTE_PCI_DRV_NEED_MAPPING, resulting to
>>> pci_map_device() failure and virtio pmd is not initiated at all.
>> Then, will the patch work with ioport way to access virtio devices?
> Yes.
>
>>>> Also, I am not sure whether I need to (at least) unbind the
>>>> virtio-pci driver, so that there should have no kernel driver
>>>> running for the virtio device before DPDK using it.
>>> Why not? That's what the DPDK document asked to do
>>> (http://dpdk.org/doc/guides/linux_gsg/build_dpdk.html):
>>>
>>>     3.6. Binding and Unbinding Network Ports to/from the Kernel Modules
>>>     
>>>     As of release 1.4, DPDK applications no longer automatically unbind
>>>     all supported network ports from the kernel driver in use. Instead,
>>>     all ports that are to be used by an DPDK application must be bound
>>>     to the uio_pci_generic, igb_uio or vfio-pci module before the
>>>     application is run. Any network ports under Linux* control will be
>>>     ignored by the DPDK poll-mode drivers and cannot be used by the
>>>     application.
>> This seems obsolete? since it's not covering ioport.
> I don't think so. Above is for how to run DPDK applications. ioport
> is just a (optional) way to access PCI resource in a specific PMD.
>
> And, above speicification avoids your concerns, that two drivers try
> to manipulate same device concurrently, doesn't it?
>
> And, it is saying "any network ports under Linux* control will be
> ignored by the DPDK poll-mode drivers and cannot be used by the
> application", so that the case you were saying that virtio pmd
> continues to work without the bind looks like a bug to me.
>
> Can anyone confirm that?

That document isn't accurate. virtio doesn't require binding to UIO
driver if it uses PORT IO. The PORT IO commit said it is because UIO
isn't secure, but avoid using uio doesn't bring more security as virtio
PMD still could ask device to DMA into any memory.
The thing we at least we might do is fail in virtio_resource_init if
kernel driver is still manipulating this device. This saves the effort
users use blacklist option and avoids the driver conflict.

>
> 	--yliu
>