mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Shaohua Li <shaohua.li@intel.com>
To: Andi Kleen <ak@suse.de>
Cc: Ashok Raj <ashok.raj@intel.com>,
	linux-kernel@vger.kernel.org, akpm@osdl.org, gregkh@suse.de,
	muli@il.ibm.com, asit.k.mallick@intel.com,
	suresh.b.siddha@intel.com, anil.s.keshavamurthy@intel.com,
	arjan@linux.intel.com
Subject: Re: [Intel IOMMU][patch 3/8] Generic hardware support for Intel IOMMU.
Date: Wed, 25 Apr 2007 09:17:31 +0800	[thread overview]
Message-ID: <1177463851.11073.6.camel@sli10-conroe.sh.intel.com> (raw)
In-Reply-To: <200704242127.09221.ak@suse.de>

On Tue, 2007-04-24 at 21:27 +0200, Andi Kleen wrote:
> On Tuesday 24 April 2007 08:03:02 Ashok Raj wrote:
> >
> > +#ifdef CONFIG_DMAR
> > +#ifdef CONFIG_SMP
> > +static void dmar_msi_set_affinity(unsigned int irq, cpumask_t mask)
> 
> 
> Why does it need an own interrupt type?
> 
> > +
> > +config IOVA_GUARD_PAGE
> > +	bool "Enables gaurd page when allocating IO Virtual Address for IOMMU"
> > +	depends on DMAR
> > +
> > +config IOVA_NEXT_CONTIG
> > +	bool "Keeps IOVA allocations consequent between allocations"
> > +	depends on DMAR && EXPERIMENTAL
> 
> Needs reference to Intel and better description
> 
> The file should have a high level description what it is good for etc.
> 
> Need high level overview over what locks protects what and if there
> is a locking order.
> 
> It doesn't seem to enable sg merging? Since you have enough space 
> that should work.
We actually have a patch to do sg merge. In my test, it doesn't have any
performance gain.

