Re: [PATCH 5.4 v2 1/1] iommu/vt-d: Fix agaw for a supported 48 bit guest address width

[gre...@linuxfoundation.org]

On Mon, Apr 12, 2021 at 06:25:44PM +, Saeed Mirzamohammadi wrote:
> Hi Greg,
> 
> This patch fixes an issue with the IOMMU driver and it only applies to 5.4, 
> 4.19, and 4.14 stable kernels. May I know when this patch would be available 
> in the stable kernels?
> 
> Subject: iommu/vt-d: Fix agaw for a supported 48 bit guest address width
> 




This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.


___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 2/9] Move dma_ops from archdata into struct device

[gre...@linuxfoundation.org]

On Wed, Jan 11, 2017 at 10:28:05PM +, Bart Van Assche wrote:
> On Wed, 2017-01-11 at 21:31 +0100, gre...@linuxfoundation.org wrote:
> > That's a big sign that your patch series needs work.  Break it up into
> > smaller pieces, it should be possible, which will make merges easier
> > (well, different in a way.)
> 
> Hello Greg,
> 
> Can you have a look at the attached patches? These three patches are a
> splitup of the single patch at the start of this e-mail thread.

Please send them in the proper format (i.e. one patch per email), and I
will be glad to review them.  Otherwise it's really hard to do so, would
you want to review attachments?

thanks,

greg k-h
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 2/9] Move dma_ops from archdata into struct device

[gre...@linuxfoundation.org]

On Wed, Jan 11, 2017 at 06:17:03PM +, Bart Van Assche wrote:
> On Wed, 2017-01-11 at 07:48 +0100, Greg Kroah-Hartman wrote:
> > On Tue, Jan 10, 2017 at 04:56:41PM -0800, Bart Van Assche wrote:
> > > Several RDMA drivers, e.g. drivers/infiniband/hw/qib, use the CPU to
> > > transfer data between memory and PCIe adapter. Because of performance
> > > reasons it is important that the CPU cache is not flushed when such
> > > drivers transfer data. Make this possible by allowing these drivers to
> > > override the dma_map_ops pointer. Additionally, introduce the function
> > > set_dma_ops() that will be used by a later patch in this series.
> > 
> > When you say things like "additionally", that's a huge flag that this
> > needs to be split up into multiple patches.  No need to add
> > set_dma_ops() here in this patch.
> 
> Hello Greg,
> 
> Some architectures already define a set_dma_ops() function. So what this
> patch does is to move both the dma_ops pointer and the set_dma_ops()
> function from architecture-specific to architecture independent code. I
> don't think that it is possible to separate these two changes. But I
> understand that how I formulated the patch description caused confusion. I
> will rewrite the patch description to make it more clear before I repost
> this patch series.

I think you should separate it out into multiple patches, this is a
mess, as you say below:

> > And I'd argue that it should be dma_ops_set(), and dma_ops_get(), just
> > to keep the namespace sane, but that's probably a different set of
> > patches...
> 
> Every time I rebase and retest this patch series on top of a new kernel
> version I have to modify some of the patches to compensate for changes in
> the architecture code. So I expect that once Linus merges these patches that
> he will have to resolve one or more merge conflicts. Including a rename of
> the functions that query and set the dma_ops pointer in this patch series
> would increase the number of merge conflicts triggered by this patch series
> and would make Linus' job harder. So I hope that you will allow me to
> postpone that rename until a later time ...

That's a big sign that your patch series needs work.  Break it up into
smaller pieces, it should be possible, which will make merges easier
(well, different in a way.)

Good luck, tree-wide changes are not simple.

greg k-h
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 2/9] Move dma_ops from archdata into struct device

[gre...@linuxfoundation.org]

