From: David Marchand <david.marchand@redhat.com>
To: Patrick Robb <probb@iol.unh.edu>
Cc: "Dharmik Jayesh Thakkar" <DharmikJayesh.Thakkar@arm.com>,
"Ruifeng Wang" <Ruifeng.Wang@arm.com>,
"Juraj Linkeš" <juraj.linkes@pantheon.tech>,
"Honnappa Nagarahalli" <Honnappa.Nagarahalli@arm.com>,
"ci@dpdk.org" <ci@dpdk.org>, nd <nd@arm.com>
Subject: Re: Intel QAT 8970 accel card on ARM Ampere Server
Date: Wed, 11 Oct 2023 13:51:32 +0200 [thread overview]
Message-ID: <CAJFAV8wj2tzpbfddmBHoO2t7fPebOfL8nFqJa_rQneDhXX7zbw@mail.gmail.com> (raw)
In-Reply-To: <CAJvnSUA2XONXmcAcyBo73rWswkmMDqQsGes+it0u=j8Tiwgidg@mail.gmail.com>
On Tue, Oct 10, 2023 at 6:00 PM Patrick Robb <probb@iol.unh.edu> wrote:
> On Mon, Oct 9, 2023 at 11:56 PM Dharmik Jayesh Thakkar <DharmikJayesh.Thakkar@arm.com> wrote:
>>
>> Hi Patrick,
>>
>>
>>
>> Can you provide the grub settings? Is iommu.passthrough=1 included?
>
>
> Sure. I'm not sure if you just wanted the kernel cmdline options or the whole grub config, but I assume you just meant kernel cmdline. Let me know if you meant more.
>
> GRUB_CMDLINE_LINUX_DEFAULT="default_hugepagesz=1G hugepagesz=1G hugepages=32 iommu=pt intel_iommu=on isolcpus=39-79 nohz_full=39-79 rcu_nocbs=39-79 processor.max_cstate=1 intel_pstate=disable console=ttyS0,115200 console=tty0"
>
> But, iommu.passthrough=1 is not included, so I can add that if we need to. Do you know that this won't have any bad implications for the (intel, nvidia, broadcom) NICs which we test on this server?
>
>>
>>
>>
>> Also, is qat_c62xvf loaded as well?
>
> qat_c62xvf is built in to the kernel also.
>
>>
>>
>>
>>
>>
>> Finally, a few guidelines on the vfio driver:
>>
>> At times, we need to configure the vfio driver.
>>
>> On kernel vers. 5.9+ we need to load the vfio-pci driver with the additional parameter disable_denylist=1
>>
>> Unload the vfio-pci driver if it is already loaded so that we can reload it with the correct parameters :
>> sudo modprobe -r vfio_iommu_type1; sudo modprobe -r vfio_pci; sudo modprobe -r vfio_virqfd; sudo modprobe -r vfio
>>
>> If you can't unload the vfio driver because it's been built into the kernel, you'll have to find another way to change VFIO parameters, or to rebuild your kernel with VFIO_PCI set as a module. Failing to do that, you might encounter issues later on when you try to bind the VFs to VFIO.
>>
>> Load the vfio-pci driver and bind it to QAT VFs device ids:
>> sudo modprobe vfio-pci disable_denylist=1 enable_sriov=1 vfio-pci.ids=8086:37c9
>>
>> Enable no-iommu-mode:
>> echo "1" | sudo tee /sys/module/vfio/parameters/enable_unsafe_noiommu_mode
>>
>> /sys/module/vfio/parameter is missing ?
>>
>> If /sys/module/vfio/parameters does not exist, you might be missing the kernel module VFIO_NOIOMMU
>>
>>
>>
>> Automatically set VFIO params on boot
>>
>> It's possible to set these parameters automatically on boot by creating a /etc/modprobe.d/vfio-pci.conf file with the parameters :
>> cat /etc/modprobe.d/vfio-pci.conf
>> options vfio enable_unsafe_noiommu_mode=1
>> options vfio-pci disable_denylist=1 enable_sriov=1 vfio-pci.ids=8086:37c9
>>
>>
>>
>> We haven’t encountered this issue in the past, so just making sure the configuration is correct. I don’t think having the driver static/loadable should make a difference, I will try with building statically on my setup.
>>
>>
>>
>> Thank you!
>>
>>
> Okay, this should be fine. Like I said, we are also running tests on NICs on this server. So, in our Jenkinsfiles scripts for running the testing, I will add a preliminary step only for QAT tests which runs:
> sudo modprobe -r vfio_iommu_type1; sudo modprobe -r vfio_pci; sudo modprobe -r vfio_virqfd; sudo modprobe -r vfio
- I thought vfio_iommu_type1 was a x86 thing. So it would work for x86
(Intel/AMD) systems, but fail on other arches.. ?
If you tested this on ARM, it is probably ok as is.
> sudo modprobe vfio-pci disable_denylist=1 enable_sriov=1 vfio-pci.ids=8086:37c9
- Speaking to myself, too bad the disable_denylist param value is only
read once, when loading the vfio-pci kernel module...
So ok, I get why you need to reload the whole chain of kmods.
However, I don't think the vfio-pci.ids syntax works for passing parameters.
And in any case, why do you need to set this initial list?
Binding devices (using either driverctl or dpdk-devbind.py) to
vfio-pci should be done the "usual" way, or is there some special case
again for QAT?
- Besides, from what I understood so far, there are two parts specific
to this QAT test:
* enabling SRIOV so that creating VF is possible with a PF bound to
vfio-pci (option enable_sriov=1),
* for a list of PCI QAT cards, forcing the disable_denylist is needed
(option disable_denylist=1),
For the latter point, at this step of the test setup, do you know
which QAT devices will be used?
If so, the commandline params could be constructed to enable
disable_denylist only for known-broken QAT devices (the list is
available in the kernel commit Dharmik provided earlier).
> echo "1" | sudo tee /sys/module/vfio/parameters/enable_unsafe_noiommu_mode
> (then run QAT tests)
>
> And if running on NICs, have a preliminary step which runs
> sudo modprobe -r vfio_iommu_type1; sudo modprobe -r vfio_pci; sudo modprobe -r vfio_virqfd; sudo modprobe -r vfio
> sudo modprobe vfio
Given that vfio_iommu_type1 is ok on other arch, this lgtm.
--
David Marchand
prev parent reply other threads:[~2023-10-11 11:51 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-31 17:13 Patrick Robb
2023-08-04 9:48 ` Ruifeng Wang
2023-08-08 7:07 ` Juraj Linkeš
2023-08-08 7:11 ` Ruifeng Wang
2023-08-11 21:18 ` Patrick Robb
2023-08-21 8:45 ` Juraj Linkeš
2023-08-30 0:05 ` Patrick Robb
2023-09-01 21:30 ` Patrick Robb
2023-09-11 8:13 ` Juraj Linkeš
2023-09-20 18:28 ` Patrick Robb
2023-09-25 15:19 ` Ruifeng Wang
2023-10-09 16:34 ` Patrick Robb
2023-10-10 2:28 ` Patrick Robb
2023-10-10 3:55 ` Dharmik Jayesh Thakkar
2023-10-10 7:25 ` David Marchand
2023-10-10 15:03 ` Dharmik Jayesh Thakkar
2023-10-10 15:12 ` David Marchand
2023-10-10 15:59 ` Patrick Robb
2023-10-10 21:50 ` Dharmik Jayesh Thakkar
2023-10-11 8:14 ` Juraj Linkeš
2023-10-11 20:13 ` Patrick Robb
2023-11-02 22:00 ` Patrick Robb
2023-11-14 7:34 ` Ruifeng Wang
2023-11-14 14:36 ` Patrick Robb
2024-02-27 6:58 ` Patrick Robb
2024-02-27 13:50 ` Honnappa Nagarahalli
2024-02-28 20:00 ` Patrick Robb
2024-02-28 20:40 ` Honnappa Nagarahalli
2024-03-07 5:27 ` Patrick Robb
2024-03-07 7:56 ` David Marchand
2023-10-11 11:51 ` David Marchand [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJFAV8wj2tzpbfddmBHoO2t7fPebOfL8nFqJa_rQneDhXX7zbw@mail.gmail.com \
--to=david.marchand@redhat.com \
--cc=DharmikJayesh.Thakkar@arm.com \
--cc=Honnappa.Nagarahalli@arm.com \
--cc=Ruifeng.Wang@arm.com \
--cc=ci@dpdk.org \
--cc=juraj.linkes@pantheon.tech \
--cc=nd@arm.com \
--cc=probb@iol.unh.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).