kexec.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Baoquan He <bhe@redhat.com>
To: Joerg Roedel <joro@8bytes.org>
Cc: kexec@lists.infradead.org, xlpang@redhat.com,
	linux-kernel@vger.kernel.org, Vincent.Wan@amd.com,
	iommu@lists.linux-foundation.org, dyoung@redhat.com
Subject: Re: [PATCH v6 7/9] iommu/amd: Update domain into to dte entry during device driver init
Date: Sun, 13 Nov 2016 13:17:17 +0800	[thread overview]
Message-ID: <20161113051717.GB19995@x1> (raw)
In-Reply-To: <20161110114816.GE9996@8bytes.org>

Hi Joerg,

Thanks for your reviewing and great comments!

On 11/10/16 at 12:48pm, Joerg Roedel wrote:
> On Thu, Oct 20, 2016 at 07:37:18PM +0800, Baoquan He wrote:
> >  	prot = dir2prot(direction);
> > +	if (translation_pre_enabled(iommu) && !dev_data->domain_updated) {
> > +		dev_data->domain_updated = true;
> > +		set_dte_entry(dev_data->devid, domain, dev_data->ats.enabled);
> > +		if (alias != dev_data->devid)
> > +			set_dte_entry(alias, domain, dev_data->ats.enabled);
> > +		device_flush_dte(dev_data);
> > +	}
> 
> Hmm, I really don't like to have these checks in the fast-path. But to
> get rid of it I think we need to re-work the way domains are assigned to
> devices.
> 
> One way to do this would be to add a 'defered-domain-attach' feature to
> the iommu-core code. What do you think about this?

Yes, I have to admit code in this patch is really urly. Could you say a
little more about the "defered-domain-attach"? I would love to do any
improvement as long as it's make things correct and better. I could read
code flow several times from init to the end of driver probe, then may
get what you say because of my limited knowledge. If you can give a little
details about it, I can try to change and post for reviewing.

What I get now is you want to see a function  is added so that we can invoke
when attach domain to device. And the calling can be decided by checking
if it's in kdump. This makes it like intel iommu does, defer the
attaching to probe stage. That's why you don't need to do what I am
doing in this patch when you fix intel iommu failure in kdump kernel. Am
I right?

Thanks
Baoquan


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  parent reply	other threads:[~2016-11-13  5:17 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-20 11:37 [PATCH v6 0/9] Fix kdump faults on system with amd iommu Baoquan He
2016-10-20 11:37 ` [PATCH v6 1/9] iommu/amd: Detect pre enabled translation Baoquan He
2016-10-20 11:37 ` [PATCH v6 2/9] iommu/amd: add several helper function Baoquan He
2016-10-20 11:37 ` [PATCH v6 3/9] iommu/amd: Define bit fields for DTE particularly Baoquan He
2016-10-20 11:37 ` [PATCH v6 4/9] iommu/amd: Add function copy_dev_tables Baoquan He
2016-10-20 11:37 ` [PATCH v6 5/9] iommu/amd: copy old trans table from old kernel Baoquan He
2016-10-20 11:37 ` [PATCH v6 6/9] iommu/amd: Don't update domain info to dte entry at iommu init stage Baoquan He
2016-10-20 11:37 ` [PATCH v6 7/9] iommu/amd: Update domain into to dte entry during device driver init Baoquan He
     [not found]   ` <20161110114816.GE9996@8bytes.org>
2016-11-13  5:17     ` Baoquan He [this message]
2016-10-20 11:37 ` [PATCH v6 8/9] iommu/amd: Add sanity check of irq remap information of old dev table entry Baoquan He
2016-10-20 11:37 ` [PATCH v6 9/9] iommu/amd: Don't copy GCR3 table root pointer Baoquan He
2016-11-04  5:14 ` [PATCH v6 0/9] Fix kdump faults on system with amd iommu Baoquan He
2016-11-04  5:29   ` Baoquan He
     [not found] ` <20161110115218.GF9996@8bytes.org>
2016-11-13  5:07   ` Baoquan He

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=20161113051717.GB19995@x1 \
    --to=bhe@redhat.com \
    --cc=Vincent.Wan@amd.com \
    --cc=dyoung@redhat.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xlpang@redhat.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;
as well as URLs for NNTP newsgroup(s).