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

Re: [PATCH v3 5/6] vpci: use reference counter to protect vpci state


  • To: Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Fri, 17 Mar 2023 09:43:24 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=TC6gEcbprR+YQ02obtqbKU98TWnGsM6iNBqFbjjtes0=; b=eNzdpLOAnHfm02FCk6ESDUNoSrnqbXhpIRGUSu1g0GddS1wS8SVdDisHJFIF9yekuT5mXrXUWUkUDJT0qF8S7gpYkX24lzzdXRNAvCSM9PsPh/9xj6Varu5K03j0eAlyF3bPwKFbFFrIhGvTt+28fkBtHTw55oU9xw+LZvraABSWcp2w5Dc+el7SOmK+QYPHtu0dwI6/mO3RqV5XrNrd/7XdKRX6UC4PVmem9sq0vmWPPKfOb5w+BdBhXmBsk4aA8Z4JEVeqSEVkR2xeF3di2E61F94eo2TcuhNTsXOw5ANQOVbtRnpphNmJGRNd5J60tKMy83Dm/hujIJ3hr8FQtA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Yfq4CXh4HzgEkHz/dNA+4rhmBXBi53w4kpq6YWAM5Vt/Kqq8r0fqQq3UCW+8OEI1zvuS935jRjdswaQ7SpdoyyH/Y6xmNn7OkgXIvZeF1WjS7LoJ7w6FLjaxP2Sghe9vH0exUbkoYK4OSXfkRd0DbkMmEk5lBfEmuRob0IqNnsR1u95dCAJZclx37n9w81DQsX/KMQXv8rQpjeq3/t1oWOaTNa0bwt6tHvBbf/hGs2O6wJR50/iTfsIEfChMl0SzR70OEfhGIenvYw7ZFUbf8+t1Gc/sgVxTzGpBe9CeqgY4ZFE+kERvmt8x8WzursMfbPA6yhztDlXuwKRerFZ32w==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>
  • Delivery-date: Fri, 17 Mar 2023 08:43:43 +0000
  • Ironport-data: A9a23:jua6DK+58z20cgjHLzFrDrUDtn+TJUtcMsCJ2f8bNWPcYEJGY0x3n GIZXWGDOqyKM2TzftwlPN/k9khQv5HQmt4yGgpur388E34SpcT7XtnIdU2Y0wF+jCHgZBk+s 5hBMImowOQcFCK0SsKFa+C5xZVE/fjUAOG6UKicYXoZqTZMEE8JkQhkl/MynrlmiN24BxLlk d7pqojUNUTNNwRcawr40Ire7kI/1BjOkGlA5AdmPqkU5Aa2e0Q9V/rzG4ngdxMUfaEMdgKKb 76r5K20+Grf4yAsBruN+losWhRXKlJ6FVHmZkt+A8BOsDAbzsAB+v9T2M4nQVVWk120c+VZk 72hg3ASpTABZcUgkMxFO/VR/roX0aduoNcrKlDn2SCfItGvn9IBDJyCAWlvVbD09NqbDklky 94yBxMMbCqkxNyYnbaqbO02p+MKeZyD0IM34hmMzBn/JNN/GdXmfP+P4tVVmjAtmspJAPDSI dIDbiZiZwjBZBsJPUoLDJU5n6GjgXyXnz9w8QrJ4/ZopTWOilUpiNABM/KMEjCObd9SkUuC4 HrP4kzyAw0ANczZwj2Amp6prraXxXugCdlNStVU8NZ13kGIm2UfISYKcmH8+8ep0k7mVehmf hl8Fi0G6PJaGFaQZuf6Wxq0sXuVpCk2UtBbE/A5wAyVw6+S6AGcbkAUQzgEZNE4ucseQT0xy kTPj97vHSZosrCeVTSa7Lj8hTG4NDURLGQCTTQZVgZD6N7myLzflTrKR9dnVauq1Nv8HGiox yjQ9XBmwbIOkcQMyqO3u0jdhC6hrYTISQhz4RjLWmWi7UVyY4vNi5GU1GU3JM1odO6xJmRtd lBd8yRCxIji1a2wqRE=
  • Ironport-hdrordr: A9a23:/D4SOK2hgJCs0Ab5n5V43wqjBHYkLtp133Aq2lEZdPU0SKGlfq GV7ZEmPHrP4gr5N0tOpTntAse9qBDnhPxICOsqXYtKNTOO0AeVxelZhrcKqAeQeBEWmNQ96U 9hGZIOcuEZDzJB/LvHCN/TKadd/DGFmprY+ts31x1WPGVXgzkL1XYANu6ceHcGIzVuNN4CO7 e3wNFInDakcWR/VLXBOpFUN9KzweEijfjdEGc7OyI=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Tue, Mar 14, 2023 at 08:56:30PM +0000, Volodymyr Babchuk wrote:
> vPCI MMIO handlers are accessing pdevs without protecting this
> access with pcidevs_{lock|unlock}. This is not a problem as of now
> as these are only used by Dom0. But, towards vPCI is used also for
> guests, we need to properly protect pdev and pdev->vpci from being
> removed while still in use.
> 
> For that use pdev reference counting.

I wonder whether vPCI does need to take another reference to the
device.  This all stems from me not having it fully clear how the
reference counting is supposed to be used for pdevs.

As mentioned in a previous patch, I would expect device assignation to
take a reference, and hence vPCI won't need to take an extra refcount
since vPCI can only be used once the device has been assigned to a
domain, and hence already has at least an extra reference taken from
the fact it's assigned to a domain.

If anything I would add an ASSERT(pdev->refcount > 1) or equivalent.

> 
> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@xxxxxxxx>
> Suggested-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> ---
> 
> v3:
>  - Moved from another patch series
> ---
>  xen/drivers/vpci/vpci.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
> index 199ff55672..005f38dc77 100644
> --- a/xen/drivers/vpci/vpci.c
> +++ b/xen/drivers/vpci/vpci.c
> @@ -62,6 +62,7 @@ void vpci_remove_device(struct pci_dev *pdev)
>      xfree(pdev->vpci->msi);
>      xfree(pdev->vpci);
>      pdev->vpci = NULL;
> +    pcidev_put(pdev);
>  }
>  
>  int vpci_add_handlers(struct pci_dev *pdev)
> @@ -72,6 +73,8 @@ int vpci_add_handlers(struct pci_dev *pdev)
>      if ( !has_vpci(pdev->domain) )
>          return 0;
>  
> +    pcidev_get(pdev);
> +
>      /* We should not get here twice for the same device. */
>      ASSERT(!pdev->vpci);

You are missing a pcidev_put() in case allocation of pdev->vpci fails.

Thanks, Roger.



 


Rackspace

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