quick update:
I could bind the QAT VFs to vfio-pci after using the module loading options Dharmik mentioned.
First I tested SYM QAT pmd from dpdk test on the VF and got:
+ Tests Total : 751
+ Tests Skipped : 257
+ Tests Executed : 659
+ Tests Unsupported: 0
+ Tests Passed : 494
+ Tests Failed : 0
+ ------------------------------------------------------- +
Test OK
I can try the crypto performance DTS testsuite next. Let me know if you have any thoughts.
+ Paul, Wathsala
> On Feb 27, 2024, at 12:58 AM, Patrick Robb <probb@iol.unh.edu> wrote:
>
>
>
> On Tue, Nov 14, 2023 at 2:35 AM Ruifeng Wang <Ruifeng.Wang@arm.com> wrote:
> Hi Patrick,
> It seems kernel v5.15 has a defect on this. A similar issue was fixed by commit:
> 40da865381ad ("crypto: qat - remove unneeded packed attribute")
> Could you patch the kernel and try again?
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=40da865381ad061ab75a7a9da469ed4e623bdfeb
> Thanks,
> Ruifeng
>
> Hi Ruifeng,
>
> Sorry for the delay on this - there has been a work item backlog at the Community Lab we've been working through.
>
> I did rebuild the patch today with these changes from the commit (or similar, as the commit above was for the qat_common file in a different state, but I tried to remain as true to the commit as possible).
>
> And that does seem to have resolved the seg fault problem! Thank you so much for picking this commit out of obscurity and sending it our way!
>
> root@arm-ampere-dut:~# echo 16 > /sys/bus/pci/drivers/c6xx/0000:03:00.0/sriov_numvfs
> root@arm-ampere-dut:~# cat /sys/bus/pci/drivers/c6xx/0000:03:00.0/sriov_numvfs
> 16
>
> Wunderbar!
>
> The only other thing I changed (just because I was floating the idea with Dharmik before) was in the kernel .config I changed the qat_c62x and qat_c62xvf modules from statically built in (=y) to loadable (=m). Of course, this should not matter, and I presume the change in behavior relates to those brought in from the commit above. I just want to present fully all changes made so there is a complete picture.
>
> I will continue on this tomorrow according to where this conversation left off, and try to move this quickly. If indeed there are no more blockers I think we are very close. As a reminder, when standing up a new testing plan, we want to make sure at least 1 rep from each vendor has SSH access and can remotely login to help with system tuning, troubleshooting, etc. for the testbed and test plan. Who would be the best person from ARM for this at this time, given the context on QAT testing? Ruifeng? Dharmik? Someone else?
>
> Thanks, I'll keep yall apprised of the situation.
>