From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Stewart Hildebrand <stewart.hildebrand@amd.com>,
xen-devel@lists.xenproject.org,
Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>,
Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
George Dunlap <george.dunlap@citrix.com>,
Julien Grall <julien@xen.org>,
Stefano Stabellini <sstabellini@kernel.org>,
Jun Nakajima <jun.nakajima@intel.com>,
Kevin Tian <kevin.tian@intel.com>, Paul Durrant <paul@xen.org>,
Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Subject: Re: [PATCH v13 01/14] vpci: use per-domain PCI lock to protect vpci structure
Date: Tue, 13 Feb 2024 10:01:56 +0100 [thread overview]
Message-ID: <ZcswBFHtINB1XMAS@macbook> (raw)
In-Reply-To: <ec5d0c39-1559-4f10-9574-98cfa0542993@suse.com>
On Tue, Feb 13, 2024 at 09:44:58AM +0100, Jan Beulich wrote:
> On 13.02.2024 09:35, Roger Pau Monné wrote:
> > On Fri, Feb 02, 2024 at 04:33:05PM -0500, Stewart Hildebrand wrote:
> >> --- a/xen/include/xen/sched.h
> >> +++ b/xen/include/xen/sched.h
> >> @@ -462,7 +462,8 @@ struct domain
> >> #ifdef CONFIG_HAS_PCI
> >> struct list_head pdev_list;
> >> /*
> >> - * pci_lock protects access to pdev_list.
> >> + * pci_lock protects access to pdev_list. pci_lock also protects pdev->vpci
> >> + * structure from being removed.
> >> *
> >> * Any user *reading* from pdev_list, or from devices stored in pdev_list,
> >> * should hold either pcidevs_lock() or pci_lock in read mode. Optionally,
> >> @@ -628,6 +629,18 @@ struct domain
> >> unsigned int cdf;
> >> };
> >>
> >> +/*
> >> + * Check for use in ASSERTs to ensure that:
> >> + * 1. we can *read* d->pdev_list
> >> + * 2. pdevs (belonging to this domain) do not go away
> >> + * 3. pdevs (belonging to this domain) do not get assigned to other domains
> >
> > I think you can just state that this check ensures there will be no
> > changes to the entries in d->pdev_list, but not the contents of each
> > entry. No changes to d->pdev_list already ensures not devices can be
> > deassigned or removed from the system, and obviously makes the list
> > safe to iterate against.
> >
> > I would also drop the explicitly mention this is intended for ASSERT
> > usage: there's nothing specific in the code that prevents it from
> > being used in other places (albeit I think that's unlikely).
>
> But pcidevs_locked(), resolving to spin_is_locked(), isn't reliable. The
> assertion usage is best-effort only, without a guarantee that all wrong
> uses would be caught.
Do we want to protect this with !NDEBUG guards then?
> >> + * This check is not suitable for protecting other state or critical regions.
> >> + */
> >> +#define pdev_list_is_read_locked(d) ({ \
> >
> > I would be tempted to drop at least the '_read_' part from the name,
> > the name is getting a bit too long for my taste.
>
> While I agree with the long-ish aspect, I'm afraid the "read" part is
> crucial. As a result I see no room for shortening.
OK, if you think that's crucial then I'm not going to argue.
> >> + struct domain *d_ = (d); \
> >
> > Why do you need this local domain variable? Can't you use the d
> > parameter directly?
>
> It would be evaluated then somewhere between 0 and 2 times.
It's ASSERT code only, so I don't see that as an issue. Otherwise d_
needs to be made const.
Thanks, Roger.
next prev parent reply other threads:[~2024-02-13 9:02 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-02 21:33 [PATCH v13 00/14] PCI devices passthrough on Arm, part 3 Stewart Hildebrand
2024-02-02 21:33 ` [PATCH v13 01/14] vpci: use per-domain PCI lock to protect vpci structure Stewart Hildebrand
2024-02-06 15:43 ` Stewart Hildebrand
2024-02-13 8:35 ` Roger Pau Monné
2024-02-13 8:44 ` Jan Beulich
2024-02-13 9:01 ` Roger Pau Monné [this message]
2024-02-13 9:05 ` Jan Beulich
2024-02-13 16:58 ` Stewart Hildebrand
2024-02-14 9:07 ` Jan Beulich
2024-02-13 16:57 ` Stewart Hildebrand
2024-02-14 11:38 ` Jan Beulich
2024-02-15 5:26 ` Stewart Hildebrand
2024-02-15 20:30 ` [PATCH v13.1 " Stewart Hildebrand
2024-02-16 11:44 ` Roger Pau Monné
2024-02-16 14:41 ` Stewart Hildebrand
2024-02-19 8:46 ` Roger Pau Monné
2024-02-19 11:47 ` [PATCH v13.2 " Stewart Hildebrand
2024-02-19 12:10 ` Jan Beulich
2024-02-19 12:47 ` Stewart Hildebrand
2024-02-19 13:12 ` Jan Beulich
2024-02-19 14:14 ` Stewart Hildebrand
2024-02-21 2:45 ` [PATCH v13.3 " Stewart Hildebrand
2024-02-26 14:47 ` Jan Beulich
2024-02-27 11:08 ` Roger Pau Monné
2024-02-27 11:06 ` Roger Pau Monné
2024-02-02 21:33 ` [PATCH v13 02/14] vpci: restrict unhandled read/write operations for guests Stewart Hildebrand
2024-02-02 21:33 ` [PATCH v13 03/14] vpci: add hooks for PCI device assign/de-assign Stewart Hildebrand
2024-02-02 21:33 ` [PATCH v13 04/14] vpci/header: rework exit path in init_header() Stewart Hildebrand
2024-02-02 21:33 ` [PATCH v13 05/14] vpci/header: implement guest BAR register handlers Stewart Hildebrand
2024-02-02 21:33 ` [PATCH v13 06/14] rangeset: add RANGESETF_no_print flag Stewart Hildebrand
2024-02-02 21:33 ` [PATCH v13 07/14] rangeset: add rangeset_purge() function Stewart Hildebrand
2024-02-02 21:33 ` [PATCH v13 08/14] vpci/header: handle p2m range sets per BAR Stewart Hildebrand
2024-02-02 21:33 ` [PATCH v13 09/14] vpci/header: program p2m with guest BAR view Stewart Hildebrand
2024-02-02 21:33 ` [PATCH v13 10/14] vpci/header: emulate PCI_COMMAND register for guests Stewart Hildebrand
2024-02-14 15:41 ` Jan Beulich
2024-03-18 21:03 ` Stewart Hildebrand
2024-03-19 8:21 ` Jan Beulich
2024-02-02 21:33 ` [PATCH v13 11/14] vpci: add initial support for virtual PCI bus topology Stewart Hildebrand
2024-02-02 21:33 ` [PATCH v13 12/14] xen/arm: translate virtual PCI bus topology for guests Stewart Hildebrand
2024-02-02 21:33 ` [PATCH v13 13/14] xen/arm: account IO handlers for emulated PCI MSI-X Stewart Hildebrand
2024-02-02 21:33 ` [PATCH v13 14/14] arm/vpci: honor access size when returning an error Stewart Hildebrand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZcswBFHtINB1XMAS@macbook \
--to=roger.pau@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=george.dunlap@citrix.com \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=jun.nakajima@intel.com \
--cc=kevin.tian@intel.com \
--cc=oleksandr_andrushchenko@epam.com \
--cc=paul@xen.org \
--cc=sstabellini@kernel.org \
--cc=stewart.hildebrand@amd.com \
--cc=volodymyr_babchuk@epam.com \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.