From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jiqian Chen <Jiqian.Chen@amd.com>
Cc: xen-devel@lists.xenproject.org, Huang Rui <ray.huang@amd.com>
Subject: Re: [PATCH v1 3/3] vpci/msi: Remove registers when init_msi() fails
Date: Thu, 27 Mar 2025 13:44:06 +0100 [thread overview]
Message-ID: <Z-VIFo7q7-UNsLCt@macbook.local> (raw)
In-Reply-To: <20250327073214.158210-3-Jiqian.Chen@amd.com>
On Thu, Mar 27, 2025 at 03:32:14PM +0800, Jiqian Chen wrote:
> When init_msi() fails, the new codes will try to hide MSI
> capability, so it can't rely on vpci_deassign_device() to
> remove all MSI related registers anymore, those registers
> must be cleaned up in failure path of init_msi.
>
> To do that, use a vpci_register array to record all MSI
> registers and call vpci_remove_register() to remove registers.
As I'm just seeing 3 patches on the series, isn't there one missing
for MSI-X at least?
> Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com>
> ---
> xen/drivers/vpci/msi.c | 57 +++++++++++++++++++++++++++++-------------
> 1 file changed, 39 insertions(+), 18 deletions(-)
>
> diff --git a/xen/drivers/vpci/msi.c b/xen/drivers/vpci/msi.c
> index 9d7a9fd8dba1..30ef97efb7b0 100644
> --- a/xen/drivers/vpci/msi.c
> +++ b/xen/drivers/vpci/msi.c
> @@ -195,6 +195,9 @@ static void cf_check mask_write(
>
> static int cf_check init_msi(struct pci_dev *pdev)
> {
> + unsigned int offset;
> + unsigned int reg_index = 0;
> + struct vpci_register registers[VPCI_CAP_MAX_REGISTER];
> unsigned int pos = pdev->msi_pos;
> uint16_t control;
> int ret;
> @@ -206,15 +209,13 @@ static int cf_check init_msi(struct pci_dev *pdev)
> if ( !pdev->vpci->msi )
> return -ENOMEM;
>
> + offset = msi_control_reg(pos);
> ret = vpci_add_register(pdev->vpci, control_read, control_write,
> - msi_control_reg(pos), 2, pdev->vpci->msi);
> + offset, 2, pdev->vpci->msi);
> if ( ret )
> - /*
> - * NB: there's no need to free the msi struct or remove the register
> - * handlers form the config space, the caller will take care of the
> - * cleanup.
> - */
> - return ret;
> + goto fail;
> + registers[reg_index].offset = offset;
> + registers[reg_index++].size = 2;
>
> /* Get the maximum number of vectors the device supports. */
> control = pci_conf_read16(pdev->sbdf, msi_control_reg(pos));
> @@ -234,33 +235,42 @@ static int cf_check init_msi(struct pci_dev *pdev)
> pdev->vpci->msi->address64 = is_64bit_address(control);
> pdev->vpci->msi->masking = is_mask_bit_support(control);
>
> + offset = msi_lower_address_reg(pos);
> ret = vpci_add_register(pdev->vpci, address_read, address_write,
> - msi_lower_address_reg(pos), 4, pdev->vpci->msi);
> + offset, 4, pdev->vpci->msi);
> if ( ret )
> - return ret;
> + goto fail;
> + registers[reg_index].offset = offset;
> + registers[reg_index++].size = 4;
>
> + offset = msi_data_reg(pos, pdev->vpci->msi->address64);
> ret = vpci_add_register(pdev->vpci, data_read, data_write,
> - msi_data_reg(pos, pdev->vpci->msi->address64), 2,
> - pdev->vpci->msi);
> + offset, 2, pdev->vpci->msi);
> if ( ret )
> - return ret;
> + goto fail;
> + registers[reg_index].offset = offset;
> + registers[reg_index++].size = 2;
>
> if ( pdev->vpci->msi->address64 )
> {
> + offset = msi_upper_address_reg(pos);
> ret = vpci_add_register(pdev->vpci, address_hi_read, address_hi_write,
> - msi_upper_address_reg(pos), 4, pdev->vpci->msi);
> + offset, 4, pdev->vpci->msi);
> if ( ret )
> - return ret;
> + goto fail;
> + registers[reg_index].offset = offset;
> + registers[reg_index++].size = 4;
> }
>
> if ( pdev->vpci->msi->masking )
> {
> + offset = msi_mask_bits_reg(pos, pdev->vpci->msi->address64);
> ret = vpci_add_register(pdev->vpci, mask_read, mask_write,
> - msi_mask_bits_reg(pos,
> - pdev->vpci->msi->address64),
> - 4, pdev->vpci->msi);
> + offset, 4, pdev->vpci->msi);
> if ( ret )
> - return ret;
> + goto fail;
> + registers[reg_index].offset = offset;
> + registers[reg_index++].size = 4;
As commented on the previous patch, I don't like much the usage of
this registers array to store which handlers have been added. It
would be best if you just removed every possible handler that could be
added, without keeping track of them.
Thinking about it, do we maybe need a helper vcpi function that wipes
all handlers from a specific range? I think it could be helpful here,
as the size of the capabilities is well-known, so on error it would be
easier to just call such a generic handler to wipe all hooks added to
the region covered by the failing capability.
Let me know what you think of it.
Thanks, Roger.
next prev parent reply other threads:[~2025-03-27 12:44 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-27 7:32 [PATCH v1 1/3] vpci: Hide capability when it fails to initialize Jiqian Chen
2025-03-27 7:32 ` [PATCH v1 2/3] vpci/rebar: Remove registers when init_rebar() fails Jiqian Chen
2025-03-27 12:38 ` Roger Pau Monné
2025-03-27 7:32 ` [PATCH v1 3/3] vpci/msi: Remove registers when init_msi() fails Jiqian Chen
2025-03-27 12:44 ` Roger Pau Monné [this message]
2025-03-31 8:13 ` Chen, Jiqian
2025-03-31 8:53 ` Roger Pau Monné
2025-03-31 9:43 ` Chen, Jiqian
2025-03-31 11:12 ` Roger Pau Monné
2025-03-27 9:25 ` [PATCH v1 1/3] vpci: Hide capability when it fails to initialize Roger Pau Monné
2025-03-31 7:26 ` Chen, Jiqian
2025-03-31 8:43 ` Roger Pau Monné
2025-03-31 8:46 ` Jan Beulich
2025-03-31 9:32 ` Chen, Jiqian
2025-03-31 11:04 ` Roger Pau Monné
2025-04-01 9:17 ` Chen, Jiqian
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=Z-VIFo7q7-UNsLCt@macbook.local \
--to=roger.pau@citrix.com \
--cc=Jiqian.Chen@amd.com \
--cc=ray.huang@amd.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.