From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
To: Dan Williams <dan.j.williams@intel.com>, <linux-cxl@vger.kernel.org>
Subject: Not enough CXL HDM decoders in pass through host bridges (sort of)
Date: Thu, 16 Feb 2023 18:30:25 +0000 [thread overview]
Message-ID: <20230216183025.00000e39@huawei.com> (raw)
Hi Dan,
I've finally been adding support for multiple HDM decoders in QEMU
(need to implement the address decode at EPs, but have it working at
HB and switch USP)
Whilst testing ran into a corner case on the kernel side of things.
Host Bridge
|
Root Port
|
Switch USP
|
________|_________
| |
DSP0 DSP1
| |
Type3 Type3
Previously I'd been testing this with either an interleave across the two
Type3 devices or with just one in use (as I only had one HDM decoder in the SW USP
so couldn't handle anything else)
Now I have lots of decoders, I added a simple test with two regions. One on each of
the type 3 devices.
It fails on the second region (with a "no decoder available error") because...
It's trying to find an HDM decoder in the host bridge and the fake one used
for a pass through decoder is 'already in use' by the first region.
I'm not sure we can simply skip the check in this case because cxld->region
can only point at one region at a time and I haven't though through
the impacts of that for a pass through decoder. The cynic in me says
that if this HB had more RPs, we'd have a maximum of 32 decoders, so
just fake 32 of them instead of 1 and not worry about it any more but
that feels like a hack and probably has side effects.
I thought I'd raise the issue first and think about a solution afterwards
(and secretly hope it is fixed before I get to it ;)).
Obviously I can avoid the whole thing by adding an RP and hence have
actually decoders to use up on the host bridge which does fine for
testing my QEMU work, but we still need to fix this up - unless I'm missing
some subtlety.
There is another question of whether we should make some effort to conserve
decoders - so if we can just expand an existing one to cover a wider range?
We can't do that after commit, but maybe there is a dance we could do to
soft commit a bunch of regions, then hard commit them as a set.
HDM decoders may be a precious resource on some systems even though CXL 3.0
let's host bridges have 32 of them. One to tackle only when it's a real problem
though.
Jonathan
next reply other threads:[~2023-02-16 18:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-16 18:30 Jonathan Cameron [this message]
2023-02-16 22:11 ` Not enough CXL HDM decoders in pass through host bridges (sort of) Dan Williams
2023-02-17 11:33 ` Jonathan Cameron
2023-02-17 14:29 ` Jonathan Cameron
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=20230216183025.00000e39@huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=dan.j.williams@intel.com \
--cc=linux-cxl@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox