[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Tue, 8 Feb 2022 11:11:14 +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=LI9VW8Pk5kJ7LXO2kwg/5AE5zwMQHkvZPn1RbdhVvFY=; b=gdb5Fzrf1tr0OW9Wv6BvMJVoL/DiU1hIo5tpkwLaKF0Oq6h28jkZk/VsxMs+ZtOibSTRYc+Nlx/U4vT+QydSRwYAgthc+eDUow+6cGHXIdfbRsuVoCea/OjugYIrT8NlwPbLvkEAQurtiAx5JTwxTBd+mKc0+4wH1E6AqLAy9uipuEv8/8M9qKADrmgdJvhstYNAVXhryhbybz1AsIW5YCOZA302z5nI5/6oUdCOdsyZao1aAwbc7ZqGl7hqarms7y/XsPOqNvjPEr/VUydzNZkivfLu7S7aKfaINredaQT1WxiBTq6NnnK8Zpi4FrMAfb1/jbF54Vi8gZIFSPDvTQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gaPNl2pG6u8vNF6wAf54tXfJIlTc4bUMqxBs2YLcCSlDUrxYzweDvbwkQrkCZNAm+clB7jYGsyCklNn8Fl/CQ4zG73DaNVqtRQBxeVmbCa6Q1dbyB/mOMyqAt17exF/Q/XNqgoceRuAdtt9EM3w8UAYHDBJgknJwSCuganpNhTX8CuSnz4T9bj5FlRm167IeYe2a38IbTq5zr5ZSiK8EDdBLUs2lBxD3q7n9933tX69UyigwxI9Cx1dPSaaJCHloxB+Dff5eQqXnTFSrcSuTJy5nvDm76t/01bY6iwaR7B3A0q3CE4w5jYeSC6ZZ0VnDt7hn1cHah3fQR0768VEEdA==
- Authentication-results: esa4.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
- Cc: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>, "julien@xxxxxxx" <julien@xxxxxxx>, "sstabellini@xxxxxxxxxx" <sstabellini@xxxxxxxxxx>, Oleksandr Tyshchenko <Oleksandr_Tyshchenko@xxxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Artem Mygaiev <Artem_Mygaiev@xxxxxxxx>, "andrew.cooper3@xxxxxxxxxx" <andrew.cooper3@xxxxxxxxxx>, "george.dunlap@xxxxxxxxxx" <george.dunlap@xxxxxxxxxx>, "paul@xxxxxxx" <paul@xxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Rahul Singh <rahul.singh@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Tue, 08 Feb 2022 10:11:27 +0000
- Ironport-data: A9a23:HdaBjq8Y9yk7ZznDHVURDrUDoHiTJUtcMsCJ2f8bNWPcYEJGY0x3n zYbCDzUPqncNjPxfNAjaYzn8R5X65XTnYNrQQA+pC48E34SpcT7XtnIdU2Y0wF+jyHgoOCLy +1EN7Es+ehtFie0Si9AttENlFEkvU2ybuOU5NXsZ2YhFWeIdA970Ug5w7Rh0tYx6TSEK1jlV e3a8pW31GCNg1aYAkpMg05UgEoy1BhakGpwUm0WPZinjneH/5UmJMt3yZWKB2n5WuFp8tuSH I4v+l0bElTxpH/BAvv9+lryn9ZjrrT6ZWBigVIOM0Sub4QrSoXfHc/XOdJFAXq7hQllkPgg4 Yl9mqatWTt4AaPyieo8XDBhPhxHaPguFL/veRBTsOSWxkzCNXDt3+9vHAc9OohwFuRfWD8Us 6ZCcXZUM07F17neLLGTE4GAguw5K8bmJsUHs2xIxjDFF/c2B5vERs0m4PcGgWZr3pkfRZ4yY eIeM2o0XBjhYydNFUYxEpYertaFhHrgJmgwRFW9+vNsvjm7IBZK+KDkLd79atGMA8JPkS6wj 3ja8mHOJwAVPd2S1xKI6nupwOTImEvTUo8ICKex8PIshVSJ33ESEzUfT179qv684mauVtQaJ 0EK9y4Gqakp6FftXtT7Rwe/onOPolgbQdU4O/cz6ByJjLHV5QmZLmEeS3hKb9lOnPExQTsmx 1qYheTDDDZksKCWYX+F/7LSpjS3UQAyKWIBfiYCQREyyt/vupwojhnPQ9BgF4a4ltTwXzr3x liiriIzmrEShs4jzLig8BbMhDfEjprUSg844C3HU2Tj6Rl2DKaCY4Gr8lHd4ex3EJeCTlKBs X4HnOCT9OkLS5qKkUSlW/4RFbuk4/KENjz0glN1GZQlsTO39BaekZt4uW8kYh0za4BdJGGvM BS7VR5tCIF7bVL2XYBNfpKNWvsk87nuNNvMb93pV48bCnRuTzOv8CZrbE+W+mnilkkwjK0yU aumndaQ4WUyUvo+kmfvLwsJ+fpyn31lmzuPLXzu50n/idKjiGippaDp2bdkRsQw9+u6rQrc6 L6z3OPamkwEAIUSjsQ6mLP/zGzmz1BmX/gaSOQNL4ZvxzaK/0l7WpfsLUsJIdANokisvr6gE ouBckFZ0kHjonbMNB+HbHtuAJu2A8oj9CNiZHJ9Zw/zs5TGXWpIxP1OH6bbgJF9rLAzpRKKZ 6Vtlzq87gRnFW2cpmV1gWjVp41+bhW77T9izAL+CAXTi6VIHlSTkve9J1OH3HBXUkKf6Jtvy 5X9h1izacdSGGxKUp2MANrxlAzZgJTosL8rN6c+CoIIIxuEHUkDA3GZs8Lb1OlWcUqanWbBh 1/NafrazMGUy7IIHBDyrfnsh6+iEvdkH1ocGG/e7L2sMjLd8HblyohFONtktxiEPI8t0Kn9N +hT0d/mN/gLwARDv4ZmSu45xqMi/dr/4bRdy108TnnMal2qDJJmI2WHgpYT5vEcmOcBtFvkQ F+L9/lbJa6NZJHvHmkOKVd3de+Ez/wVxGXftKxnPEXg6SZr17ObSkEObQKUgSlQIeItYoMoy OssouAM7Am7hkZ4O9qKlHkMpW+NMmYBQ+MssZRDWN3njQ8iy1djZ53AC3CpvMHTOosUakRze 22anqvPgbhY13HuSXtrGCifx/dZiLQPpAtOkA0IKWOWl4eXnfQwxhBQr2g6F1wH0hVd3utvE WF3LEkpd76W9jJlicUfDWChHwZNWE+Q9kDrkgZbkWTYSw+jV3DXLX17MuGIpRhL/2VZdzld3 beZ1Ge6Dmq6IJCvhnM/CRx/tvjubd1t7QmTysmoEvOME4Q+fTe40LSlYnAFqke/DM487KEdS TKGIAqkhXXHCBMt
- Ironport-hdrordr: A9a23:4n4uMK+yiHC30URk5d9uk+FAdb1zdoMgy1knxilNoENuHfBwxv rDoB1E73LJYVYqOU3Jmbi7Sc69qFfnhORICO4qTMqftWjdyRCVxeRZg7cKrAeQeREWmtQtsJ uINpIOdOEYbmIK/PoSgjPIaurIqePvmMvD5Za8854ud3ATV0gJ1XYGNu/xKDwReOApP+tcKH LKjfA32AZINE5nJfiTNz0gZazuttfLnJXpbVovAAMm0hCHiXeN5KThGxaV8x8CW3cXqI1SvF Ttokjc3OGOovu7whjT2yv66IlXosLozp9mCNaXgsYYBz3wgkKDZZhnWZeFoDcpydvfomoCoZ 3pmVMNLs5z43TeciWcpgbs4RDp1HIU53rr2Taj8A3eiP28YAh/J9tKhIpffBecwVEnpstA3K VC2H/cn4ZLDDvb9R6NqeTgZlVPrA6ZsHAimekcgzh0So0FcoJcqoQZ4Qd8DIoAJiTn84oqed MeQ/003MwmMW9yUkqp/VWGmLeXLzYO91a9MwQ/U/WuonlrdCsT9Tpc+CQd9k1wg67VBaM0o9 gsCZ4Y542mePVmGZ6VNN1xMfdfNVa9My4kEFjiaGgPR5t3c04klfbMkcAIDaeRCds18Kc=
- Ironport-sdr: pII45nKWVQwacj6Oprq5sU/Q0LsmTMQxRtCIuhj9BcwcGgnpWivAH2fZ1+rybeW0JRqp7vvRa9 aomSOWRBjz6h5EM+AEhrsDs91cpSFyUE8EiKI3rXQv3H86Dqu9jZhFv7swe4eafN7NpisSjof/ qBkwolm8UStAPloKzvHyvVpI+ukLrC0skXZMBMP+ckdwmpl5r3NeRvYVcBwSQapMlVbmlJ6Slh Llq0Ccq7bjVp7CLBPGdyRqlV057hjmDXsizADRhGETsqNyBfGuDa4/Q3kyk2Koi6WuNd+9OrhP 1ti5Qu1k+nVKgYqj3QDAJFIP
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Mon, Feb 07, 2022 at 05:37:49PM +0100, Jan Beulich wrote:
> On 07.02.2022 17:21, Oleksandr Andrushchenko wrote:
> >
> >
> > On 07.02.22 18:15, Jan Beulich wrote:
> >> On 07.02.2022 17:07, Oleksandr Andrushchenko wrote:
> >>> On 07.02.22 17:26, Jan Beulich wrote:
> >>>> 1b. Make vpci_write use write lock for writes to command register and
> >>>> BARs
> >>>> only; keep using the read lock for all other writes.
> >>> I am not quite sure how to do that. Do you mean something like:
> >>> void vpci_write(pci_sbdf_t sbdf, unsigned int reg, unsigned int size,
> >>> uint32_t data)
> >>> [snip]
> >>> list_for_each_entry ( r, &pdev->vpci->handlers, node )
> >>> {
> >>> [snip]
> >>> if ( r->needs_write_lock)
> >>> write_lock(d->vpci_lock)
> >>> else
> >>> read_lock(d->vpci_lock)
> >>> ....
> >>>
> >>> And provide rw as an argument to:
> >>>
> >>> int vpci_add_register(struct vpci *vpci, vpci_read_t *read_handler,
> >>> vpci_write_t *write_handler, unsigned int offset,
> >>> unsigned int size, void *data, --->>> bool
> >>> write_path <<<-----)
> >>>
> >>> Is this what you mean?
> >> This sounds overly complicated. You can derive locally in vpci_write(),
> >> from just its "reg" and "size" parameters, whether the lock needs taking
> >> in write mode.
> > Yes, I started writing a reply with that. So, the summary (ROM
> > position depends on header type):
> > if ( (reg == PCI_COMMAND) || (reg == ROM) )
> > {
> > read PCI_COMMAND and see if memory or IO decoding are enabled.
> > if ( enabled )
> > write_lock(d->vpci_lock)
> > else
> > read_lock(d->vpci_lock)
> > }
>
> Hmm, yes, you can actually get away without using "size", since both
> command register and ROM BAR are 32-bit aligned registers, and 64-bit
> accesses get split in vpci_ecam_write().
>
> For the command register the memory- / IO-decoding-enabled check may
> end up a little more complicated, as the value to be written also
> matters. Maybe read the command register only for the ROM BAR write,
> using the write lock uniformly for all command register writes?
>
> > Do you also think we can drop pdev->vpci (or currently pdev->vpci->lock)
> > at all then?
>
> I haven't looked at this in any detail, sorry. It sounds possible,
> yes.
AFAICT you should avoid taking the per-device vpci lock when you take
the per-domain lock in write mode. Otherwise you still need the
per-device vpci lock in order to keep consistency between concurrent
accesses to the device registers.
Thanks, Roger.
|