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

Re: [PATCH] vpci: introduce per-domain lock to protect vpci structure


  • To: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Fri, 11 Feb 2022 16:44:02 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; 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=wgKdJrADDx7vLgciLHuGqrjnG5eQrRWvFKfaM1dzUKY=; b=Tl4WEtRHsVykSO3PvfnAeVftRfLkr8aXv0IPzeWoSLtp8RLHTtIAKL5IbDZlHcNIoeKCBB7YVZ/xPfn9eWvRuMnP0nNeAEQPSXJGGPJzbuVaHYXpJjrFbb4B5vc2hzb6SIxI6JFgt+DkaMtta3+sqp3DaJA73WF3FWgBsGhOzR4CsUCWTjFhGBzf2r8gF/fb4hRpZA4dTle9k3wVynYx7D4CDN4XOUPjRdm0WJnKlm0Xm3nqhb96/PNblyuh38mrmTCAyyvzzHhvw7VmQHQ4m7rneOaiaAXtgZhius46Ld7fSZXUEq7sqrBWoH01AzypBs4wtT6GdIbwLzOLRzMykw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=evmNfj5J9athv/Q/MAnV7/PHE9GU+ldOFkQc+Q+YKI9q8tPdqachrlArfdybyw3U0ZSjrM/RfYitXNc9tf+BIEaPjpywV10vwQrXupZZmdJQjPcTluJWfuSiS6ksSvSymtgx5PFqXkFHVMQvGFTF0W0/y4DMGwoyAQdM+j+E0/ZsWIsmAzjF7Sp8f0ahbLYnUdIlJaxS+Jz8XYioFdLsLEK1YN0dVjKZAaADmCDsDopnIWPtG39MYBjNmHpg9/C16LYOHx/+Pv6/Z6KGAWRlaDqC9OzVUcQ5Q9YWXaDSq0LKv5wtJvwAAfGkP9mFGHMyojxiNqIQHfNxUu4uGSV77A==
  • Authentication-results: esa4.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "jbeulich@xxxxxxxx" <jbeulich@xxxxxxxx>, "julien@xxxxxxx" <julien@xxxxxxx>, "sstabellini@xxxxxxxxxx" <sstabellini@xxxxxxxxxx>, Oleksandr Tyshchenko <Oleksandr_Tyshchenko@xxxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Artem Mygaiev <Artem_Mygaiev@xxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Rahul Singh <rahul.singh@xxxxxxx>
  • Delivery-date: Fri, 11 Feb 2022 15:44:30 +0000
  • Ironport-data: A9a23:VuD+yq6TlY11zgSjxNbH2AxRtCrBchMFZxGqfqrLsTDasY5as4F+v mNND2nQb67ba2P3fox1PYq08BhSv5TcydYwTFBu+CxhHi5G8cbLO4+Ufxz6V8+wwmwvb67FA +E2MISowBUcFyeEzvuV3zyIQUBUjclkfJKlYAL/En03FV8MpBsJ00o5wbZj29cw27BVPivW0 T/Mi5yHULOa82Yc3lI8s8pvfzs24ZweEBtB1rAPTagjUG32zhH5P7pGTU2FFFPqQ5E8IwKPb 72rIIdVXI/u10xF5tuNyt4Xe6CRK1LYFVDmZnF+A8BOjvXez8CbP2lS2Pc0MC9qZzu1c99Z+ okWq6WbGAgVNZaUkeQMD0YCODx8IvgTkFPHCSDXXc27ykTHdz3nwul0DVFwNoodkgp1KTgQr 7pCcmlLN03dwbLtqF64YrAEasALNs7kMZlZonh95TrYEewnUdbIRKCiCdpwgmlq25kVQ622i 8wxOBxBUwrpbT5zCF4dIbRiv8rzv3umbGgNwL6SjfVuuDWCpOBr65DTN97Sds2PVN9itE+Sr WLb/Ez0GhgfcteYzFKt1XahhfTGmy/hb74DD72z9vNsg1q7y3QaDVsdUl7TidCjlkO7bPdOJ EUV9zQGoLA78QqgSdyVdwexoGOA+AUdXdVQO+Qg7UeGza+8ywyUHHQeRzhNLtkvrtYrRCcC3 0WM2djuAFRHoLCTDH6Q6LqQhTezIjQOa38PYzceSgkI6MWlp5s85jroSttgC6ezgsfCMDf82 S2RrCM+irMQiuYGz6y+u1vAhlqEpJLEUwo07QX/RX++40VyY4vNT5ez9VHR4PJELYCYZlqMp n4Jn46Z9u9mJZOQkC2ARs0dEbfv4OyKWAAwmnY2QcNnrW70vSf+I8YAu1mSOXuFLO42JWT3W WSCtj9a38daPGr2MvVcfoCuXpFCIbfbKfzpUfXdb9xra5d3dROa8CwGWXN8z1wBg2B3z/hhZ M7zndKESC9DVP85lGbeq/I1jOdzrh3S018/UnwSI/6P9bOFLECYRr4eWLdlRrBotfjUyOk5H js2Cidr9/m9eLCmCsU02dRKRbzvEZTdLcqnwyCwXrTdSjeK4El7V5fsLUoJIuSJZZh9mObS5 W2aUURF0lf5jnCvAVzUNiw+Mu6wAswi9CpT0ckQ0bCAgSlLjWGHtvl3SnfKVeN/qLwLIQBcE 5HphPls8twQE2+aqlzxnLH2rZB4dQTDuO59F3HNXdTLRLY5H1ah0oa9JmPHrXBSZgLq5ZpWi +DxjWvzHMtcLzmO+e6LMZpDOXvq5iND8A+zNmOVSuRulLLErtQ0dXyr06NfzgNlAUyr+wZ2H j2+WH8wjeLMv5U04J/Og6WFpJ2uCOxwAgxRGGyz0Fp8HXOyErOLzdASXeCWUyraUW+oqqyua f8Ml6P3MeEdnUYMuI15Su45waU77trphrlb0gU7QymbMwX1UuttciucwM1ClqxR3bsF6wG4b V2Cp4tBMrKTNcK7TFNIfFg5bv6O3O0/kyXJ6ahnO13z4SJ6peLVUUhbMxSWpjZaKb95bNEsz es74ZZE4A2jkBs6dN2Bi3kMpWiLK3UBVYQht40bX9C32lZ6lAkabMWFWCHs4ZyJZ9FdCWUQI 2eZ1PjYmrBR5kveaH5vR3LD6vVQ2MYVsxdQwV5ce1nQwojZhuU61QF6+CgsSlgH1Q1O1u9+N zQ5N0BxIqnSrT5kiNIaAjKpEgBFQhaY5lbw2x0Ck2iAFxukUWnELWscP+eR/R9GrzIAL2YDp LzImnz4VTvKfd3q2npgUEFonPXvUNht+1CQg8ugBcmEQ8E3bDeNbnVCvobUR88L2f8MuXA=
  • Ironport-hdrordr: A9a23:8T0ED6qT0wL8BuXBMvC6pPgaV5u8L9V00zEX/kB9WHVpm5Oj+P xGzc526farslsssSkb6Ku90dq7MAnhHP9OkMMs1NiZLW7bUQeTTL2KqLGSuwEIeBeOu9K1t5 0QFZSWYeeYZTMR46fHCUuDYq8dKbG8geWVbIzlvhVQpHRRGsVdBnBCe2Om+yNNNWp7LKt8MK DZyttMpjKmd3hSRN+8HGM5U+/KoMCOvI76YDYdbiRXpDWmvHeN0vrXAhKY1hARX3dk2rE561 XIlAT/++GKr+y78BnBzGXehq4m1+cJi+EzSvBkuPJlagkEuTzYJ7iJbofy/Qzd7tvfqmrC2+ O83ivId/4Dl085OFvF5ScFkjOQrwoG+jvsz0SVjmDkptG8TDUmC9BZjYYcaRfB7VE81esMmZ 6j8ljpwKa/Nymw6hgVJuK4JC1Chw6xuz4vgOQTh3tQXc8Xb6JQt5UW+AdQHI0bFCz35Yg7GK 02Zfusr8p+YBefdTTUr2NvyNujUjA6GQqHWFELvoiQ3yJNlH50wkMEzIgUn2sG9pg6V55Yjt 60ephAhfVLVIsbfKh9DOAOTY++DXHMWwvFNCaILVHuBMg8SgbwQl7MkcAIDc2RCe01JaoJ6e b8uQljxBAPkmrVeL2z4KE=
  • Ironport-sdr: 028tthY1i0h/JNOt3X+QEEQwHFcqeQRf9FBFZylQrlvvdDvZFILVm2XKi9ZUv9wnP/4z49YpEl MsGbwyIoWbuooyc6HQqY9Gi6tg+Y01kg3q0estmv3rLR663lcq092UvKZl17ct/LR/gekMXK9K rEO7TL56whGAvcUUhXxp+qD010woG1dLmanzd0/fAWaipdWF+ekDQW7Wv5Cinvkncz6jMUuCyX H4OSW0kerEQXWGkNDEUblySXHcn/tw3FKp7VgUmOBCDli701CkRCFXaw7R7kDEOh9cQiTKaGCv Z1JawnNPh5LizNun/wFvYKuu
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Fri, Feb 11, 2022 at 12:13:38PM +0000, Oleksandr Andrushchenko wrote:
> 
> 
> On 11.02.22 13:40, Roger Pau Monné wrote:
> > On Fri, Feb 11, 2022 at 07:27:39AM +0000, Oleksandr Andrushchenko wrote:
> >> Hi, Roger!
> >>
> >> On 10.02.22 18:16, Roger Pau Monné wrote:
> >>> On Wed, Feb 09, 2022 at 03:36:27PM +0200, Oleksandr Andrushchenko wrote:
> >>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@xxxxxxxx>
> >>>>
> >>>> Introduce a per-domain read/write lock to check whether vpci is present,
> >>>> so we are sure there are no accesses to the contents of the vpci struct
> >>>> if not. This lock can be used (and in a few cases is used right away)
> >>>> so that vpci removal can be performed while holding the lock in write
> >>>> mode. Previously such removal could race with vpci_read for example.
> >>> Sadly there's still a race in the usage of pci_get_pdev_by_domain wrt
> >>> pci_remove_device, and likely when vPCI gets also used in
> >>> {de}assign_device I think.
> >> Yes, this is indeed an issue, but I was not trying to solve it in
> >> context of vPCI locking yet. I think we should discuss how do
> >> we approach pdev locking, so I can create a patch for that.
> >> that being said, I would like not to solve pdev in  this patch yet
> >>
> >> ...I do understand we do want to avoid that, but at the moment
> >> a single reliable way for making sure pdev is alive seems to
> >> be pcidevs_lock....
> > I think we will need to make pcidevs_lock a rwlock and take it in read
> > mode for pci_get_pdev_by_domain.
> >
> > We didn't have this scenario before where PCI emulation is done in the
> > hypervisor, and hence the locking around those data structures has not
> > been designed for those use-cases.
> Yes, I do understand that.
> I hope pcidevs lock move to rwlock can be done as a separate
> patch. While this is not done, do you think we can proceed with
> vPCI series and pcidevs locking re-work being done after?

Ideally we would like to sort out the locking once and for all. I
would like to be sure that what we introduce now doesn't turn out to
interact badly when we decide to look at the pcidevs locking issue.

Thanks, Roger.



 


Rackspace

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