Re: [PATCH v2 5/5] vfio/pci: Latch all module parameters per device

[Alex Williamson <alex.williamson@nvidia.com>]

On Fri, 12 Jun 2026 14:25:16 +0800
Guixin Liu <kanie@linux.alibaba.com> wrote:

> Hi Alex,
> 
> In many cases, when users modify a module parameter, they expect
> the change to take effect immediately, but that's not at all what
> happens here. So I think on the one hand, we should make the module
> parameter read-only; on the other hand, we could also expose this
> information in the PCI core device's sysfs directory — read-only as well 
> for now,
> or perhaps there's an even better approach?

nointxmask never took effect immediately, it was at best setup when the
device is opened.  We could support that behavior again, but it's
actually more limiting, all devices supporting INTx would latch
nointxmask on open and therefore require an exclusive interrupt.  I've
encountered this in debugging, where it's more useful to isolate
nointxmask to a single device rather than modify the VM config to
remove devices or unload host drivers to free IRQ lines.

disable_idle_d3 manages the power state of unused devices, where
setting disable_idle_d3 never woke devices that were already bound and
idle, it only affected future use of low power states.  I do still see
value in directing this behavior to specific devices, it's a runtime
diagnostic versus directing users to set quirk flags and recompile
their kernel.

Therefore, neither of these are really improved by making the module
parameter itself read-only.

Given these are largely diagnostic, debugfs would be the more natural
way to expose it versus sysfs.  We already have some support for
debugfs for exposing migration features and state.  This might be a
good idea, but I'd also argue it's more of a feature scope, whereas I'd
really like to get the Fixes: and behavior restoration scoped change in
tree asap.  Thanks,

Alex