Archive-only list for patches
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: iommu@lists.linux.dev,
	Jean-Philippe Brucker <jean-philippe@linaro.org>,
	Joerg Roedel <joro@8bytes.org>,
	virtualization@lists.linux.dev, Will Deacon <will@kernel.org>,
	Eric Auger <eric.auger@redhat.com>,
	patches@lists.linux.dev, Alyssa Rosenzweig <alyssa@rosenzweig.io>,
	Sven Peter <sven@svenpeter.dev>, Janne Grunau <j@jannau.net>
Subject: Re: [PATCH 2/5] iommu: Add domain_alloc_identity()
Date: Wed, 12 Feb 2025 14:16:54 +0000	[thread overview]
Message-ID: <021d006e-1fe3-4f58-8e79-b5e316de347f@arm.com> (raw)
In-Reply-To: <20250212140316.GA3844591@nvidia.com>

On 2025-02-12 2:03 pm, Jason Gunthorpe wrote:
> On Wed, Feb 12, 2025 at 01:56:55PM +0000, Robin Murphy wrote:
>> On 2025-02-07 2:46 pm, Jason Gunthorpe wrote:
>>> virtio-iommu has a mode where the IDENTITY domain is actually a paging
>>> domain with an identity mapping covering some of the system address
>>> space manually created.
>>>
>>> To support this add a new domain_alloc_identity() op that accepts
>>> the struct device so that virtio can allocate and fully finalize a
>>> paging domain to return.
>>
>> Oh, I'd already managed to forget this idea - this could be convenient for
>> DART to implement per-instance identity domain support as well.
> 
> If we are going to broaden this someday then I suggest the core code should
> implement it entirely buy asking the driver for a paging domain and
> then mapping all of system memory into it. There is nothing special
> here that needs to be in driver code.

Sorry, that was just in terms of having a domain_alloc_identity() op 
that's allowed to fail, being potentially neater than otherwise having 
to register distinct per-instance ops with and without the static 
identity_domain. I'm inclined to agree that if anyone really is 
desperate for identity-mapped paging domains in the absence of true 
identity support, then indeed we probably should handle that in core 
code much like we do for improvised blocking domains.

Thanks,
Robin.

  reply	other threads:[~2025-02-12 14:16 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-07 14:46 [PATCH 0/5] Convert virtio-iommu to domain_alloc_paging() Jason Gunthorpe
2025-02-07 14:46 ` [PATCH 1/5] iommu/virtio: Break out bypass identity support into a global static Jason Gunthorpe
2025-02-12  0:43   ` Jacob Pan
2025-02-18 18:21     ` Jason Gunthorpe
2025-02-21 11:35   ` Jean-Philippe Brucker
2025-02-24 19:37     ` Jason Gunthorpe
2025-02-07 14:46 ` [PATCH 2/5] iommu: Add domain_alloc_identity() Jason Gunthorpe
2025-02-12 13:56   ` Robin Murphy
2025-02-12 14:03     ` Jason Gunthorpe
2025-02-12 14:16       ` Robin Murphy [this message]
2025-02-12 14:45         ` Jason Gunthorpe
2025-02-07 14:46 ` [PATCH 3/5] iommu/virtio: Move to domain_alloc_paging() Jason Gunthorpe
2025-02-12 19:22   ` Jacob Pan
2025-02-12 23:30     ` Jason Gunthorpe
2025-02-13  5:47       ` Jacob Pan
2025-02-18 20:01         ` Jason Gunthorpe
     [not found]       ` <67ad876d.170a0220.3c21dc.85ceSMTPIN_ADDED_BROKEN@mx.google.com>
2025-02-13  9:46         ` Jean-Philippe Brucker
2025-02-13 17:03           ` Yu Zhang
2025-02-13 18:09             ` Jean-Philippe Brucker
2025-02-19  9:39               ` Yu Zhang
2025-02-19 10:35                 ` Jean-Philippe Brucker
2025-02-19 11:11                   ` Yu Zhang
2025-02-19 11:57                     ` Jean-Philippe Brucker
2025-02-19 13:10                   ` Yi Liu
2025-02-20  2:58                   ` Baolu Lu
2025-02-20  3:44                     ` Yu Zhang
2025-02-07 14:46 ` [PATCH 4/5] iommu: Do not call domain_alloc() in iommu_sva_domain_alloc() Jason Gunthorpe
2025-02-07 14:46 ` [PATCH 5/5] iommu: Hide ops.domain_alloc behind CONFIG_FSL_PAMU Jason Gunthorpe
2025-02-12  0:41 ` [PATCH 0/5] Convert virtio-iommu to domain_alloc_paging() Jacob Pan
2025-02-12 12:50   ` Jason Gunthorpe
2025-02-12 18:50     ` Jacob Pan
2025-02-12 20:10       ` Robin Murphy
2025-02-21 11:42     ` Jean-Philippe Brucker
2025-02-24 19:39       ` Jason Gunthorpe
     [not found] ` <67abee53.170a0220.154671.ae28SMTPIN_ADDED_BROKEN@mx.google.com>
2025-02-12 11:58   ` Jean-Philippe Brucker
2025-02-12 17:05     ` Jacob Pan
     [not found]     ` <67acd4e2.630a0220.365aab.e098SMTPIN_ADDED_BROKEN@mx.google.com>
2025-02-12 19:16       ` Jean-Philippe Brucker

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=021d006e-1fe3-4f58-8e79-b5e316de347f@arm.com \
    --to=robin.murphy@arm.com \
    --cc=alyssa@rosenzweig.io \
    --cc=eric.auger@redhat.com \
    --cc=iommu@lists.linux.dev \
    --cc=j@jannau.net \
    --cc=jean-philippe@linaro.org \
    --cc=jgg@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=patches@lists.linux.dev \
    --cc=sven@svenpeter.dev \
    --cc=virtualization@lists.linux.dev \
    --cc=will@kernel.org \
    /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