From: Sathyanarayanan Kuppuswamy <sathyanarayanan.kuppuswamy@linux.intel.com>
To: Ganapatrao Kulkarni <gankulkarni@os.amperecomputing.com>,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
joro@8bytes.org, bhelgaas@google.com, robin.murphy@arm.com,
will@kernel.org
Cc: jean-philippe@linaro.org, darren@os.amperecomputing.com,
scott@os.amperecomputing.com
Subject: Re: [PATCH 1/2] PCI/ATS: Add a helper function to configure ATS STU of a PF.
Date: Mon, 27 Feb 2023 19:08:17 -0800 [thread overview]
Message-ID: <47a88e5f-ee56-9c4b-e134-e018cd6dc49e@linux.intel.com> (raw)
In-Reply-To: <e80adfa5-b51a-a1ae-f582-58eaa4a5be68@os.amperecomputing.com>
On 2/27/23 6:53 PM, Ganapatrao Kulkarni wrote:
>
>
> On 28-02-2023 12:59 am, Sathyanarayanan Kuppuswamy wrote:
>> Hi,
>>
>> On 2/27/23 5:21 AM, Ganapatrao Kulkarni wrote:
>>> As per PCI specification (PCI Express Base Specification Revision
>>> 6.0, Section 10.5) both PF and VFs of a PCI EP are permitted to be enabled
>>> independently for ATS capability, however the STU(Smallest Translation
>>> Unit) is shared between PF and VFs. For VFs, it is hardwired to Zero and
>>> the associated PF's value applies to VFs.
>>>
>>> In the current code, the STU is being configured while enabling the PF ATS.
>>> Hence, it is not able to enable ATS for VFs, if it is not enabled on the
>>> associated PF already.>
>>> Adding a function pci_ats_stu_configure(), which can be called to
>>> configure the STU during PF enumeration.
>>> Latter enumerations of VFs can successfully enable ATS independently.
>>
>> Why not enable ATS in PF before enabling it in VF? Just updating STU of
>> PF and not enabling it seem odd.
>
> More details are in PATCH 0/2 and 2/2.
>
> Also, This was discussed at
> https://lore.kernel.org/linux-arm-kernel/20230221154624.GA3701506@bhelgaas/T/
>
I agree with Bjorn's comments. It is incorrect to directly configure PF
registers from VF enable function. It is a buggy fix.
My question is, why not ensure PF ATS is configured and enabled before enabling
ATS for VF. Anyway, PF device will be enumerated before VF, right?
>>
>>>
>>> Signed-off-by: Ganapatrao Kulkarni <gankulkarni@os.amperecomputing.com>
>>> ---
>>> drivers/pci/ats.c | 32 ++++++++++++++++++++++++++++++--
>>> include/linux/pci-ats.h | 1 +
>>> 2 files changed, 31 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/pci/ats.c b/drivers/pci/ats.c
>>> index f9cc2e10b676..70e1982efdb4 100644
>>> --- a/drivers/pci/ats.c
>>> +++ b/drivers/pci/ats.c
>>> @@ -46,6 +46,34 @@ bool pci_ats_supported(struct pci_dev *dev)
>>> }
>>> EXPORT_SYMBOL_GPL(pci_ats_supported);
>>> +/**
>>> + * pci_ats_stu_configure - Configure STU of a PF.
>>> + * @dev: the PCI device
>>> + * @ps: the IOMMU page shift
>>> + *
>>> + * Returns 0 on success, or negative on failure.
>>> + */
>>> +int pci_ats_stu_configure(struct pci_dev *dev, int ps)
>>> +{
>>> + u16 ctrl;
>>> +
>>> + if (dev->ats_enabled || dev->is_virtfn)
>>> + return 0;
>>> +
>>> + if (!pci_ats_supported(dev))
>>> + return -EINVAL;
>>> +
>>> + if (ps < PCI_ATS_MIN_STU)
>>> + return -EINVAL;
>>> +
>>> + dev->ats_stu = ps;
>>> + ctrl = PCI_ATS_CTRL_STU(dev->ats_stu - PCI_ATS_MIN_STU);
>>> + pci_write_config_word(dev, dev->ats_cap + PCI_ATS_CTRL, ctrl);
>>
>> If you just want to update the STU, don't overwrite other fields.
>
> Can be read modify write, but felt not necessary, since all other fields are at default value zero.
It may not always be true. If there is a case where AMAD and AMAE attribute values are
configured independently, then your change can overwrite it.
IMO, since your intention is to update STU, I recommend just updating it.
>
>>
>>> +
>>> + return 0;
>>> +}
>>> +EXPORT_SYMBOL_GPL(pci_ats_stu_configure);
>>> +
>>> /**
>>> * pci_enable_ats - enable the ATS capability
>>> * @dev: the PCI device
>>> @@ -68,8 +96,8 @@ int pci_enable_ats(struct pci_dev *dev, int ps)
>>> return -EINVAL;
>>> /*
>>> - * Note that enabling ATS on a VF fails unless it's already enabled
>>> - * with the same STU on the PF.
>>> + * Note that enabling ATS on a VF fails unless it's already
>>> + * configured with the same STU on the PF.
>>> */
>>> ctrl = PCI_ATS_CTRL_ENABLE;
>>> if (dev->is_virtfn) {
>>> diff --git a/include/linux/pci-ats.h b/include/linux/pci-ats.h
>>> index df54cd5b15db..9b40eb555124 100644
>>> --- a/include/linux/pci-ats.h
>>> +++ b/include/linux/pci-ats.h
>>> @@ -8,6 +8,7 @@
>>> /* Address Translation Service */
>>> bool pci_ats_supported(struct pci_dev *dev);
>>> int pci_enable_ats(struct pci_dev *dev, int ps);
>>> +int pci_ats_stu_configure(struct pci_dev *dev, int ps);
>>
>> What about dummy declaration for !CONFIG_PCI_ATS case?
>
> Thanks, I overlooked else case.
>>
>>> void pci_disable_ats(struct pci_dev *dev);
>>> int pci_ats_queue_depth(struct pci_dev *dev);
>>> int pci_ats_page_aligned(struct pci_dev *dev);
>>
>
>
> Thanks,
> Ganapat
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
WARNING: multiple messages have this Message-ID (diff)
From: Sathyanarayanan Kuppuswamy <sathyanarayanan.kuppuswamy@linux.intel.com>
To: Ganapatrao Kulkarni <gankulkarni@os.amperecomputing.com>,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
joro@8bytes.org, bhelgaas@google.com, robin.murphy@arm.com,
will@kernel.org
Cc: jean-philippe@linaro.org, darren@os.amperecomputing.com,
scott@os.amperecomputing.com
Subject: Re: [PATCH 1/2] PCI/ATS: Add a helper function to configure ATS STU of a PF.
Date: Mon, 27 Feb 2023 19:08:17 -0800 [thread overview]
Message-ID: <47a88e5f-ee56-9c4b-e134-e018cd6dc49e@linux.intel.com> (raw)
In-Reply-To: <e80adfa5-b51a-a1ae-f582-58eaa4a5be68@os.amperecomputing.com>
On 2/27/23 6:53 PM, Ganapatrao Kulkarni wrote:
>
>
> On 28-02-2023 12:59 am, Sathyanarayanan Kuppuswamy wrote:
>> Hi,
>>
>> On 2/27/23 5:21 AM, Ganapatrao Kulkarni wrote:
>>> As per PCI specification (PCI Express Base Specification Revision
>>> 6.0, Section 10.5) both PF and VFs of a PCI EP are permitted to be enabled
>>> independently for ATS capability, however the STU(Smallest Translation
>>> Unit) is shared between PF and VFs. For VFs, it is hardwired to Zero and
>>> the associated PF's value applies to VFs.
>>>
>>> In the current code, the STU is being configured while enabling the PF ATS.
>>> Hence, it is not able to enable ATS for VFs, if it is not enabled on the
>>> associated PF already.>
>>> Adding a function pci_ats_stu_configure(), which can be called to
>>> configure the STU during PF enumeration.
>>> Latter enumerations of VFs can successfully enable ATS independently.
>>
>> Why not enable ATS in PF before enabling it in VF? Just updating STU of
>> PF and not enabling it seem odd.
>
> More details are in PATCH 0/2 and 2/2.
>
> Also, This was discussed at
> https://lore.kernel.org/linux-arm-kernel/20230221154624.GA3701506@bhelgaas/T/
>
I agree with Bjorn's comments. It is incorrect to directly configure PF
registers from VF enable function. It is a buggy fix.
My question is, why not ensure PF ATS is configured and enabled before enabling
ATS for VF. Anyway, PF device will be enumerated before VF, right?
>>
>>>
>>> Signed-off-by: Ganapatrao Kulkarni <gankulkarni@os.amperecomputing.com>
>>> ---
>>> drivers/pci/ats.c | 32 ++++++++++++++++++++++++++++++--
>>> include/linux/pci-ats.h | 1 +
>>> 2 files changed, 31 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/pci/ats.c b/drivers/pci/ats.c
>>> index f9cc2e10b676..70e1982efdb4 100644
>>> --- a/drivers/pci/ats.c
>>> +++ b/drivers/pci/ats.c
>>> @@ -46,6 +46,34 @@ bool pci_ats_supported(struct pci_dev *dev)
>>> }
>>> EXPORT_SYMBOL_GPL(pci_ats_supported);
>>> +/**
>>> + * pci_ats_stu_configure - Configure STU of a PF.
>>> + * @dev: the PCI device
>>> + * @ps: the IOMMU page shift
>>> + *
>>> + * Returns 0 on success, or negative on failure.
>>> + */
>>> +int pci_ats_stu_configure(struct pci_dev *dev, int ps)
>>> +{
>>> + u16 ctrl;
>>> +
>>> + if (dev->ats_enabled || dev->is_virtfn)
>>> + return 0;
>>> +
>>> + if (!pci_ats_supported(dev))
>>> + return -EINVAL;
>>> +
>>> + if (ps < PCI_ATS_MIN_STU)
>>> + return -EINVAL;
>>> +
>>> + dev->ats_stu = ps;
>>> + ctrl = PCI_ATS_CTRL_STU(dev->ats_stu - PCI_ATS_MIN_STU);
>>> + pci_write_config_word(dev, dev->ats_cap + PCI_ATS_CTRL, ctrl);
>>
>> If you just want to update the STU, don't overwrite other fields.
>
> Can be read modify write, but felt not necessary, since all other fields are at default value zero.
It may not always be true. If there is a case where AMAD and AMAE attribute values are
configured independently, then your change can overwrite it.
IMO, since your intention is to update STU, I recommend just updating it.
>
>>
>>> +
>>> + return 0;
>>> +}
>>> +EXPORT_SYMBOL_GPL(pci_ats_stu_configure);
>>> +
>>> /**
>>> * pci_enable_ats - enable the ATS capability
>>> * @dev: the PCI device
>>> @@ -68,8 +96,8 @@ int pci_enable_ats(struct pci_dev *dev, int ps)
>>> return -EINVAL;
>>> /*
>>> - * Note that enabling ATS on a VF fails unless it's already enabled
>>> - * with the same STU on the PF.
>>> + * Note that enabling ATS on a VF fails unless it's already
>>> + * configured with the same STU on the PF.
>>> */
>>> ctrl = PCI_ATS_CTRL_ENABLE;
>>> if (dev->is_virtfn) {
>>> diff --git a/include/linux/pci-ats.h b/include/linux/pci-ats.h
>>> index df54cd5b15db..9b40eb555124 100644
>>> --- a/include/linux/pci-ats.h
>>> +++ b/include/linux/pci-ats.h
>>> @@ -8,6 +8,7 @@
>>> /* Address Translation Service */
>>> bool pci_ats_supported(struct pci_dev *dev);
>>> int pci_enable_ats(struct pci_dev *dev, int ps);
>>> +int pci_ats_stu_configure(struct pci_dev *dev, int ps);
>>
>> What about dummy declaration for !CONFIG_PCI_ATS case?
>
> Thanks, I overlooked else case.
>>
>>> void pci_disable_ats(struct pci_dev *dev);
>>> int pci_ats_queue_depth(struct pci_dev *dev);
>>> int pci_ats_page_aligned(struct pci_dev *dev);
>>
>
>
> Thanks,
> Ganapat
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-02-28 3:08 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-27 13:21 [PATCH 0/2] Add support to enable ATS on VFs independently Ganapatrao Kulkarni
2023-02-27 13:21 ` Ganapatrao Kulkarni
2023-02-27 13:21 ` [PATCH 1/2] PCI/ATS: Add a helper function to configure ATS STU of a PF Ganapatrao Kulkarni
2023-02-27 13:21 ` Ganapatrao Kulkarni
2023-02-27 19:29 ` Sathyanarayanan Kuppuswamy
2023-02-27 19:29 ` Sathyanarayanan Kuppuswamy
2023-02-28 2:53 ` Ganapatrao Kulkarni
2023-02-28 2:53 ` Ganapatrao Kulkarni
2023-02-28 3:08 ` Sathyanarayanan Kuppuswamy [this message]
2023-02-28 3:08 ` Sathyanarayanan Kuppuswamy
2023-02-28 3:25 ` Ganapatrao Kulkarni
2023-02-28 3:25 ` Ganapatrao Kulkarni
2023-02-27 13:21 ` [PATCH 2/2] iommu/arm-smmu-v3: Configure STU of a PF if ATS is not enabled Ganapatrao Kulkarni
2023-02-27 13:21 ` Ganapatrao Kulkarni
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=47a88e5f-ee56-9c4b-e134-e018cd6dc49e@linux.intel.com \
--to=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=bhelgaas@google.com \
--cc=darren@os.amperecomputing.com \
--cc=gankulkarni@os.amperecomputing.com \
--cc=iommu@lists.linux.dev \
--cc=jean-philippe@linaro.org \
--cc=joro@8bytes.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=robin.murphy@arm.com \
--cc=scott@os.amperecomputing.com \
--cc=will@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.