[dpdk-dev] [PATCH v3 0/4] fix the issue that DPDK takes over virtio device blindly

[Xie, Huawei]

On 2/26/2016 4:41 PM, David Marchand wrote:
> On Fri, Feb 26, 2016 at 7:09 AM, Xie, Huawei <huawei.xie at intel.com> wrote:
>> On 2/24/2016 8:45 PM, Thomas Monjalon wrote:
>>>> Huawei Xie (4):
>>>>   eal: make the comment more accurate
>>>>   eal: set kdrv to RTE_KDRV_NONE if kernel driver isn't manipulating the device.
>>>>   virtio: return 1 to tell the kernel we don't take over this device
>>>>   virtio: check if kernel driver is manipulating the virtio device
>>> The virtio PCI code has been refactored.
>>> Please Huawei, would it be possible to rebase on master?
>> OK. Since IO port map is moved to EAL layer, it is not straightforward
>> like before for virtio PMD to distinguish the reason why port map fails.
>> We have two choices. Return 1 to the upper layer to say that we don't
>> take over the device for all the map failures or we check the driver
>> type, return -1 for UIO/VFIO driver error, return 1 for kernel driver,
>> which is a bit overelaborate.
> The important thing is to have eal report "none" driver first (your
> 2nd patch) , then in ioport_map, "none" driver will trigger the x86
> special case (see other discussion [1]).
> For "uio" drivers, code (when fixed for uio_pci_generic) already does
> the right stuff.
> "vfio" is handled.
> Anything else should fail once we have the "none" driver correctly reported.
>

in rte_eal_pci_map_device:
            case RTE_KDRV_NONE:
#if defined(RTE_ARCH_X86)
                ret = pci_ioport_map(dev, bar, p);
#endif
                break;
        }


in vtpci_init:
        if (legacy_virtio_resource_init(dev, hw) < 0) {
                if (dev->kdrv == RTE_KDRV_UNKNOWN) {
                        PMD_INIT_LOG(INFO,
                                "skip kernel managed virtio device.");
                        return 1;
                }
                return -1;
        }


in dev_init
    ret = vt_pci_init
    if (ret)
        return ret
> What did I miss ?
>
>
> [1] http://dpdk.org/ml/archives/dev/2016-February/034035.html
>