From: "Michael S. Tsirkin" <mst@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: qemu-devel@nongnu.org, eric.auger.pro@gmail.com,
eric.auger@redhat.com, clg@redhat.com, zhenzhong.duan@intel.com,
marcel.apfelbaum@gmail.com
Subject: Re: [PATCH 0/5] PCI: Implement basic PCI PM capability backing
Date: Thu, 20 Feb 2025 17:54:41 -0500 [thread overview]
Message-ID: <20250220175420-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20250220224918.2520417-1-alex.williamson@redhat.com>
On Thu, Feb 20, 2025 at 03:48:53PM -0700, Alex Williamson wrote:
> Eric recently identified an issue[1] where during graceful shutdown
> of a VM in a vIOMMU configuration, the guest driver places the device
> into the D3 power state, the vIOMMU is then disabled, triggering an
> AddressSpace update. The device BARs are still mapped into the AS,
> but the vfio host driver refuses to DMA map the MMIO space due to the
> device power state.
>
> The proposed solution in [1] was to skip mappings based on the
> device power state. Here we take a different approach. The PCI spec
> defines that devices in D1/2/3 power state should respond only to
> configuration and message requests and all other requests should be
> handled as an Unsupported Request. In other words, the memory and
> IO BARs are not accessible except when the device is in the D0 power
> state.
>
> To emulate this behavior, we can factor the device power state into
> the mapping state of the device BARs. Therefore the BAR is marked
> as unmapped if either the respective command register enable bit is
> clear or the device is not in the D0 power state.
>
> In order to implement this, the PowerState field of the PMCSR
> register becomes writable, which allows the device to appear in
> lower power states. This also therefore implements D3 support
> (insofar as the BAR behavior) for all devices implementing the PM
> capability. The PCI spec requires D3 support.
>
> An aspect that needs attention here is whether this change in the
> wmask and PMCSR bits becomes a problem for migration, and how we
> might solve it. For a guest migrating old->new, the device would
> always be in the D0 power state, but the register becomes writable.
> In the opposite direction, is it possible that a device could
> migrate in a low power state and be stuck there since the bits are
> read-only in old QEMU? Do we need an option for this behavior and a
> machine state bump, or are there alternatives?
>
> Thanks,
> Alex
>
> [1]https://lore.kernel.org/all/20250219175941.135390-1-eric.auger@redhat.com/
PCI bits:
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
feel free to merge.
> Alex Williamson (5):
> hw/pci: Basic support for PCI power management
> pci: Use PCI PM capability initializer
> vfio/pci: Delete local pm_cap
> pcie, virtio: Remove redundant pm_cap
> hw/vfio/pci: Re-order pre-reset
>
> hw/net/e1000e.c | 3 +-
> hw/net/eepro100.c | 4 +-
> hw/net/igb.c | 3 +-
> hw/nvme/ctrl.c | 3 +-
> hw/pci-bridge/pcie_pci_bridge.c | 3 +-
> hw/pci/pci.c | 83 ++++++++++++++++++++++++++++++++-
> hw/pci/trace-events | 2 +
> hw/vfio/pci.c | 29 ++++++------
> hw/vfio/pci.h | 1 -
> hw/virtio/virtio-pci.c | 11 ++---
> include/hw/pci/pci.h | 3 ++
> include/hw/pci/pci_device.h | 3 ++
> include/hw/pci/pcie.h | 2 -
> 13 files changed, 112 insertions(+), 38 deletions(-)
>
> --
> 2.48.1
next prev parent reply other threads:[~2025-02-20 22:55 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-20 22:48 [PATCH 0/5] PCI: Implement basic PCI PM capability backing Alex Williamson
2025-02-20 22:48 ` [PATCH 1/5] hw/pci: Basic support for PCI power management Alex Williamson
2025-02-24 19:03 ` Eric Auger
2025-02-25 5:24 ` Alex Williamson
2025-02-25 9:45 ` Eric Auger
2025-02-20 22:48 ` [PATCH 2/5] pci: Use PCI PM capability initializer Alex Williamson
2025-02-24 18:37 ` Eric Auger
2025-02-24 19:03 ` Alex Williamson
2025-02-20 22:48 ` [PATCH 3/5] vfio/pci: Delete local pm_cap Alex Williamson
2025-02-24 18:38 ` Eric Auger
2025-02-20 22:48 ` [PATCH 4/5] pcie, virtio: Remove redundant pm_cap Alex Williamson
2025-02-21 6:12 ` Duan, Zhenzhong
2025-02-22 6:00 ` Cédric Le Goater
2025-02-24 1:45 ` Duan, Zhenzhong
2025-02-24 18:40 ` Eric Auger
2025-02-20 22:48 ` [PATCH 5/5] hw/vfio/pci: Re-order pre-reset Alex Williamson
2025-02-24 20:16 ` Eric Auger
2025-02-20 22:54 ` Michael S. Tsirkin [this message]
2025-02-24 8:21 ` [PATCH 0/5] PCI: Implement basic PCI PM capability backing Cédric Le Goater
2025-02-24 1:43 ` Duan, Zhenzhong
2025-02-24 8:14 ` Cédric Le Goater
2025-02-24 15:09 ` Alex Williamson
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=20250220175420-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=clg@redhat.com \
--cc=eric.auger.pro@gmail.com \
--cc=eric.auger@redhat.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=zhenzhong.duan@intel.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;
as well as URLs for NNTP newsgroup(s).