On Wed, Jan 11, 2017 at 06:03:15PM +, Bart Van Assche wrote:
> On Wed, 2017-01-11 at 07:46 +0100, Greg Kroah-Hartman wrote:
> > On Tue, Jan 10, 2017 at 04:56:41PM -0800, Bart Van Assche wrote:
> > > Several RDMA drivers, e.g. drivers/infiniband/hw/qib, use the CPU to
> > > transfer data between memory and PCIe adapter. Because of performance
> > > reasons it is important that the CPU cache is not flushed when such
> > > drivers transfer data. Make this possible by allowing these drivers to
> > > override the dma_map_ops pointer. Additionally, introduce the function
> > > set_dma_ops() that will be used by a later patch in this series.
> > > 
> > > Signed-off-by: Bart Van Assche 
> > > Cc: [ ... ]
> > 
> > That's a crazy cc: list, you should break this up into smaller pieces,
> > otherwise it's going to bounce...
> 
> That's a subset of what scripts/get_maintainer.pl came up with. Suggestions
> for a more appropriate cc-list for a patch like this that touches all
> architectures would be welcome.

You need to break this patch up into a series that can be applied in
sequence, don't change everything all at once.  That's a mess to merge,
as you are finding out.

> > > diff --git a/include/linux/device.h b/include/linux/device.h
> > > index 491b4c0ca633..c7cb225d36b0 100644
> > > --- a/include/linux/device.h
> > > +++ b/include/linux/device.h
> > > @@ -885,6 +885,8 @@ struct dev_links_info {
> > >   * a higher-level representation of the device.
> > >   */
> > >  struct device {
> > > + const struct dma_map_ops *dma_ops; /* See also get_dma_ops() */
> > > +
> > >   struct device   *parent;
> > >  
> > >   struct device_private   *p;
> > 
> > Why not put this new pointer down with the other dma fields in this
> > structure?  Any specific reason it needs to be first?
> 
> Are there CPU architectures for which access to the first member of a
> structure can be encoded and/or executed more efficiently than access to
> other members of a structure? If not, I'm fine with moving the new pointer
> further down.

Why do you think that your pointer is the one that gets to be "most
efficient"?  :)

Seriously, no, it doesn't matter at all, it's all just pointer math
which is very fast.  Put it with the other stuff please, don't try to
optimize something without ever measuring it.

thanks,

greg k-h
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [v12, 0/8] Fix eSDHC host version register bug

[gre...@linuxfoundation.org]

On Wed, Oct 19, 2016 at 02:47:07AM +, Y.B. Lu wrote:
> + Greg
> 
> Hi Greg,
> 
> I submitted this patchset for a MMC bug fix, and introduce the below patch 
> which needs your ACK.
> > > Arnd Bergmann (1):
> > >   base: soc: introduce soc_device_match() interface
> https://patchwork.kernel.org/patch/9342913/
> 
> Could you help to review it and give some comments or ACK.
> Thank you very much.

Now acked.

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH char-misc-next v2 04/22] iommu: Allow iova to be used without requiring IOMMU_SUPPORT

[gre...@linuxfoundation.org]

On Mon, Oct 05, 2015 at 10:23:38PM -0700, Sudeep Dutt wrote:
> On Tue, 2015-10-06 at 06:20 +0100, gre...@linuxfoundation.org wrote:
> > On Tue, Oct 06, 2015 at 06:12:40AM +0100, gre...@linuxfoundation.org wrote:
> > > On Mon, Oct 05, 2015 at 10:38:43AM -0700, Sudeep Dutt wrote:
> > > > On Mon, 2015-10-05 at 03:50 -0700, Woodhouse, David wrote:
> > > > > On Tue, 2015-09-29 at 18:09 -0700, Ashutosh Dixit wrote:
> > > > > > From: Sudeep Dutt <sudeep.d...@intel.com>
> > > > > > 
> > > > > > iova is a library which can be built without IOMMU_SUPPORT
> > > > > > 
> > > > > > Signed-off-by: Sudeep Dutt <sudeep.d...@intel.com>
> > > > > 
> > > > > The first three of these patches are in 4.3-rc4 already. Apologies for
> > > > > the delay in pushing them out.
> > > > > 
> > > > > This one looks sane enough too, but perhaps in that case we should 
> > > > > move
> > > > > the code *out* of drivers/iommu/ and into lib/iova/ ?
> > > > > 
> > > > 
> > > > Yes, moving the code into lib/iova is the correct long term solution. I
> > > > have sent Greg a patch which reverts this commit since it is no longer
> > > > required and will create a merge conflict for him unnecessarily as well
> > > > with 4.3-rc4.
> > > 
> > > I can handle merge issues, that's trivial.  Reverting the patch
> > > shoulnd't really be needed, right?  Let me see what happens when I merge
> > > to see if your patch is necessary...
> > 
> > Ok, I don't think it is needed, the merge was pretty trivial.
> > 
> > Can you test out my char-misc-testing branch right now to see if it's
> > all ok with the merge?  If so, I'll move it all over to the "real" place
> > for it to start showing up in linux-next, i.e. my char-misc-next branch.
> > 
> 
> Hi Greg,
> 
> I think it is best to revert this patch as it is incorrect. The iommu
> folder gets compiled only if IOMMU_SUPPORT is enabled so IOMMU_IOVA
> should indeed be included only when IOMMU_SUPPORT is enabled.
> 
> Sincere apologies for the mess here but I believe it will all get fixed
> up if you accept the revert of 353649e5da I sent across earlier today.

Again, look at the merge, I think I already handled this in that manner.
If not, let me know.

thanks,

greg k-h
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH char-misc-next v2 04/22] iommu: Allow iova to be used without requiring IOMMU_SUPPORT

