From: "Roger Pau Monné" <roger@xenproject.org>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Teddy Astie <teddy.astie@vates.tech>
Subject: Re: [PATCH 3/6] x86/vPCI: tighten locking assertions
Date: Thu, 24 Sep 2026 11:02:19 +0200 [thread overview]
Message-ID: <arTnGy24-o79NapH@macbook.local> (raw)
In-Reply-To: <1b8c4276-0031-4a19-9663-b63799f5cf81@suse.com>
On Tue, Sep 08, 2026 at 03:02:19PM +0200, Jan Beulich wrote:
> Already when they were introduced, they seemed overly lax. In particular
> anything invoked solely from vpci_{read,write}() can check that the per-
> domain PCI r/w lock is held. There's no need to permit the alternative of
> holding the global PCI devices lock.
I think this was (mostly?) done so that the macro could beused
generically without having to think whether the context is locked by
the pcidev_lock or the domain lock (or possibly both).
> vpci_msi_arch_update()'s sole call site is update_msi(), which in turn is
> solely called from write handling hooks.
>
> vpci_msi_update(), besides being called from vpci_msi_arch_update() (see
> above), has two further call sites:
> - vpci_msi_arch_enable(), called upon control register writes,
> - vpci_msix_arch_enable_entry(), called solely from update_entry(), which
> in turn is again called upon control register writes, plus from
> msix_write(), which read-locks the domain's PCI lock.
> Both arch_enable functions therefore can also have their assertions
> adjusted.
>
> vpci_msi_disable() is called from
> - vpci_msi_arch_disable(), called upon control register writes,
> - vpci_msix_arch_enable_entry(), covered above,
> - vpci_msix_arch_disable_entry(), called update_entry() (see above) and
> upon control register writes.
I was under the impression that the long term plan was to drop the
pcidevs_lock side of ASSERT_PDEV_LIST_IS_READ_LOCKED(), and convert
that assert to check exclusively for the per-domain pci_lock.
However doing it would require assessing (and possibly adjusting) of
all users, which is unlikely to happen.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger@xenproject.org>
> ---
> With this perhaps the comment near the top of vpci_msix_arch_print() might
> better go away. Thoughts?
I would remove it now - previously it was the outlier and hence
deserved a comment, that's not the case after your change.
Thanks, Roger.
next prev parent reply other threads:[~2026-09-24 9:02 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-08 13:00 [PATCH 0/6] x86: pass-through / {,v}PCI locking Jan Beulich
2026-09-08 13:01 ` [PATCH 1/6] x86/pass-through: defer event unlock in pt_irq_create_bind() Jan Beulich
2026-09-22 13:37 ` Roger Pau Monné
2026-09-22 14:59 ` Jan Beulich
2026-09-08 13:01 ` [PATCH 2/6] x86/pass-through: no locking around pt_irq_{create,destroy}_bind() Jan Beulich
2026-09-23 10:37 ` Roger Pau Monné
2026-09-24 9:57 ` Jan Beulich
2026-09-25 14:53 ` Roger Pau Monné
2026-09-28 12:50 ` Jan Beulich
2026-09-29 9:31 ` Roger Pau Monné
2026-09-08 13:02 ` [PATCH 3/6] x86/vPCI: tighten locking assertions Jan Beulich
2026-09-24 9:02 ` Roger Pau Monné [this message]
2026-09-08 13:03 ` [PATCH 4/6] vPCI: drop bogus locking assertion Jan Beulich
2026-09-24 9:28 ` Roger Pau Monné
2026-09-08 13:03 ` [PATCH 5/6] x86/pass-through: use simpler locking primitives in pt_irq_{create,destroy}_bind() Jan Beulich
2026-09-25 16:14 ` Roger Pau Monné
2026-09-08 13:04 ` [PATCH 6/6] x86/HVM: drop vector parameter from .pi_update_irte() hook Jan Beulich
2026-09-25 16:15 ` Roger Pau Monné
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=arTnGy24-o79NapH@macbook.local \
--to=roger@xenproject.org \
--cc=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.com \
--cc=teddy.astie@vates.tech \
--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.