qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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



  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).