lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080922144601.GA27956@elte.hu>
Date:	Mon, 22 Sep 2008 16:46:01 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Joerg Roedel <joerg.roedel@....com>
Cc:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] AMD IOMMU: revert "x86, AMD IOMMU: honor iommu=off
	instead of amd_iommu=off"


* Joerg Roedel <joerg.roedel@....com> wrote:

> >     x86, AMD IOMMU: honor iommu=off instead of amd_iommu=off
> > 
> >     This patch removes the amd_iommu=off kernel parameter and honors 
> >     the generic
> > 
> >     iommu=off parameter for the same purpose.
> > 
> > 
> > The above commit is wrong.
> 
> It isn't. The user normally don't care about the type of IOMMU in the 
> system. So disabling it with iommu=off is the right way. To achieve 
> what you want its better to add iommu=gart and iommu=amd to the option 
> parser. This will be consistent with Calgary and SWIOTLB too.

well, what matters in the end is to have a consistent set of exclusion 
options:

  gart_iommu=off     # disable the GART (and only that one)
  intel_iommu=off    # disable the Intel IOMMU (and only that one)
  amd_iommu=off      # disable AMD-IOMMU (and only that one)

then there's the all-off option:

  iommu=off          # wildcard: disable all IOMMUs

[ whether iommu=off also disables the swiotlb is a detail. ]

and we could also do the inclusive options in addition:

  iommu=gart         # use the GART as the primary IOMMU [if available]
  iommu=amd          # use the AMD-IOMMU as the primary IOMMU [if available]
  iommu=intel        # use the Intel IOMMU [if available]

so could we please first agree on such a specific list of generic 
options, and then implement them consistently, while keeping legacies 
(the ones that matter) intact as well?

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