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: <20080919192732.GI27426@8bytes.org>
Date:	Fri, 19 Sep 2008 21:27:32 +0200
From:	Joerg Roedel <joro@...tes.org>
To:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
Cc:	ashok.raj@...el.com, shaohua.li@...el.com,
	anil.s.keshavamurthy@...el.com, muli@...ibm.com,
	joerg.roedel@....com, iommu@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org, mingo@...e.hu,
	"Woodhouse, David" <david.woodhouse@...el.com>
Subject: Re: [PATCH 03/23] AMD IOMMU: implement lazy IO/TLB flushing

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@...tes.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

--
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