linux-kernel - Re: [PATCH v5 5/7] iommu/dma: Allow a single FQ in addition to per-CPU FQs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8209c172aaa415eace9dcd4b5675ef8506a34538.camel@linux.ibm.com>
Date:   Mon, 30 Jan 2023 16:57:56 +0100
From:   Niklas Schnelle <schnelle@...ux.ibm.com>
To:     Jason Gunthorpe <jgg@...dia.com>,
        Robin Murphy <robin.murphy@....com>
Cc:     Joerg Roedel <joro@...tes.org>, Will Deacon <will@...nel.org>,
        Wenjia Zhang <wenjia@...ux.ibm.com>,
        Matthew Rosato <mjrosato@...ux.ibm.com>,
        Gerd Bayer <gbayer@...ux.ibm.com>,
        Pierre Morel <pmorel@...ux.ibm.com>, iommu@...ts.linux.dev,
        linux-s390@...r.kernel.org, borntraeger@...ux.ibm.com,
        hca@...ux.ibm.com, gor@...ux.ibm.com,
        gerald.schaefer@...ux.ibm.com, agordeev@...ux.ibm.com,
        svens@...ux.ibm.com, linux-kernel@...r.kernel.org,
        Julian Ruess <julianr@...ux.ibm.com>
Subject: Re: [PATCH v5 5/7] iommu/dma: Allow a single FQ in addition to
 per-CPU FQs

On Mon, 2023-01-30 at 11:29 -0400, Jason Gunthorpe wrote:
> On Mon, Jan 30, 2023 at 03:13:22PM +0000, Robin Murphy wrote:
> 
> > Either way, the more I think about this the more I'm starting to agree that
> > adding more domain types for iommu-dma policy is a step in the wrong
> > direction. If I may, I'd like to fall back on the "or at least some definite
> > internal flag" part of my original suggestion :)
> 
> Yes please, lets try to remove IOMMU_DOMAIN_DMA, not add more :)
> 
> At this point we should probably just sort of hackily add a ops flag
> to indicate single queue and when we fixup the policy logic we can
> make it a user selectable policy as well.
> 
> Jason

Ok yeah I did like the policy idea you brought up a while back. If we
want to do the conversion to dma-iommu before that we do need an
interim solution though. So if I'm reading your ops flag idea right I
think it could even re-use much of the logic in this series and just
not introduce a new domain type.

I'm wondering if maybe instead of plain flag bits it makes more sense
to have a dma_iommu_options struct that contains the queue size and a
flags value which indicates whether a single or per-CPU queue is used.
Then I could add an iommu_ops callback that takes a device and a
pointer to the dma_iommu_options. That way we can still set the options
per device but don't need a whole extra domain type. This callback
would then just be called during initialization of the DMA-FQ domain
and not having the callback just leaves the defaults unchanged. Does
that go in the right direction?

Thanks,
Niklas