Re: [Patch v2 7/9] iommu/amd: copy old tables and do not update dev tables before driver init

[Baoquan He <bhe-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

Hi Joerg,

On 11/27/15 at 12:35pm, Joerg Roedel wrote:
> > +++ b/drivers/iommu/amd_iommu.c
> > @@ -1992,14 +1992,15 @@ static void do_attach(struct iommu_dev_data *dev_data,
> >  	/* Update data structures */
> >  	dev_data->domain = domain;
> >  	list_add(&dev_data->list, &domain->dev_list);
> > -	set_dte_entry(dev_data->devid, domain, ats);
> > +	if (!translation_pre_enabled()) {
> > +		set_dte_entry(dev_data->devid, domain, ats);
> > +		/* Flush the DTE entry */
> > +		device_flush_dte(dev_data);
> > +	}
> 
> Hmm, this patch adds a lot of special cases into the AMD IOMMU code to
> make sure the domain is attached at driver init time.
> 
> Can we change the code to generally defer domain attachment to driver
> init time? There is a set_dma_mask call-back in the dma-ops that can be
> used for that.
> 
> This would limit the special cases to device table initialization and
> iommu enable time.

I checked code and still didn't get how to use set_dma_mask to help
defer the domain info updating to driver init time. Previously what I
tried to do is:
Firstly copy old dev table entries to newly allocated dev table;
Secondly always use the old dev table before driver init. Means before
driver init any behavious which is trying to update domain informaton to
that device would be skipped;
Thirdly, as soon as it's going to driver init, allow the updating.

>From definition and usage for other arch/component set_dma_mask is only
used to set the DMA addressing limitations which is I got from reading.
Could you please give more tips on this? Maybe I didn't dig into it deep
enough to get it.

Thanks
Baoquan