From: Xu Yilun <yilun.xu@linux.intel.com>
To: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
Cc: Arto Merilainen <amerilainen@nvidia.com>,
dan.j.williams@intel.com, linux-kernel@vger.kernel.org,
bhelgaas@google.com, aik@amd.com, lukas@wunner.de,
Samuel Ortiz <sameo@rivosinc.com>,
linux-pci@vger.kernel.org, linux-coco@lists.linux.dev
Subject: Re: [PATCH v4 07/10] PCI/IDE: Add IDE establishment helpers
Date: Thu, 25 Sep 2025 18:18:18 +0800 [thread overview]
Message-ID: <aNUW6s9++Ely4v2R@yilunxu-OptiPlex-7050> (raw)
In-Reply-To: <yq5a1pod4obp.fsf@kernel.org>
> This is the change I am adding
>
> drivers/pci/ide.c | 128 ++++++++++++++++++++++-
> drivers/virt/coco/arm-cca-host/arm-cca.c | 13 +++
> include/linux/pci-ide.h | 7 ++
> 3 files changed, 147 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/ide.c b/drivers/pci/ide.c
> index 3f772979eacb..23d1712ba97a 100644
> --- a/drivers/pci/ide.c
> +++ b/drivers/pci/ide.c
> @@ -101,7 +101,7 @@ void pci_ide_init(struct pci_dev *pdev)
> pdev->ide_cap = ide_cap;
> pdev->nr_link_ide = nr_link_ide;
> pdev->nr_sel_ide = nr_streams;
> - pdev->nr_ide_mem = nr_ide_mem;
> + pdev->nr_ide_mem = min(nr_ide_mem, PCI_IDE_AASOC_REG_MAX);
> }
>
> struct stream_index {
> @@ -213,11 +213,13 @@ struct pci_ide *pci_ide_stream_alloc(struct pci_dev *pdev)
> .rid_start = pci_dev_id(rp),
> .rid_end = pci_dev_id(rp),
> .stream_index = no_free_ptr(ep_stream)->stream_index,
> + .nr_mem = 0,
> },
> [PCI_IDE_RP] = {
> .rid_start = pci_dev_id(pdev),
> .rid_end = rid_end,
> .stream_index = no_free_ptr(rp_stream)->stream_index,
> + .nr_mem = 0,
> },
> },
> .host_bridge_stream = no_free_ptr(hb_stream)->stream_index,
> @@ -228,6 +230,109 @@ struct pci_ide *pci_ide_stream_alloc(struct pci_dev *pdev)
> }
> EXPORT_SYMBOL_GPL(pci_ide_stream_alloc);
>
> +static int add_range_merge_overlap(struct range *range, int az, int nr_range,
> + u64 start, u64 end)
> +{
> + int i;
> +
> + if (start >= end)
> + return nr_range;
> +
> + /* get new start/end: */
> + for (i = 0; i < nr_range; i++) {
> +
> + if (!range[i].end)
> + continue;
> +
> + /* Try to add to the end */
> + if (range[i].end + 1 == start) {
> + range[i].end = end;
> + return nr_range;
> + }
> +
> + /* Try to add to the start */
> + if (range[i].start == end + 1) {
> + range[i].start = start;
> + return nr_range;
> + }
> + }
> +
> + /* Need to add it: */
> + return add_range(range, az, nr_range, start, end);
> +}
Can add_range_with_merge() serve your purpose?
> +
> +int pci_ide_add_address_assoc_block(struct pci_dev *pdev,
> + struct pci_ide *ide,
> + u64 start, u64 end)
> +{
> + struct pci_ide_partner *partner;
> +
> + if (!pci_is_pcie(pdev)) {
> + pci_warn_once(pdev, "not a PCIe device\n");
> + return -EINVAL;
> + }
> +
> + switch (pci_pcie_type(pdev)) {
> + case PCI_EXP_TYPE_ENDPOINT:
> +
> + if (pdev != ide->pdev)
> + return -EINVAL;
> + partner = &ide->partner[PCI_IDE_RP];
> + break;
IIUC, you want to program the RP is it? So is it better we input the to
be programmed device (RP), not the target device (EP) with the range.
> + default:
> + pci_warn_once(pdev, "invalid device type\n");
> + return -EINVAL;
> + }
> +
> + if (partner->nr_mem >= pdev->nr_ide_mem)
> + return -ENOMEM;
I don't get why the desired number blocks for RP is related to the
supported number blocks for EP.
Apart from this, I don't see the necessary to input the EP device.
> +
> + partner->nr_mem = add_range_merge_overlap(partner->mem,
> + PCI_IDE_AASOC_REG_MAX, partner->nr_mem,
> + start, end);
> + return 0;
> +}
> +
> +
> +int pci_ide_merge_address_assoc_block(struct pci_dev *pdev,
> + struct pci_ide *ide, u64 start, u64 end)
> +{
> + struct pci_ide_partner *partner;
> +
> + if (!pci_is_pcie(pdev)) {
> + pci_warn_once(pdev, "not a PCIe device\n");
> + return -EINVAL;
> + }
> +
> + switch (pci_pcie_type(pdev)) {
> + case PCI_EXP_TYPE_ENDPOINT:
> +
> + if (pdev != ide->pdev)
> + return -EINVAL;
> + partner = &ide->partner[PCI_IDE_RP];
> + break;
> + default:
> + pci_warn_once(pdev, "invalid device type\n");
> + return -EINVAL;
> + }
> +
> + for (int i = 0; i < PCI_IDE_AASOC_REG_MAX; i++) {
> + struct range *r = &partner->mem[i];
> +
> + if (r->start < start)
> + start = r->start;
> + if (r->end > end)
> + end = r->end;
> + r->start = 0;
> + r->end = 0;
> + }
> + partner->mem[0].start = start;
> + partner->mem[0].end = end;
> + partner->nr_mem = 1;
IIUC, this function will merge previously added ranges, and the newly
input range, into one, which is wield to me as a kAPI.
> +
> + return 0;
> +}
I noticed Arto has a good idea that there needs at most 2 blocks no
matter how the mmio layout is for PF/VF/MFD..., one for 32 bit, one for
64 bit. And the direct connected upstream bridge to the DSM device has
already aggregated the 2 ranges on enumeration. [1] That greatly reduces
the complexity. No need for callers to iterate the devices/resources to
collect the ranges again.
For TDX, the firmware enforces to setup only one addr block for RP, no
matter how many supported blocks the RP actually has. That means TDX
could only support 64 bit IDE ranges. I'd like to require an input
parameter like "max_nr_mem_rp" for this purpose.
Based on the above, I've found the only input from the caller is the
max_nr_mem_rp, how about we just add it in pci_ide_stream_alloc(),
input 0 if you don't need the addr block setup.
[...]
>
> @@ -163,9 +164,21 @@ static int cca_tsm_connect(struct pci_dev *pdev)
> if (rc)
> goto err_stream;
>
> + /*
> + * Try to use the available address assoc register blocks.
> + * If we fail with ENOMEM, create one block covering the entire
> + * address range. (Should work for arm64)
> + */
> + pci_dev_for_each_resource(pdev, res) {
> + rc = pci_ide_add_address_assoc_block(pdev, ide, res->start, res->end);
> + if (rc == -ENOMEM)
> + pci_ide_merge_address_assoc_block(pdev, ide, res->start, res->end);
> + }
You just input the addr of PF0, not VF/MFD... any limitation? If we
switch to get ranges from direct upstream bridge, are you still OK?
Thanks,
Yilun
next prev parent reply other threads:[~2025-09-25 10:30 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-17 18:33 [PATCH v4 00/10] PCI/TSM: Core infrastructure for PCI device security (TDISP) Dan Williams
2025-07-17 18:33 ` [PATCH v4 01/10] coco/tsm: Introduce a core device for TEE Security Managers Dan Williams
2025-07-29 11:28 ` Jonathan Cameron
2025-07-17 18:33 ` [PATCH v4 02/10] PCI/IDE: Enumerate Selective Stream IDE capabilities Dan Williams
2025-07-29 12:03 ` Jonathan Cameron
2025-08-05 20:59 ` dan.j.williams
2025-08-07 20:12 ` Bjorn Helgaas
2025-08-07 22:37 ` dan.j.williams
2025-08-07 22:53 ` Bjorn Helgaas
2025-08-08 2:17 ` dan.j.williams
2025-08-08 15:59 ` Bjorn Helgaas
2025-08-07 22:43 ` Bjorn Helgaas
2025-07-17 18:33 ` [PATCH v4 03/10] PCI: Introduce pci_walk_bus_reverse(), for_each_pci_dev_reverse() Dan Williams
2025-07-29 13:06 ` Jonathan Cameron
2025-08-05 23:52 ` dan.j.williams
2025-08-06 10:54 ` Jonathan Cameron
2025-08-07 20:24 ` Bjorn Helgaas
2025-08-07 23:17 ` dan.j.williams
2025-08-07 23:26 ` Bjorn Helgaas
2025-07-17 18:33 ` [PATCH v4 04/10] PCI/TSM: Authenticate devices via platform TSM Dan Williams
2025-07-29 14:56 ` Jonathan Cameron
2025-08-06 1:35 ` dan.j.williams
2025-08-06 11:10 ` Jonathan Cameron
2025-08-06 23:16 ` dan.j.williams
2025-08-07 10:42 ` Jonathan Cameron
2025-08-07 2:35 ` dan.j.williams
2025-08-05 15:53 ` Xu Yilun
2025-08-06 22:30 ` dan.j.williams
2025-08-07 21:27 ` Bjorn Helgaas
2025-08-08 22:51 ` dan.j.williams
2025-08-13 2:57 ` Alexey Kardashevskiy
2025-08-14 1:40 ` dan.j.williams
2025-08-14 14:52 ` Alexey Kardashevskiy
2025-08-18 21:08 ` dan.j.williams
2025-07-17 18:33 ` [PATCH v4 05/10] samples/devsec: Introduce a PCI device-security bus + endpoint sample Dan Williams
2025-07-29 15:16 ` Jonathan Cameron
2025-08-06 3:20 ` dan.j.williams
2025-08-06 11:16 ` Jonathan Cameron
2025-08-06 18:33 ` dan.j.williams
2025-08-11 13:18 ` Gerd Hoffmann
2025-08-11 20:47 ` dan.j.williams
2025-08-07 21:45 ` Bjorn Helgaas
2025-08-08 23:45 ` dan.j.williams
2025-07-17 18:33 ` [PATCH v4 06/10] PCI: Add PCIe Device 3 Extended Capability enumeration Dan Williams
2025-07-29 15:23 ` Jonathan Cameron
2025-08-06 21:00 ` dan.j.williams
2025-08-06 21:02 ` dan.j.williams
2025-08-07 22:06 ` Bjorn Helgaas
2025-08-09 0:05 ` dan.j.williams
2025-08-07 22:46 ` Bjorn Helgaas
2025-07-17 18:33 ` [PATCH v4 07/10] PCI/IDE: Add IDE establishment helpers Dan Williams
2025-07-29 15:45 ` Jonathan Cameron
2025-08-06 21:40 ` dan.j.williams
2025-08-07 22:38 ` Bjorn Helgaas
2025-08-09 1:52 ` dan.j.williams
2025-08-07 22:47 ` Bjorn Helgaas
2025-08-08 10:21 ` Arto Merilainen
2025-08-08 17:26 ` dan.j.williams
2025-08-11 8:02 ` Arto Merilainen
2025-08-28 8:19 ` Aneesh Kumar K.V
2025-09-11 4:15 ` Aneesh Kumar K.V
2025-09-11 19:25 ` dan.j.williams
2025-09-25 10:18 ` Xu Yilun [this message]
2025-09-25 11:30 ` Arto Merilainen
2025-07-17 18:33 ` [PATCH v4 08/10] PCI/IDE: Report available IDE streams Dan Williams
2025-07-29 15:47 ` Jonathan Cameron
2025-08-07 22:48 ` Bjorn Helgaas
2025-07-17 18:33 ` [PATCH v4 09/10] PCI/TSM: Report active " Dan Williams
2025-07-29 15:58 ` Jonathan Cameron
2025-08-06 21:55 ` dan.j.williams
2025-08-07 22:49 ` Bjorn Helgaas
2025-07-17 18:33 ` [PATCH v4 10/10] samples/devsec: Add sample IDE establishment Dan Williams
2025-07-29 16:06 ` Jonathan Cameron
2025-07-18 10:57 ` [PATCH v4 00/10] PCI/TSM: Core infrastructure for PCI device security (TDISP) Aneesh Kumar K.V
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=aNUW6s9++Ely4v2R@yilunxu-OptiPlex-7050 \
--to=yilun.xu@linux.intel.com \
--cc=aik@amd.com \
--cc=amerilainen@nvidia.com \
--cc=aneesh.kumar@kernel.org \
--cc=bhelgaas@google.com \
--cc=dan.j.williams@intel.com \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=sameo@rivosinc.com \
/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