From: Alex Williamson <alex@shazbot.org>
To: lirongqing <lirongqing@baidu.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>, Kevin Tian <kevin.tian@intel.com>,
Ankit Agrawal <ankita@nvidia.com>,
Leon Romanovsky <leon@kernel.org>,
Alistair Popple <apopple@nvidia.com>, <kvm@vger.kernel.org>,
<linux-kernel@vger.kernel.org>,
alex@shazbot.org
Subject: Re: [PATCH] vfio/pci: Allow disabling idle D3 on a per-device basis
Date: Wed, 22 Apr 2026 15:51:58 -0600 [thread overview]
Message-ID: <20260422155158.527a0765@shazbot.org> (raw)
In-Reply-To: <20260422081307.2550-1-lirongqing@baidu.com>
On Wed, 22 Apr 2026 04:13:07 -0400
lirongqing <lirongqing@baidu.com> wrote:
> From: Li RongQing <lirongqing@baidu.com>
>
> The disable_idle_d3 module parameter currently toggles idle D3 power
> management for all devices handled by vfio-pci. This is too coarse for
> environments where only specific devices (e.g., certain GPUs or NICs)
> have issues with D3 state transition.
>
> For example, some PCIe devices exhibit hardware bugs or firmware issues
> when entering or exiting D3 state. These devices may experience PCIe link
> speed degradation after transitioning out of D3, reducing from Gen4/Gen5
> to lower speeds, which can significantly impact I/O bandwidth. In such
> cases, only these problematic devices need to have idle D3 disabled,
> rather than all devices globally.
>
> Introduce a new module parameter 'disable_idle_d3_ids' to allow users to
> specify a list of vendor:device IDs that should have idle D3 disabled.
>
> To support this, add a 'disable_idle_d3' flag to struct
> vfio_pci_core_device. This flag is initialized during device probe
> based on both the global 'disable_idle_d3' parameter and the new
> 'disable_idle_d3_ids' list. All runtime PM decisions are then shifted
> to use this per-device flag.
>
> In vfio_pci_dev_set_try_reset(), update the logic to iterate through
> all devices in the dev_set and respect their individual D3 settings
> when performing a bus reset.PCI_DEV_FLAGS_NO_D3
There are device flags that can be set by quirks to handle this:
enum pci_dev_flags {
...
/* Device configuration is irrevocably lost if disabled into D3 */
PCI_DEV_FLAGS_NO_D3 = (__force pci_dev_flags_t) (1 << 1),
...
/* Do not use PM reset even if device advertises NoSoftRst- */
PCI_DEV_FLAGS_NO_PM_RESET = (__force pci_dev_flags_t) (1 << 7),
Ideally vfio-pci.disable_idle_d3 would be your debug tool for
evaluating issues with device level D3 support. If an incompatible
device is found, we should attempt to resolve issues, like link
re-training, or at least contribute a quirk for the device so that all
users benefit, not just those with a magic list of broken devices.
You also have the reset_method sysfs attribute at your disposal to
manage how we trigger a function scoped reset. Thanks,
Alex
prev parent reply other threads:[~2026-04-22 21:52 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-22 8:13 [PATCH] vfio/pci: Allow disabling idle D3 on a per-device basis lirongqing
2026-04-22 21:51 ` Alex Williamson [this message]
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=20260422155158.527a0765@shazbot.org \
--to=alex@shazbot.org \
--cc=ankita@nvidia.com \
--cc=apopple@nvidia.com \
--cc=jgg@ziepe.ca \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lirongqing@baidu.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox