public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Joerg Roedel <joerg.roedel@amd.com>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: mingo@elte.hu, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] remove fullflush and nofullflush in IOMMU generic option
Date: Fri, 19 Sep 2008 19:20:36 +0200	[thread overview]
Message-ID: <20080919172036.GT24392@amd.com> (raw)
In-Reply-To: <20080920020917O.fujita.tomonori@lab.ntt.co.jp>

On Sat, Sep 20, 2008 at 02:09:21AM +0900, FUJITA Tomonori wrote:
> On Fri, 19 Sep 2008 18:45:41 +0200
> Joerg Roedel <joerg.roedel@amd.com> wrote:
> 
> > On Sat, Sep 20, 2008 at 01:23:30AM +0900, FUJITA Tomonori wrote:
> > > This patch against tip/x86/iommu virtually reverts
> > > 2842e5bf3115193f05dc9dac20f940e7abf44c1a. But just reverting the
> > > commit breaks AMD IOMMU so this patch also includes some fixes.
> >  
> > NACK.
> > 
> > > The above commit adds new two options to x86 IOMMU generic kernel boot
> > > options, fullflush and nofullflush. But such change that affects all
> > > the IOMMUs needs more discussion (all IOMMU parties need the chance to
> > > discuss it):
> > 
> > It affects only IOMMUs which use the iommu_fullflush variable. This are
> > GART, which used it since ages, and AMD IOMMU which was introduced by
> > the above commit. It absolutly makes sense to have command line parameters
> > which make sense for more than one or most of the IOMMUs in x86 into
> > 'iommu='. Ingo agreed with this, see http://lkml.org/lkml/2008/6/30/155
> > I agree with that too. The commit you are trying to revert here was a
> > step into this direction.
> 
> The point is we can't remove or rename VT-d option for IOTLB batching
> because we already exported it for users.
> 
> I think that once we export a boot option to users, we can't remove or
> rename it. It's the user interface.
> 
> You have a different policy for the kernel boot option? You think we
> can change or rename it after exporting it?

No. But we can have the generic option in parallel. There is no reason
to remove the VT-d specific option.

> 
> Yeah, Intel IOMMU need to keep the current option for IOTLB batching
> but it also support fullflush. But we don't discuss anything with
> Intel developers. That's what I'm against.

Thats why my patch does not change VT-d code. So why do you send revert
patches and not starting this discussion? If Muli and the Intel people
disagree we can still revert it.

> > > 'nofullflush' definitely is pointless. 'nofullflush' option doesn't
> > > change any kernel behavior and it was added just for GART
> > > compatibility. We should not have such generic meaningless option just
> > > for GART.
> > 
> > So why do you keep it in this patch then?
> 
> As I wrote, I think that we can't remove the exported user interfacea

You keep this option for AMD IOMMU too. If you move it to AMD IOMMU code
then you can remove nofullflush there.

> 
> Please keep it for AMD option for now. Please send a patch to make it
> generic to other IOMMU people and give them a chance to discuss on
> it.
>

Ok, I will forward the patch to Intel VT-d maintainers and Muli to
discuss it. If they disagree we can revert the patch.

Joerg

-- 
           |           AMD Saxony Limited Liability Company & Co. KG
 Operating |         Wilschdorfer Landstr. 101, 01109 Dresden, Germany
 System    |                  Register Court Dresden: HRA 4896
 Research  |              General Partner authorized to represent:
 Center    |             AMD Saxony LLC (Wilmington, Delaware, US)
           | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy


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

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-19 16:23 [PATCH] remove fullflush and nofullflush in IOMMU generic option FUJITA Tomonori
2008-09-19 16:45 ` Joerg Roedel
2008-09-19 17:09   ` FUJITA Tomonori
2008-09-19 17:20     ` Joerg Roedel [this message]
2008-09-19 17:34       ` FUJITA Tomonori
2008-09-19 17:46         ` Joerg Roedel
2008-09-19 18:40           ` FUJITA Tomonori
2008-09-19 19:42             ` Joerg Roedel
2008-09-19 17:30     ` Joerg Roedel
2008-09-19 17:40       ` FUJITA Tomonori
2008-09-19 18:01         ` Joerg Roedel
2008-09-19 18:48           ` FUJITA Tomonori
2008-09-19 19:52             ` Joerg Roedel
2008-09-19 20:02               ` FUJITA Tomonori
2008-09-19 20:19                 ` Joerg Roedel
2008-09-19 21:56                   ` FUJITA Tomonori
2008-09-19 22:09                     ` Joerg Roedel
2008-09-19 22:18                       ` FUJITA Tomonori
2008-09-19 22:39                         ` Joerg Roedel
2008-09-20  0:54                           ` FUJITA Tomonori
2008-09-20  6:00 ` Ingo Molnar
2008-09-20 13:57   ` FUJITA Tomonori
2008-09-22 11:17     ` Ingo Molnar
2008-09-22 12:05       ` Joerg Roedel
2008-09-22 15:25       ` FUJITA Tomonori
2008-09-22 16:23         ` Joerg Roedel
2008-09-22 16:51           ` FUJITA Tomonori
2008-09-22 18:34             ` Joerg Roedel
2008-09-22 18:48               ` Ingo Molnar
2008-09-22 19:01                 ` Joerg Roedel
2008-09-24 13:12               ` FUJITA Tomonori

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=20080919172036.GT24392@amd.com \
    --to=joerg.roedel@amd.com \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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