On Thu, 30 Jul 2026 15:47:13 +0100 Matt Evans matt@ozlabs.org wrote:
Hi Alex,
On 29/07/2026 18:52, Alex Williamson wrote:
On Wed, 15 Jul 2026 18:47:30 +0100 Matt Evans matt@ozlabs.org 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.
I'd agree with the statement that they shouldn't, it would be difficult to synchronize setting the flag once there are any active mappings of the BARs. Also, if we put it in the bitfield category under the comment that the value is only modified at setup/release, it documents the intentions, hopefully to the extent the author or reviewers notice. An argument can always be made to change it if there's a worthwhile use case. Thanks,
Alex