Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 5 May 2023 21:09:00 -0700
From:   Jacob Pan <jacob.jun.pan@linux.intel.com>
To:     Jason Gunthorpe <jgg@ziepe.ca>
Cc:     Linus Torvalds <torvalds@linux-foundation.org>,
        Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
        linux-kernel@vger.kernel.org, iommu@lists.linux.dev,
        jacob.jun.pan@linux.intel.com
Subject: Re: [git pull] IOMMU Updates for Linux v6.4
Message-ID: <20230505210900.0764fa83@jacob-builder>
In-Reply-To: <ZE70doFi8X3KgfrV@ziepe.ca>
References: <ZE5NR5Ml8I2/Ze0f@8bytes.org>
        <CAHk-=wiriLmq6OgLLF9seANqCJqjCrgUC384zcJUFtv3xJgVkQ@mail.gmail.com>
        <ZE70doFi8X3KgfrV@ziepe.ca>
Organization: OTC
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi Jason,

On Sun, 30 Apr 2023 20:06:30 -0300, Jason Gunthorpe <jgg@ziepe.ca> wrote:

> We've had this longstanding confusion in the iommu layer that SVA and
> PASID are one and the same thing, we are slowly reorganizing it.. For
> now it is fine for IOMMU_SVA to cover the PASID allocator as the only
> drivers that support PASID also support SVA.
> 
> Arguably the design is backwards and IOMMU_SVA should be user
> selectable and it should turn off the SVA code entirely including the
> driver code.
> 
> > Somebody should double-check my result, in other words.  
> 
> I didn't notice anything wrong, I'm sure Lu and Yi will test it!
FWIW, I did a quick test with SVA ENQCMD on an Intel Data Streaming
Accelerator (DSA) shared work queue, seems to work fine. Code looks good to
me too.

Thanks,

Jacob