All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Vidya Sagar <vidyas@nvidia.com>,
	"bhelgaas@google.com" <bhelgaas@google.com>
Cc: corbet@lwn.net, bhelgaas@google.com, galshalom@nvidia.com,
	leonro@nvidia.com, treding@nvidia.com, jonathanh@nvidia.com,
	mmoshrefjava@nvidia.com, shahafs@nvidia.com, vsethi@nvidia.com,
	sdonthineni@nvidia.com, jan@nvidia.com, tdave@nvidia.com,
	linux-doc@vger.kernel.org, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, kthota@nvidia.com,
	mmaddireddy@nvidia.com, sagar.tv@gmail.com
Subject: Re: [PATCH V4] PCI: Extend ACS configurability
Date: Mon, 8 Jul 2024 11:39:15 -0300	[thread overview]
Message-ID: <20240708143915.GF14004@nvidia.com> (raw)
In-Reply-To: <20240625153150.159310-1-vidyas@nvidia.com>

On Tue, Jun 25, 2024 at 09:01:50PM +0530, Vidya Sagar wrote:
> PCIe ACS settings control the level of isolation and the possible P2P
> paths between devices. With greater isolation the kernel will create
> smaller iommu_groups and with less isolation there is more HW that
> can achieve P2P transfers. From a virtualization perspective all
> devices in the same iommu_group must be assigned to the same VM as
> they lack security isolation.
> 
> There is no way for the kernel to automatically know the correct
> ACS settings for any given system and workload. Existing command line
> options (ex:- disable_acs_redir) allow only for large scale change,
> disabling all isolation, but this is not sufficient for more complex cases.
> 
> Add a kernel command-line option 'config_acs' to directly control all the
> ACS bits for specific devices, which allows the operator to setup the
> right level of isolation to achieve the desired P2P configuration.
> The definition is future proof, when new ACS bits are added to the spec
> the open syntax can be extended.
> 
> ACS needs to be setup early in the kernel boot as the ACS settings
> effect how iommu_groups are formed. iommu_group formation is a one
> time event during initial device discovery, changing ACS bits after
> kernel boot can result in an inaccurate view of the iommu_groups
> compared to the current isolation configuration.
> 
> ACS applies to PCIe Downstream Ports and multi-function devices.
> The default ACS settings are strict and deny any direct traffic
> between two functions. This results in the smallest iommu_group the
> HW can support. Frequently these values result in slow or
> non-working P2PDMA.
> 
> ACS offers a range of security choices controlling how traffic is
> allowed to go directly between two devices. Some popular choices:
>   - Full prevention
>   - Translated requests can be direct, with various options
>   - Asymmetric direct traffic, A can reach B but not the reverse
>   - All traffic can be direct
> Along with some other less common ones for special topologies.
> 
> The intention is that this option would be used with expert knowledge
> of the HW capability and workload to achieve the desired
> configuration.
> 
> Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
> ---
> v4:
> * Changed commit message (Courtesy: Jason) to provide more details
> 
> v3:
> * Fixed a documentation issue reported by kernel test bot
> 
> v2:
> * Refactored the code as per Jason's suggestion
> 
>  .../admin-guide/kernel-parameters.txt         |  22 +++
>  drivers/pci/pci.c                             | 148 +++++++++++-------
>  2 files changed, 112 insertions(+), 58 deletions(-)

Bjorn?

Jason

  parent reply	other threads:[~2024-07-08 14:39 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-21 11:09 [PATCH V2] PCI: Extend ACS configurability Vidya Sagar
2024-05-21 15:44 ` kernel test robot
2024-05-23  6:35 ` [PATCH V3] " Vidya Sagar
2024-05-23 14:59   ` Bjorn Helgaas
2024-05-23 15:16     ` Jason Gunthorpe
2024-06-03  7:50       ` Vidya Sagar
2024-06-07 19:30         ` Bjorn Helgaas
2024-06-10 11:38           ` Jason Gunthorpe
2024-06-12 21:29             ` Bjorn Helgaas
2024-06-12 23:23               ` Jason Gunthorpe
2024-06-13 22:05                 ` Bjorn Helgaas
2024-06-13 23:36                   ` Jason Gunthorpe
2024-06-13 22:38                 ` Alex Williamson
2024-06-12 12:19   ` Jason Gunthorpe
2024-06-25 15:31   ` [PATCH V4] " Vidya Sagar
2024-06-25 16:26     ` Lukas Wunner
2024-06-25 16:39       ` Jason Gunthorpe
2024-06-26  6:02       ` Leon Romanovsky
2024-06-26  7:40     ` Tian, Kevin
2024-06-26 11:50       ` Jason Gunthorpe
2024-07-08 14:39     ` Jason Gunthorpe [this message]
2024-07-12 21:57     ` Bjorn Helgaas
2024-09-25  5:06     ` Jiri Slaby
2024-09-25  5:29       ` Jiri Slaby
2024-09-25  5:49         ` Jiri Slaby
2024-10-01 19:33           ` Jason Gunthorpe
2024-10-07 16:36             ` Steffen Dirkwinkel
2024-10-07 20:43       ` Bjorn Helgaas

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=20240708143915.GF14004@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=bhelgaas@google.com \
    --cc=corbet@lwn.net \
    --cc=galshalom@nvidia.com \
    --cc=jan@nvidia.com \
    --cc=jonathanh@nvidia.com \
    --cc=kthota@nvidia.com \
    --cc=leonro@nvidia.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mmaddireddy@nvidia.com \
    --cc=mmoshrefjava@nvidia.com \
    --cc=sagar.tv@gmail.com \
    --cc=sdonthineni@nvidia.com \
    --cc=shahafs@nvidia.com \
    --cc=tdave@nvidia.com \
    --cc=treding@nvidia.com \
    --cc=vidyas@nvidia.com \
    --cc=vsethi@nvidia.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.