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
next prev 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®