All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tushar Dave <tdave@nvidia.com>
To: qemu-devel@nongnu.org
Cc: mst@redhat.com, philmd@oss.qualcomm.com, zhao1.liu@intel.com,
	yishaih@nvidia.com, alwilliamson@nvidia.com, jgg@nvidia.com,
	skolothumtho@nvidia.com
Subject: [PATCH v2 0/3] pcie/acs: configurable ACS capabilities for root and downstream ports
Date: Mon,  5 Oct 2026 20:31:30 -0500	[thread overview]
Message-ID: <20261006013133.3457555-1-tdave@nvidia.com> (raw)

This series adds an 'acs-ctrl' property to PCIe root ports and downstream
ports, letting the hypervisor expose a specific PCIe ACS (Access Control
Services) configuration to the guest instead of QEMU always advertising
every ACS capability the port structurally supports.

This matters for P2P (peer-to-peer) topologies such as GPUDirect RDMA,
where the actual ACS configuration in effect must match what the host
side is doing -- otherwise the guest sees a topology/configuration that
doesn't reflect reality, which is undefined behavior and can fail either
in software or in hardware.

Patch 1 adds the missing ACS capability to xio3130 downstream ports
(previously only root ports exposed one), gated behind a new
'x-pcie-acs' property so older machine types can disable it via
hw_compat and preserve migration compatibility.

Patch 2 introduces the 'acs-ctrl' property itself on both root and
downstream ports, so the configured value -- not just the maximal
capability set -- is what gets exposed to the guest.

Patch 3 makes the ACS Control register read-only to the guest once
'acs-ctrl' has been explicitly configured, so a guest OS doing normal
PCIe programming can't silently override the host-configured ACS
state. An explicitly configured value of 0 is treated the same as any
other configured value (locked), distinct from the property never
being set at all (which stays guest-writable, unchanged from current
behavior).

Changes in v2:
- Patch 1: Limit x-pcie-acs to the xio3130 downstream port
- Patch 2: Error out when acs-ctrl is set on a port without ACS, reword
  the commit message and the unsupported-bits error
- Patch 3: Make pcie_acs_init() safe for devices that are not PCIe
  ports, clarify the acs-ctrl property description

Link to v1: https://lore.kernel.org/qemu-devel/20260922215008.2554402-1-tdave@nvidia.com/

Tushar Dave (2):
  xio3130_downstream: Add ACS support for downstream PCIe ports
  hw/pci: Make ACS Control read-only to guests

Yishai Hadas (1):
  hw/pci: Expose ACS ctrl on Guest as configured by the hypervisor

 hw/core/machine.c                  |  1 +
 hw/pci-bridge/pcie_root_port.c     | 14 ++++++-
 hw/pci-bridge/xio3130_downstream.c | 19 ++++++++++
 hw/pci/pcie.c                      | 61 ++++++++++++++++++++++++++++--
 include/hw/pci/pci.h               |  3 ++
 include/hw/pci/pcie.h              |  8 +++-
 include/hw/pci/pcie_port.h         |  2 +
 7 files changed, 100 insertions(+), 8 deletions(-)

-- 
2.34.1



             reply	other threads:[~2026-10-06  1:37 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-06  1:31 Tushar Dave [this message]
2026-10-06  1:31 ` [PATCH v2 1/3] xio3130_downstream: Add ACS support for downstream PCIe ports Tushar Dave
2026-10-06  4:49   ` Michael S. Tsirkin
2026-10-07 17:42     ` Tushar Dave
2026-10-06  1:31 ` [PATCH v2 2/3] hw/pci: Expose ACS ctrl on Guest as configured by the hypervisor Tushar Dave
2026-10-06  4:45   ` Michael S. Tsirkin
2026-10-07 17:00     ` Tushar Dave
2026-10-06  1:31 ` [PATCH v2 3/3] hw/pci: Make ACS Control read-only to guests Tushar Dave
2026-10-06  4:44   ` Michael S. Tsirkin
2026-10-07 16:33     ` Tushar Dave
2026-10-07 22:27       ` Michael S. Tsirkin

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=20261006013133.3457555-1-tdave@nvidia.com \
    --to=tdave@nvidia.com \
    --cc=alwilliamson@nvidia.com \
    --cc=jgg@nvidia.com \
    --cc=mst@redhat.com \
    --cc=philmd@oss.qualcomm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=skolothumtho@nvidia.com \
    --cc=yishaih@nvidia.com \
    --cc=zhao1.liu@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.