On Mon, Jan 18, 2016 at 12:15:40PM +0530, Santosh Shukla wrote:
> I am testing for virtio 1.0 and 0.95 for arm including your patch,
> soon we;ll post the patch series that is rebased on / dependent on
> below patchset:
> - virtio 1.0
> - vfio-noiommu
> - KDRV check by huawei
>
> IMO, we should start merging the dependent patches as because I'll
Yep, agreed. That's why I was keep pushing Huawei for ACK and
validation team for testing, although I have tested that. :)
> have to rebase, then do regression across the platform at least for
> x86/arm64 and it's quite a work now.
>
> Beside that I have few question specific to vfio in virtio pmd driver;
> - vfio don't need resource_init functionality as it uses struct
> rte_pci_dev but it need parsing so to make sure
> 1. user has setted no_iommu mode
> 2. virtio pci device attached to vfio-no-iommu driver or not.
>
> So for 1) I am thinking to add RTE_KDRV_VFIO_NOIOMMU mode and a helper
> function like pci_vfio_is_iommu(), such that pc_xxx_scan() function
> updates dev->kdrv with RTE_KDRV_VFIO_NOIOMMU at driver probe time.
That sounds better to me. And that's also what I want to comment on
your another patch [09/14], that we should try to avoid getting UIO/VFIO
stuff inside virtio pmd driver, unless it's a must. (yes, I know
UIO is already an example here, but I don't like it, and badly, I don't
have the time to check if I can remove it.)
>
> case 2) would check for _noiommu mode and then would verify that
> driver is attached or not?
Sorry, very limited VFIO and noiommu knowledge, and I can't answer, so
far.
--yliu
>
> above two case applicable to both virtio spec 1.0 and 0.95. I have
> done changes for those two case for v5 patch series,l any comment
> welcome before I push patch for review.
>
> Thanks.