[gre...@linuxfoundation.org]

On Tue, Oct 06, 2015 at 01:05:27AM -0700, Sudeep Dutt wrote:
> On Tue, 2015-10-06 at 08:56 +0100, gre...@linuxfoundation.org wrote:
> > On Mon, Oct 05, 2015 at 10:23:38PM -0700, Sudeep Dutt wrote:
> > > On Tue, 2015-10-06 at 06:20 +0100, gre...@linuxfoundation.org wrote:
> > > > On Tue, Oct 06, 2015 at 06:12:40AM +0100, gre...@linuxfoundation.org 
> > > > wrote:
> > > > > On Mon, Oct 05, 2015 at 10:38:43AM -0700, Sudeep Dutt wrote:
> > > > > > On Mon, 2015-10-05 at 03:50 -0700, Woodhouse, David wrote:
> > > > > > > On Tue, 2015-09-29 at 18:09 -0700, Ashutosh Dixit wrote:
> > > > > > > > From: Sudeep Dutt <sudeep.d...@intel.com>
> > > > > > > > 
> > > > > > > > iova is a library which can be built without IOMMU_SUPPORT
> > > > > > > > 
> > > > > > > > Signed-off-by: Sudeep Dutt <sudeep.d...@intel.com>
> > > > > > > 
> > > > > > > The first three of these patches are in 4.3-rc4 already. 
> > > > > > > Apologies for
> > > > > > > the delay in pushing them out.
> > > > > > > 
> > > > > > > This one looks sane enough too, but perhaps in that case we 
> > > > > > > should move
> > > > > > > the code *out* of drivers/iommu/ and into lib/iova/ ?
> > > > > > > 
> > > > > > 
> > > > > > Yes, moving the code into lib/iova is the correct long term 
> > > > > > solution. I
> > > > > > have sent Greg a patch which reverts this commit since it is no 
> > > > > > longer
> > > > > > required and will create a merge conflict for him unnecessarily as 
> > > > > > well
> > > > > > with 4.3-rc4.
> > > > > 
> > > > > I can handle merge issues, that's trivial.  Reverting the patch
> > > > > shoulnd't really be needed, right?  Let me see what happens when I 
> > > > > merge
> > > > > to see if your patch is necessary...
> > > > 
> > > > Ok, I don't think it is needed, the merge was pretty trivial.
> > > > 
> > > > Can you test out my char-misc-testing branch right now to see if it's
> > > > all ok with the merge?  If so, I'll move it all over to the "real" place
> > > > for it to start showing up in linux-next, i.e. my char-misc-next branch.
> > > > 
> > > 
> > > Hi Greg,
> > > 
> > > I think it is best to revert this patch as it is incorrect. The iommu
> > > folder gets compiled only if IOMMU_SUPPORT is enabled so IOMMU_IOVA
> > > should indeed be included only when IOMMU_SUPPORT is enabled.
> > > 
> > > Sincere apologies for the mess here but I believe it will all get fixed
> > > up if you accept the revert of 353649e5da I sent across earlier today.
> > 
> > Again, look at the merge, I think I already handled this in that manner.
> > If not, let me know.
> > 
> 
> Hi Greg,
> 
> I took a look at your latest char-misc-testing tree and it needs to be
> fixed up. IOMMU_IOVA should be inside the "if IOMMU_SUPPORT" block
> instead of above it.
> 
> git revert 353649e5da in the char-misc-testing tree will fix everything
> up or you could also apply the patch I sent earlier today which has the
> same revert.

