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

Re: [PATCH 3/6] x86/vPCI: tighten locking assertions



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@xxxxxxxx>

Acked-by: Roger Pau Monné <roger@xxxxxxxxxxxxxx>

> ---
> 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.



 


Rackspace

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