> > +static char *fault_reason_strings[] =
> > +{
> > +	"Software",
> > +	"Present bit in root entry is clear",
> > +	"Present bit in context entry is clear",
> > +	"Invalid context entry",
> > +	"Access beyond MGAW",
> > +	"PTE Write access is not set",
> > +	"PTE Read access is not set",
> > +	"Next page table ptr is invalid",
> > +	"Root table address invalid",
> > +	"Context table ptr is invalid",
> > +	"non-zero reserved fields in RTP",
> > +	"non-zero reserved fields in CTP",
> > +	"non-zero reserved fields in PTE",
> > +	"Unknown"
> > +};
> > +
> > +#define MAX_FAULT_REASON_IDX 	(12)
> 
> 
> You got 14 of them. better use ARRAY_SIZE
> 
> > +#define IOMMU_NAME_LEN		(7)
> > +
> > +struct iommu {
> 
> call it intel_iommu or somesuch even when it's private.
> 
> > +static int __init intel_iommu_setup(char *str)
> > +{
> > +	if (!str)
> > +		return -EINVAL;
> > +	while (*str) {
> > +		if (!strncmp(str, "off", 3)) {
> > +			dmar_disabled = 1;
> > +			printk(KERN_INFO"Intel-IOMMU: disabled\n");
> > +		}
> > +		str += strcspn(str, ",");
> > +		while (*str == ',')
> > +			str++;
> > +	}
> > +	return 0;
> > +}
> > +__setup("intel_iommu=", intel_iommu_setup);
> 
> Why can't you just use the normal iommu=off for this? 
iommu=off disable all iommu, intel_iommu=off just disables intel_iommu.
Isn't possible people want to use other iommu like swiotlb?
> > +
> > +#define MIN_PGTABLE_PAGES	(10)
> > +static mempool_t *pgtable_mempool;
> > +#define MIN_DOMAIN_REQ		(20)
> > +static mempool_t *domain_mempool;
> > +#define MIN_DEVINFO_REQ		(20)
> > +static mempool_t *devinfo_mempool;
> 
> Lots of mempools. How much memory does this pin?
> 
> > +
> > +#define alloc_pgtable_page() mempool_alloc(pgtable_mempool, GFP_ATOMIC)
> > +#define free_pgtable_page(vaddr) mempool_free(vaddr, pgtable_mempool)
> > +#define alloc_domain_mem() mempool_alloc(domain_mempool, GFP_ATOMIC)
> > +#define free_domain_mem(vaddr) mempool_free(vaddr, domain_mempool)
> > +#define alloc_devinfo_mem() mempool_alloc(devinfo_mempool, GFP_ATOMIC)
> > +#define free_devinfo_mem(vaddr) mempool_free(vaddr, devinfo_mempool)
> 
> Do we need the macros? Better expand them in the caller.
> 
> > +static void __iommu_flush_cache(struct iommu *iommu, void *addr, int size)
> > +{
> > +	if (!ecap_coherent(iommu->ecap))
> > +		clflush_cache_range(addr, size);
> > +}
> > +
> > +#define iommu_flush_cache_entry(iommu, addr) \
> > +	__iommu_flush_cache(iommu, addr, 8)
> > +#define iommu_flush_cache_page(iommu, addr) \
> > +	__iommu_flush_cache(iommu, addr, PAGE_SIZE_4K)
> 
> Similar.
> 
> And the 8 should be probably something more descriptive (sizeof?)
> 
> > +/* context entry handling */
> > +static struct context_entry * device_to_context_entry(struct iommu *iommu,
> > +		u8 bus, u8 devfn)
> > +{
> > +	struct root_entry *root;
> > +	struct context_entry *context;
> > +	unsigned long phy_addr;
> > +	unsigned long flags;
> > +
> > +	spin_lock_irqsave(&iommu->lock, flags);
> > +	root = &iommu->root_entry[bus];
> > +	if (!root_present(*root)) {
> > +		phy_addr = (unsigned long)alloc_pgtable_page();
> 
> A GFP_ATOMIC mempool is rather useless. mempool only works if it can block
> for someone else freeing memory and if it can't do that it's not failsafe.
> I'm afraid you need to revise the allocation strategy -- best would be
> to somehow move the memory allocations outside the spinlock paths
> and preallocate if possible.
The problem is pci_map_single and friends usually called with interrupt
disabled or spin locked, so we must use GFP_ATOMIC.

> Same problem in other code.
> 
> > +		if (!dma_pte_present(*pte)) {
> > +			tmp = alloc_pgtable_page();
> 
> Please don't name variable tmp. I know some other code does it, but it's
> just bad style imho.
> 
> 
> > +	/* Make sure hardware complete it */
> > +	start_time = jiffies;
> > +	while (1) {
> > +		sts = dmar_readl(iommu->reg, DMAR_GSTS_REG);
> > +		if (sts & DMA_GSTS_RTPS)
> > +			break;
> > +		if (time_after(jiffies, start_time + DMAR_OPERATION_TIMEOUT))
> > +			panic("DMAR hardware is malfunctional, please disable IOMMU\n");
> > +		cpu_relax();
> > +	}
> 
> Could MWAIT/MONITOR be used for this?
MWAIT/MONITOR just works for cached memory. And this is memory mapped io.

Thanks,
Shaohua

  parent reply	other threads:[~2007-04-25  1:21 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-24  6:02 [Intel IOMMU][patch 0/8] Intel IOMMU Support Ashok Raj
2007-04-24  6:03 ` [Intel IOMMU][patch 1/8] ACPI support for Intel Virtualization Technology for Directed I/O Ashok Raj
2007-04-24 18:50   ` Andi Kleen
2007-04-24 20:17     ` Ashok Raj
2007-04-24  6:03 ` [Intel IOMMU][patch 2/8] Some generic search functions required to lookup device relationships Ashok Raj
2007-04-24  6:03 ` [Intel IOMMU][patch 3/8] Generic hardware support for Intel IOMMU Ashok Raj
2007-04-24 19:27   ` Andi Kleen
2007-04-24 20:59     ` Ashok Raj
2007-04-25  1:17     ` Shaohua Li [this message]
2007-04-25  6:53       ` Andi Kleen
2007-04-24  6:03 ` [Intel IOMMU][patch 4/8] Supporting Zero Length Reads in " Ashok Raj
2007-04-24 19:28   ` Andi Kleen
2007-04-24 20:42     ` Ashok Raj
2007-04-24 21:00     ` David Miller
2007-04-24  6:03 ` [Intel IOMMU][patch 5/8] Graphics driver workarounds to provide unity map Ashok Raj
2007-04-24  6:03 ` [Intel IOMMU][patch 6/8] Doc updates for Intel Virtualization Technology for Directed I/O Ashok Raj
2007-04-24  6:03 ` [Intel IOMMU][patch 7/8] Support for legacy ISA devices Ashok Raj
2007-04-24 19:31   ` Andi Kleen
2007-04-24 20:33     ` Arjan van de Ven
2007-04-24 20:39     ` Ashok Raj
2007-04-24  6:03 ` [Intel IOMMU][patch 8/8] Preserve some Virtual Address when devices cannot address entire range Ashok Raj
2007-04-24 19:33   ` Andi Kleen
2007-04-24 20:33     ` Ashok Raj
2007-04-24 21:12       ` Andi Kleen
2007-04-24 21:23         ` David Miller
2007-04-24 21:32           ` Roland Dreier
2007-04-24 21:47             ` David Miller
2007-04-24 21:38           ` Ashok Raj
2007-04-24 21:50             ` David Miller
2007-04-24 22:03               ` Andi Kleen
2007-04-24 22:26                 ` Ashok Raj
2007-04-25  1:12                 ` H. Peter Anvin
2007-04-25  6:55                   ` Andi Kleen
2007-04-24 23:22               ` Alan Cox
  -- strict thread matches above, loose matches on Subject: below --
2007-04-23 16:38 [Intel IOMMU][patch 0/8] Intel IOMMU Support Ashok Raj
2007-04-23 16:38 ` [Intel IOMMU][patch 3/8] Generic hardware support for Intel IOMMU Ashok Raj

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=1177463851.11073.6.camel@sli10-conroe.sh.intel.com \
    --to=shaohua.li@intel.com \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=anil.s.keshavamurthy@intel.com \
    --cc=arjan@linux.intel.com \
    --cc=ashok.raj@intel.com \
    --cc=asit.k.mallick@intel.com \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=muli@il.ibm.com \
    --cc=suresh.b.siddha@intel.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

all inboxes | Powered by JetHome®