From: "Roger Pau Monné" <roger.pau@citrix.com>
To: "Chen, Jiqian" <Jiqian.Chen@amd.com>
Cc: Jan Beulich <jbeulich@suse.com>, "Huang, Ray" <Ray.Huang@amd.com>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v4 09/10] vpci/msi: Free MSI resources when init_msi() fails
Date: Wed, 21 May 2025 13:23:48 +0200 [thread overview]
Message-ID: <aC23xI0qgsAqLb2S@macbook.local> (raw)
In-Reply-To: <BL1PR12MB5849E2CD05D70E7A475646F3E79EA@BL1PR12MB5849.namprd12.prod.outlook.com>
On Wed, May 21, 2025 at 07:00:37AM +0000, Chen, Jiqian wrote:
> On 2025/5/20 17:43, Roger Pau Monné wrote:
> > On Tue, May 20, 2025 at 11:14:27AM +0200, Jan Beulich wrote:
> >> On 20.05.2025 11:09, Roger Pau Monné wrote:
> >>> On Tue, May 20, 2025 at 08:40:28AM +0200, Jan Beulich wrote:
> >>>> On 09.05.2025 11:05, Jiqian Chen wrote:
> >>>>> When init_msi() fails, the previous new changes will hide MSI
> >>>>> capability, it can't rely on vpci_deassign_device() to remove
> >>>>> all MSI related resources anymore, those resources must be
> >>>>> removed in cleanup function of MSI.
> >>>>
> >>>> That's because vpci_deassign_device() simply isn't called anymore?
> >>>> Could do with wording along these lines then. But (also applicable
> >>>> to the previous patch) - doesn't this need to come earlier? And is
> >>>> it sufficient to simply remove the register intercepts? Don't you
> >>>> need to put in place ones dropping all writes and making all reads
> >>>> return either 0 or ~0 (covering in particular Dom0, while for DomU-s
> >>>> this may already be the case by default behavior)?
> >>>
> >>> For domUs this is already the default behavior.
> >>>
> >>> For dom0 I think it should be enough to hide the capability from the
> >>> linked list, but not hide all the capability related
> >>> registers. IMO a well behaved dom0 won't try to access capabilities
> >>> disconnected from the linked list,
> >>
> >> Just that I've seen drivers knowing where their device has certain
> >> capabilities, thus not bothering to look up the respective
> >> capability.
> >
> > OK, so let's make the control register read-only in case of failure.
> >
> > If MSI(-X) is already enabled we should also make the entries
> > read-only, and while that's not very complicated for MSI, it does get
> > more convoluted for MSI-X. I'm fine with just making the control
> > register read-only for the time being.
> If I understand correctly, I need to avoid control register being removed and set the write hook of control register to be vpci_ignored_write and avoid freeing vpci->msi?
>
> "
> if ( !msi_pos || !vpci->msi )
> return;
>
> + spin_lock(&vpci->lock);
> + control = vpci_get_register(vpci, msi_control_reg(msi_pos), 2);
> + if ( control )
> + control->write = vpci_ignored_write;
> + spin_unlock(&vpci->lock);
> +
> if ( vpci->msi->masking )
> end = msi_pending_bits_reg(msi_pos, vpci->msi->address64);
> else
> end = msi_mask_bits_reg(msi_pos, vpci->msi->address64) - 2;
>
> - size = end - msi_control_reg(msi_pos);
> + start = msi_control_reg(msi_pos) + 2;
> + size = end - start;
>
> - vpci_remove_registers(vpci, msi_control_reg(msi_pos), size);
> - XFREE(vpci->msi);
> + vpci_remove_registers(vpci, start, size);
I think you want to first purge all the MSI range, and then add the
control register, also you want to keep the XFREE(), and set the
register as:
vpci_add_register(vpci, vpci_hw_read16, NULL, msi_control_reg(msi_pos),
2, NULL);
So that you make it strictly hardware read-only, and not use the data
in vpci->msi.
Regards, Roger.
next prev parent reply other threads:[~2025-05-21 11:24 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-09 9:05 [PATCH v4 00/10] Support hiding capability when its initialization fails Jiqian Chen
2025-05-09 9:05 ` [PATCH v4 01/10] vpci/header: Move emulating cap list logic into new function Jiqian Chen
2025-05-09 9:05 ` [PATCH v4 02/10] vpci/header: Emulate legacy capability list for dom0 Jiqian Chen
2025-05-15 16:29 ` Roger Pau Monné
2025-05-16 2:33 ` Chen, Jiqian
2025-05-09 9:05 ` [PATCH v4 03/10] vpci/header: Emulate extended " Jiqian Chen
2025-05-18 14:20 ` Jan Beulich
2025-05-19 6:43 ` Chen, Jiqian
2025-05-19 6:56 ` Jan Beulich
2025-05-19 7:13 ` Chen, Jiqian
2025-05-19 13:10 ` Jan Beulich
2025-05-19 13:21 ` Roger Pau Monné
2025-05-21 6:08 ` Chen, Jiqian
2025-05-21 6:25 ` Jan Beulich
2025-05-21 6:44 ` Chen, Jiqian
2025-05-09 9:05 ` [PATCH v4 04/10] vpci: Refactor REGISTER_VPCI_INIT Jiqian Chen
2025-05-18 14:34 ` Jan Beulich
2025-05-19 6:56 ` Chen, Jiqian
2025-05-19 13:07 ` Jan Beulich
2025-05-09 9:05 ` [PATCH v4 05/10] vpci: Hide legacy capability when it fails to initialize Jiqian Chen
2025-05-18 14:44 ` Jan Beulich
2025-05-19 7:35 ` Chen, Jiqian
2025-05-19 10:04 ` Roger Pau Monné
2025-05-09 9:05 ` [PATCH v4 06/10] vpci: Hide extended " Jiqian Chen
2025-05-18 14:47 ` Jan Beulich
2025-05-19 7:41 ` Chen, Jiqian
2025-05-19 13:12 ` Jan Beulich
2025-05-09 9:05 ` [PATCH v4 07/10] vpci: Refactor vpci_remove_register to remove matched registers Jiqian Chen
2025-05-19 6:30 ` Jan Beulich
2025-05-19 7:44 ` Chen, Jiqian
2025-05-19 10:24 ` Roger Pau Monné
2025-05-09 9:05 ` [PATCH v4 08/10] vpci/rebar: Remove registers when init_rebar() fails Jiqian Chen
2025-05-19 6:54 ` Jan Beulich
2025-05-19 7:49 ` Chen, Jiqian
2025-05-09 9:05 ` [PATCH v4 09/10] vpci/msi: Free MSI resources when init_msi() fails Jiqian Chen
2025-05-20 6:40 ` Jan Beulich
2025-05-20 9:09 ` Roger Pau Monné
2025-05-20 9:14 ` Jan Beulich
2025-05-20 9:43 ` Roger Pau Monné
2025-05-21 7:00 ` Chen, Jiqian
2025-05-21 11:23 ` Roger Pau Monné [this message]
2025-05-22 2:21 ` Chen, Jiqian
2025-05-22 7:12 ` Roger Pau Monné
2025-05-22 7:27 ` Chen, Jiqian
2025-05-09 9:05 ` [PATCH v4 10/10] vpci/msix: Add function to clean MSIX resources Jiqian Chen
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=aC23xI0qgsAqLb2S@macbook.local \
--to=roger.pau@citrix.com \
--cc=Jiqian.Chen@amd.com \
--cc=Ray.Huang@amd.com \
--cc=jbeulich@suse.com \
--cc=xen-devel@lists.xenproject.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.