Ok, I've applied your patch, rolled back the merge, and that should be
good, right?  If so, I'll push this branch out to char-misc-next and
then merge in 4.3-rc4 just to keep everything up to date.

thanks,

greg k-h
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH char-misc-next v2 04/22] iommu: Allow iova to be used without requiring IOMMU_SUPPORT

[gre...@linuxfoundation.org]

On Mon, Oct 05, 2015 at 10:38:43AM -0700, Sudeep Dutt wrote:
> On Mon, 2015-10-05 at 03:50 -0700, Woodhouse, David wrote:
> > On Tue, 2015-09-29 at 18:09 -0700, Ashutosh Dixit wrote:
> > > From: Sudeep Dutt 
> > > 
> > > iova is a library which can be built without IOMMU_SUPPORT
> > > 
> > > Signed-off-by: Sudeep Dutt 
> > 
> > The first three of these patches are in 4.3-rc4 already. Apologies for
> > the delay in pushing them out.
> > 
> > This one looks sane enough too, but perhaps in that case we should move
> > the code *out* of drivers/iommu/ and into lib/iova/ ?
> > 
> 
> Yes, moving the code into lib/iova is the correct long term solution. I
> have sent Greg a patch which reverts this commit since it is no longer
> required and will create a merge conflict for him unnecessarily as well
> with 4.3-rc4.

I can handle merge issues, that's trivial.  Reverting the patch
shoulnd't really be needed, right?  Let me see what happens when I merge
to see if your patch is necessary...
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH char-misc-next v2 04/22] iommu: Allow iova to be used without requiring IOMMU_SUPPORT

[gre...@linuxfoundation.org]

On Tue, Oct 06, 2015 at 06:12:40AM +0100, gre...@linuxfoundation.org wrote:
> On Mon, Oct 05, 2015 at 10:38:43AM -0700, Sudeep Dutt wrote:
> > On Mon, 2015-10-05 at 03:50 -0700, Woodhouse, David wrote:
> > > On Tue, 2015-09-29 at 18:09 -0700, Ashutosh Dixit wrote:
> > > > From: Sudeep Dutt <sudeep.d...@intel.com>
> > > > 
> > > > iova is a library which can be built without IOMMU_SUPPORT
> > > > 
> > > > Signed-off-by: Sudeep Dutt <sudeep.d...@intel.com>
> > > 
> > > The first three of these patches are in 4.3-rc4 already. Apologies for
> > > the delay in pushing them out.
> > > 
> > > This one looks sane enough too, but perhaps in that case we should move
> > > the code *out* of drivers/iommu/ and into lib/iova/ ?
> > > 
> > 
> > Yes, moving the code into lib/iova is the correct long term solution. I
> > have sent Greg a patch which reverts this commit since it is no longer
> > required and will create a merge conflict for him unnecessarily as well
> > with 4.3-rc4.
> 
> I can handle merge issues, that's trivial.  Reverting the patch
> shoulnd't really be needed, right?  Let me see what happens when I merge
> to see if your patch is necessary...

Ok, I don't think it is needed, the merge was pretty trivial.

Can you test out my char-misc-testing branch right now to see if it's
all ok with the merge?  If so, I'll move it all over to the "real" place
for it to start showing up in linux-next, i.e. my char-misc-next branch.

thanks,

greg k-h
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu