[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v7 8/8] vpci/msix: Free MSIX resources when init_msix() fails



On Fri, Jul 04, 2025 at 03:08:03PM +0800, Jiqian Chen wrote:
> When init_msix() fails, current logic return fail and free MSIX-related
> resources in vpci_deassign_device(). But the previous new changes will
> hide MSIX capability and return success, it can't reach
> vpci_deassign_device() to remove resources if hiding success, so those
> resources must be removed in cleanup function of MSIX.
> 
> To do that, implement cleanup function for MSIX.
> 
> Signed-off-by: Jiqian Chen <Jiqian.Chen@xxxxxxx>
> ---
> cc: "Roger Pau Monné" <roger.pau@xxxxxxxxxx>
> ---
> v6->v7 changes:
> * Change the pointer parameter of cleanup_msix() to be const.
> * When vpci_remove_registers() in cleanup_msix() fails, not to return
>   directly, instead try to free msix and re-add ctrl handler.
> * Pass pdev->vpci into vpci_add_register() instead of pdev->vpci->msix in
>   init_msix() since we need that every handler realize that msix is NULL
>   when msix is freed but handlers are still in there.
> 
> v5->v6 changes:
> * Change the logic to add dummy handler when !vpci->msix in cleanup_msix().
> 
> v4->v5 changes:
> * Change definition "static void cleanup_msix" to "static int cf_check 
> cleanup_msix"
>   since cleanup hook is changed to be int.
> * Add a read-only register for MSIX Control Register in the end of 
> cleanup_msix().
> 
> v3->v4 changes:
> * Change function name from fini_msix() to cleanup_msix().
> * Change to use XFREE to free vpci->msix.
> * In cleanup function, change the sequence of check and remove action 
> according to
>   init_msix().
> 
> v2->v3 changes:
> * Remove unnecessary clean operations in fini_msix().
> 
> v1->v2 changes:
> new patch.
> 
> Best regards,
> Jiqian Chen.
> ---
>  xen/drivers/vpci/msix.c | 54 ++++++++++++++++++++++++++++++++++++++---
>  1 file changed, 50 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/drivers/vpci/msix.c b/xen/drivers/vpci/msix.c
> index a1692b9d9f6a..114280337f3f 100644
> --- a/xen/drivers/vpci/msix.c
> +++ b/xen/drivers/vpci/msix.c
> @@ -36,7 +36,11 @@
>  static uint32_t cf_check control_read(
>      const struct pci_dev *pdev, unsigned int reg, void *data)
>  {
> -    const struct vpci_msix *msix = data;
> +    const struct vpci *vpci = data;
> +    const struct vpci_msix *msix = vpci->msix;
> +
> +    if ( !msix )
> +        return pci_conf_read16(pdev->sbdf, reg);
>  
>      return (msix->max_entries - 1) |
>             (msix->enabled ? PCI_MSIX_FLAGS_ENABLE : 0) |
> @@ -74,12 +78,16 @@ static void update_entry(struct vpci_msix_entry *entry,
>  static void cf_check control_write(
>      const struct pci_dev *pdev, unsigned int reg, uint32_t val, void *data)
>  {
> -    struct vpci_msix *msix = data;
> +    struct vpci *vpci = data;
> +    struct vpci_msix *msix = vpci->msix;
>      bool new_masked = val & PCI_MSIX_FLAGS_MASKALL;
>      bool new_enabled = val & PCI_MSIX_FLAGS_ENABLE;
>      unsigned int i;
>      int rc;
>  
> +    if ( !msix )
> +        return;
> +
>      if ( new_masked == msix->masked && new_enabled == msix->enabled )
>          return;
>  
> @@ -656,6 +664,44 @@ static int vpci_make_msix_hole(const struct pci_dev 
> *pdev)
>      return 0;
>  }
>  
> +static int cf_check cleanup_msix(const struct pci_dev *pdev)
> +{
> +    int rc;
> +    struct vpci *vpci = pdev->vpci;
> +    const unsigned int msix_pos = pdev->msix_pos;
> +
> +    if ( !msix_pos )
> +        return 0;
> +
> +    rc = vpci_remove_registers(vpci, msix_control_reg(msix_pos), 2);
> +    if ( rc )
> +        printk(XENLOG_WARNING "%pd %pp: fail to remove MSIX handlers 
> rc=%d\n",
> +               pdev->domain, &pdev->sbdf, rc);

The same comment as in the previous patch: vpci_remove_registers()
returning an error would likely imply memory corruption, and hence
it's best to just return error and avoid having to modify the
handlers.

Thanks, Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.