mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Michael Shavit <mshavit@google.com>
Cc: iommu@lists.linux.dev, Jason Gunthorpe <jgg@ziepe.ca>,
	Jean-Philippe Brucker <jean-philippe@linaro.org>,
	Joerg Roedel <joro@8bytes.org>,
	Lu Baolu <baolu.lu@linux.intel.com>,
	Nicolin Chen <nicolinc@nvidia.com>,
	Tomas Krcka <krckatom@amazon.de>, Will Deacon <will@kernel.org>,
	Yicong Yang <yangyicong@hisilicon.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] iommu/arm-smmu-v3: Simplify stage selection logic
Date: Thu, 17 Aug 2023 19:19:52 +0100	[thread overview]
Message-ID: <a8623bd8-1df4-42b7-4993-006316594818@arm.com> (raw)
In-Reply-To: <CAKHBV27bsDWsS_dUsj=xdTfnc0CDhcH+0ZLZ2z481BZMsBQX4w@mail.gmail.com>

On 2023-08-17 18:06, Michael Shavit wrote:
> On Fri, Aug 18, 2023 at 12:35 AM Robin Murphy <robin.murphy@arm.com> wrote:
>>
>> The reason it's like this is because of arm_smmu_enable_nesting(), which
>> *is* the additional thing that's going on with the stage selection logic.
>>
>> Thanks,
>> Robin.
> 
> Right, but arm_smmu_enable_nesting isn't involved in this computation
> at this point in the flow.
> 
> arm_smmu_enable_nesting returns early if smmu_domain->smmu isn't set,
> and smmu_domain->smmu is only set after arm_smmu_domain_finalise.
> So at this point, smmu_domain->stage is being initialized for the
> first time. If this code is responsible for handling some special
> nesting case, then it's probably not working as intended.

I think you may have misread that code...

Anyway, the point of the logic here is that it is not "selection", it 
is, as the comment says, "restriction" - i.e. it is checking that the 
already-selected stage is actually supported, and coercing it if not. 
The default selection for a newly-allocated domain is always implicitly 
ARM_SMMU_DOMAIN_S1 (which is explicitly defined as 0 to convey that 
significance), but it may be set to ARM_SMMU_DOMAIN_NESTED before the 
first attach finalises the pagetable format.

Obviously this could be clearer, especially for anyone not so familiar 
with all the history, but at this point I honestly don't think it's 
worth doing anything without completely ripping out 
arm_smmu_enable_nesting() as well. Jason already had a patch a while 
ago, and my bus rework is now also very close to the point of finally 
fixing iommu_domain_alloc() to be able to return working domains, such 
that all the "domain_finalise" bodges go away and that whole "modify the 
domain between allocation and attach" paradigm is no longer valid at all.

By this point I'm not too fussed about breaking the current meaning of 
ARM_SMMU_DOMAIN_NESTED any more. But what I definitely don't want to do 
is have a change like this which subtly but decisively breaks it while 
still leaving all the now-dead code in place ;)

Thanks,
Robin.

  reply	other threads:[~2023-08-17 18:21 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-17 16:03 Michael Shavit
2023-08-17 16:21 ` Nicolin Chen
2023-08-17 16:35 ` Robin Murphy
2023-08-17 17:06   ` Michael Shavit
2023-08-17 18:19     ` Robin Murphy [this message]
2023-08-17 18:29       ` Michael Shavit

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=a8623bd8-1df4-42b7-4993-006316594818@arm.com \
    --to=robin.murphy@arm.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=iommu@lists.linux.dev \
    --cc=jean-philippe@linaro.org \
    --cc=jgg@ziepe.ca \
    --cc=joro@8bytes.org \
    --cc=krckatom@amazon.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mshavit@google.com \
    --cc=nicolinc@nvidia.com \
    --cc=will@kernel.org \
    --cc=yangyicong@hisilicon.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

all inboxes | Powered by JetHome®