[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 1/8] IOMMU/x86: drop locking from quarantine_init() hooks
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Tue, 12 Apr 2022 13:05:26 +0200
- 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=Idj5G4HzMqeRporWfc47xozFuzLW8B0S46K7qXnsnQE=; b=eOHAXz9U5XfcflGIEnD64Z36AssvuhsSINP2ytmA5PggRrsvK9QTeCbrVG/UBT2LS5NlXp5qzmzBtbIUKIMwJwUQf2UDPRXkE5tk/yUgNwHrp9Uz5KAgXW0rtITwr0pSF4dN8JZKEb788FQZW4cN4IaZc2V118Q+l0uX97gi+DljxkOLtZ+csm7Z2H+5EBOu+20KbMlCypBIzs61kLMjEPin4vmssW1iTf7TNiBMwimoPdo4N7eslnaFYXRJdzEeTa0Zclr2Q4gJyuCaqo0ULjM3Z7o+17j2eYCwODGv3lRH34E8SJX9vs/zeSmja5aBHLZRksmExRgZhdGEbEsz9A==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mzzC0dVa0iiDyiZ2U0wz5T2mnA+BN51o/xIpZDmHaORUsOtoF9TRYbZl9T9O+DOPBsD/kMgJd4LZAA87yJhxwAtyUnexce6RIVrgBn3Yo3wpxD/B2gD0TVPuQQ89THUoPLVoUsmvdlX8/WH4DxpZHZlbLcEi9l5mmy2AwCH+lpdmHZx1mgSpeK6z1zPy0//nehicDPVI75qg0cK4NBc7az/itHfjQeXRAsuSFg0TspXPG4jk2ZeMHrNoawjDuYT0V4vC5nJesKK0pN4sRcSZtOnMbYa6tOm+CAxq+RdZHPYy8vUtv2RnDv9FtLngQNlZsPjt39d27nREZooUdGwCCg==
- Authentication-results: esa6.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
- Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Kevin Tian <kevin.tian@xxxxxxxxx>, Paul Durrant <paul@xxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
- Delivery-date: Tue, 12 Apr 2022 11:05:47 +0000
- Ironport-data: A9a23:33vJk6J882zBa439FE+R/ZUlxSXFcZb7ZxGr2PjKsXjdYENS0mEPm jcYXGmDMvnfMGemfIhxYInl9BgC6JLRy4dmTABlqX01Q3x08seUXt7xwmUcns+xwm8vaGo9s q3yv/GZdJhcokf0/0vrav67xZVF/fngqoDUUYYoAQgsA148IMsdoUg7wbRh3tcy2YHR7z6l4 rseneWOYDdJ5BYsWo4kw/rrRMRH5amaVJsw5zTSVNgT1LPsvyB94KE3fMldG0DQUIhMdtNWc s6YpF2PEsE1yD92Yj+tuu6TnkTn2dc+NyDW4pZdc/DKbhSvOkXee0v0XRYRQR4/ttmHozx+4 NNWmLy7dVwJBK/FwLQyTQkfT310E6ITrdcrIVDn2SCS50jPcn+qyPRyFkAme4Yf/46bA0kXq 6ZecmpUKEne2aTmm9pXScE17ignBNPsM44F/Glp0BnSDOo8QICFSKLPjTNd9Glg25wSTKaED yYfQSJjNwvYWjdCAWsKJ8olg8OpjFqvURQN/Tp5ooJoujOOnWSdyoPFM9fLe9rMWcRcmG6Zo H7L+yLyBRRyHMSW1D6t4n+qwOjVkkvTWogfCbm5/f5Cm0CIyyoYDxh+fUu2p7y1h1CzX/pbK lcI4Ww+oK4q7kupQ9LhGRqirxa5UgU0AoQKVbdgsUfUl/SSs13x6nU4oiBpbscLlMQKHhwQ1 FbRz/z3FXsz7Le7RifInluLlg+aNS8QJG4EQCYLSwoZ/tXuyL0OYgLzosVLS/Ds0ICscd3k6 3XT9XVl2e1P5SIe///jlW0rlQ5AsXQgouQdwgzMFlyo4QpiDGJOT9z5sAOLhRqswWvwc7Vgg JTms5XGhAztJcvU/MBofAnrNOv3jxpiGGeB6WOD57F7q1yQF4eLJOi8Gg1WKkZzKdojcjT0e kLVsg45zMYNYCr1Nf4nM9vsUZlCIU3c+TLNDK+8gj1mOMYZSeN61Hs2OR74M57FzSDAbp3Ty b/EKJ3xXB72+IxszSasRvd17FPY7ntW+I8nfriil07P+ePHPBa9EO5ZWHPTPrFRxP7V+239r ocAX/ZmPj0CCYUSlAGMqtVNRb3LRFBmba3LRzt/KrbYclU7Qjl4YxITqJt4E7FYc21uvr6g1 lm2W1NCyUq5gnvCKA6QbWtkZq+pVpF6xU/X9wRwVbp08xDPubqS0Zo=
- Ironport-hdrordr: A9a23:y5nLuqwqA9V/P4gdV0LHKrPxteskLtp133Aq2lEZdPULSKOlfp GV8MjziyWYtN9wYhAdcdDpAtjmfZr5z+8O3WB3B8beYOCGghrSEGgG1+XfKlLbak/DH4JmpM Jdmu1FeaHN5DtB/LfHCWuDYq8dKbC8mcjC74eurEuFDzsaE52Ihz0JdDpzeXcGIjWua6BJcK Z1saF81kWdkDksH4+G7j5vZZm3m/T70LbdJTIWDR8u7weDyRuu9b7BChCdmjMTSSlGz7sO+X XM11WR3NTvj9iLjjvnk0PD5ZVfn9XsjvNFGcy3k8AQbhHhkByhaohNU6CL+Bo1vOaswlA3l8 SkmWZrA+1Dr1fqOk2lqxrk3AftlB4o9n/Z0FedxUDupMToLQhKffZptMZ8SF/0+kAgtNZz3O ZgxGSCradaChvGgWDU+8XIfwsCrDv7nVMS1cooy1BPW4oXb7Fc6aYF+llOLZsGFCXmrKg6De hVCt3G7vo+SyLUU5nghBgu/DWQZAVxIv/fKXJy+PB9kgIm0EyR9nFohfD2xRw7hdcAo5ot3Z WyDk0nrsALciYsV9MPOA4we7rGNoXze2O/DIuzGyWvKEhVAQOEl3bIiI9FkN1CPqZ4i6cPpA ==
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Mon, Apr 11, 2022 at 11:35:54AM +0200, Jan Beulich wrote:
> Prior extension of these functions to enable per-device quarantine page
> tables already didn't add more locking there, but merely left in place
> what had been there before. But really locking is unnecessary here:
> We're running with pcidevs_lock held (i.e. multiple invocations of the
> same function [or their teardown equivalents] are impossible, and hence
> there are no "local" races), while all consuming of the data being
> populated here can't race anyway due to happening sequentially
> afterwards. See also the comment in struct arch_pci_dev.
I would explicitly say that none of the code in the locked region
touches any data in the domain_iommu struct, so taking the
mapping_lock is unneeded.
Long term we might wish to implemented a per-device lock that could be
used here, instead of relying on the pcidevs lock.
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
Thanks, Roger.
|
