Re: [PATCH v5 7/9] vfio/pci: Clean up BAR zap and revocation
Matt Evans <[email protected]> Thu, 30 Jul 2026 15:47:13 +0100
| Newsgroups | org.kernel.vger.linux-pci,org.freedesktop.lists.dri-devel,org.kernel.vger.kvm,org.kernel.vger.linux-kernel,org.kernel.vger.linux-media |
|---|---|
| Message-ID | <[email protected]> |
Hi Alex, On 29/07/2026 18:52, Alex Williamson wrote: > On Wed, 15 Jul 2026 18:47:30 +0100 > Matt Evans <[email protected]> wrote: >> diff --git a/include/linux/vfio_pci_core.h b/include/linux/vfio_pci_core.h >> index 9a1674c152aa..e2b4252e7c3f 100644 >> --- a/include/linux/vfio_pci_core.h >> +++ b/include/linux/vfio_pci_core.h >> @@ -134,6 +134,7 @@ struct vfio_pci_core_device { >> bool pm_intx_masked; >> bool pm_runtime_engaged; >> bool sriov_active; >> + bool zap_bars_on_revoke; >> struct pci_saved_state *pci_saved_state; >> struct pci_saved_state *pm_save; >> int ioeventfds_nr; > > This should be in the bitfield usage group since it's only modified at > init time. This was intentional, but happy to change it if you're certain ofc. Is it inconceivable that a sub-driver could set it after init? I'd say they _shouldn't_, but only review will stop them and this placement intended to be cautious. It seemed a low cost way to avoid issues around synchronisation on the bitfield. Thanks, Matt