All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joerg Roedel <joro@8bytes.org>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: ashok.raj@intel.com, shaohua.li@intel.com,
	anil.s.keshavamurthy@intel.com, muli@il.ibm.com,
	joerg.roedel@amd.com, iommu@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org, mingo@elte.hu, "Woodhouse,
	David" <david.woodhouse@intel.com>
Subject: Re: [PATCH 03/23] AMD IOMMU: implement lazy IO/TLB flushing
Date: Fri, 19 Sep 2008 21:27:32 +0200	[thread overview]
Message-ID: <20080919192732.GI27426@8bytes.org> (raw)
In-Reply-To: <20080920034028S.fujita.tomonori@lab.ntt.co.jp>

On Sat, Sep 20, 2008 at 03:40:34AM +0900, FUJITA Tomonori wrote:
> On Fri, 19 Sep 2008 19:43:39 +0200
> Joerg Roedel <joro@8bytes.org> wrote:
> 
> > Hi All,
> > 
> > FUJITA mentioned that I forgot to discuss this patch with you guys, the
> > implementers and maintainers for Intel VT-d and Calgary IOMMU drivers. I
> > would like to hear your opinion on that patch. He is right with that.
> > The patch is already in tip/iommu but can easily be reverted if there
> > are fundamental objections.
> > The patch basically moves the iommu=fullflush and iommu=nofullflush
> > option from the GART code to pci-dma.c. So we can use these parameters
> > in other IOMMU implementations too. Since Intel VT-d is implementing
> > also lazy IO/TLB flushing it would benefit from this generic parameter
> > too. I am not so sure about Calgary, but we have other parameters for
> > iommu= which doesn't affect all hardware IOMMUs.
> 
> nofullflush is pointless. It doesn't change any kernel behavior. Yes,
> GART has it and we can't remove it because we exported it to
> users. But please don't add such pointless option to the generic
> options just for GART compatibility.

I think maybe we can remove it completly. It doesn't change any behavior
for GART too and as an unknown option it will be silently ignored by the
command line parser. So removing this option completly will not break
the user interface, imho.
 
> fullflush might be useful as a generic option to disable lazy IOTLB
> flushing. But I'm not sure that Calgary uses it. VT-d already has
> 'strict' option for it and we can't change it. If VT-d wants to
> support both 'strict' and 'fullflush' for disabling lazy IOTLB
> flushing, it would make sense. But if VT-d doesn't want, it is useful
> only for GART and AMD IOMMU. If so, I don't think that it is very
> useful but I'm not against adding it.

I think it will be usefull for VT-d too. As Ingo stated some time ago,
it makes sense to have a common set of options independent of the
specific type of hardware IOMMU in the system. And all hardware IOMMUs
for x86 implement lazy IO/TLB flushing. Only Calgary does not allow to
disable it. So iommu=fullflush is a good candidate for a common
parameter.

Joerg


  reply	other threads:[~2008-09-19 19:27 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-17 16:52 [PATCH 0/23] AMD IOMMU 2.6.28 updates for review Joerg Roedel
2008-09-17 16:52 ` [PATCH 01/23] AMD IOMMU: check for invalid device pointers Joerg Roedel
2008-09-17 16:52 ` [PATCH 02/23] AMD IOMMU: move TLB flushing to the map/unmap helper functions Joerg Roedel
2008-09-17 16:52 ` [PATCH 03/23] AMD IOMMU: implement lazy IO/TLB flushing Joerg Roedel
2008-09-17 19:20   ` FUJITA Tomonori
2008-09-17 19:28     ` Joerg Roedel
2008-09-18  1:29       ` FUJITA Tomonori
2008-09-18 10:13         ` Joerg Roedel
2008-09-18 14:03         ` Joerg Roedel
2008-09-18 23:10           ` FUJITA Tomonori
2008-09-19  6:29             ` Joerg Roedel
2008-09-19 10:21               ` FUJITA Tomonori
2008-09-19 17:43           ` Joerg Roedel
2008-09-19 18:40             ` FUJITA Tomonori
2008-09-19 19:27               ` Joerg Roedel [this message]
2008-09-19 18:47             ` Keshavamurthy, Anil S
2008-09-19 18:47             ` Keshavamurthy, Anil S
2008-09-19 18:48             ` Keshavamurthy, Anil S
2008-09-21  9:05               ` Joerg Roedel
2008-09-22 16:26                 ` David Woodhouse
2008-09-21  5:27             ` Muli Ben-Yehuda
2008-09-17 16:52 ` [PATCH 04/23] AMD IOMMU: add branch hints to completion wait checks Joerg Roedel
2008-09-17 16:52 ` [PATCH 05/23] AMD IOMMU: align alloc_coherent addresses properly Joerg Roedel
2008-09-17 16:52 ` [PATCH 06/23] AMD IOMMU: add event buffer allocation Joerg Roedel
2008-09-17 16:52 ` [PATCH 07/23] AMD IOMMU: save pci segment from ACPI tables Joerg Roedel
2008-09-17 16:52 ` [PATCH 08/23] AMD IOMMU: save pci_dev instead of devid Joerg Roedel
2008-09-17 16:52 ` [PATCH 09/23] AMD IOMMU: add MSI interrupt support Joerg Roedel
2008-09-17 16:52 ` [PATCH 10/23] AMD IOMMU: add event handling code Joerg Roedel
2008-09-17 16:52 ` [PATCH 11/23] AMD IOMMU: enable event logging Joerg Roedel
2008-09-17 16:52 ` [PATCH 12/23] AMD IOMMU: allow IO page faults from devices Joerg Roedel
2008-09-17 16:52 ` [PATCH 13/23] AMD IOMMU: add dma_supported callback Joerg Roedel
2008-09-17 16:52 ` [PATCH 14/23] AMD IOMMU: don't assing preallocated protection domains to devices Joerg Roedel
2008-09-17 16:52 ` [PATCH 15/23] AMD IOMMU: some set_device_domain cleanups Joerg Roedel
2008-09-17 16:52 ` [PATCH 16/23] AMD IOMMU: avoid unnecessary low zone allocation in alloc_coherent Joerg Roedel
2008-09-17 16:52 ` [PATCH 17/23] AMD IOMMU: replace memset with __GFP_ZERO " Joerg Roedel
2008-09-17 16:52 ` [PATCH 18/23] AMD IOMMU: simplify dma_mask_to_pages Joerg Roedel
2008-09-17 19:20   ` FUJITA Tomonori
2008-09-18  7:32     ` Joerg Roedel
2008-09-18 15:57       ` FUJITA Tomonori
2008-09-18 16:39         ` Joerg Roedel
2008-09-17 16:52 ` [PATCH 19/23] AMD IOMMU: free domain bitmap with its allocation order Joerg Roedel
2008-09-17 16:52 ` [PATCH 20/23] AMD IOMMU: remove unnecessary cast to u64 in the init code Joerg Roedel
2008-09-17 16:52 ` [PATCH 21/23] AMD IOMMU: calculate IVHD size with a function Joerg Roedel
2008-09-17 16:52 ` [PATCH 22/23] AMD IOMMU: use cmd_buf_size when freeing the command buffer Joerg Roedel
2008-09-17 16:52 ` [PATCH 23/23] add AMD IOMMU tree to MAINTAINERS file Joerg Roedel

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=20080919192732.GI27426@8bytes.org \
    --to=joro@8bytes.org \
    --cc=anil.s.keshavamurthy@intel.com \
    --cc=ashok.raj@intel.com \
    --cc=david.woodhouse@intel.com \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joerg.roedel@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=muli@il.ibm.com \
    --cc=shaohua.li@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.