linux-kernel - Re: [PATCH 9/9] x86: Detect whether we should use Xen SWIOTLB.

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]

Date:	Wed, 28 Jul 2010 08:36:06 +0900
From:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To:	konrad.wilk@...cle.com
Cc:	hpa@...or.com, jeremy@...p.org, Ian.Campbell@...rix.com,
	albert_herranz@...oo.es, x86@...nel.org, jbarnes@...tuousgeek.org,
	linux-kernel@...r.kernel.org, fujita.tomonori@....ntt.co.jp,
	iommu@...ts.linux-foundation.org, tglx@...utronix.de
Subject: Re: [PATCH 9/9] x86: Detect whether we should use Xen SWIOTLB.

On Tue, 27 Jul 2010 15:41:05 -0400
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com> wrote:

> On Tue, Jul 27, 2010 at 12:03:56PM -0700, H. Peter Anvin wrote:
> > On 07/27/2010 10:00 AM, Konrad Rzeszutek Wilk wrote:
> > > It is paramount that we call pci_xen_swiotlb_detect before
> > > pci_swiotlb_detect as both implementations use the 'swiotlb'
> > > and 'swiotlb_force' flags. The pci-xen_swiotlb_detect inhibits
> > > the swiotlb_force and swiotlb flag so that the native SWIOTLB
> > > implementation is not enabled when running under Xen.
> > > 
> > > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
> > > Acked-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>
> > > Cc: FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
> > > Cc: Albert Herranz <albert_herranz@...oo.es>
> > > Cc: Ian Campbell <Ian.Campbell@...rix.com>
> > > Cc: Thomas Gleixner <tglx@...utronix.de>
> > > Cc: "H. Peter Anvin" <hpa@...or.com>
> > > Cc: x86@...nel.org
> > > Cc: Jesse Barnes <jbarnes@...tuousgeek.org>
> > > ---
> > >  arch/x86/kernel/pci-dma.c |    7 +++++--
> > >  1 files changed, 5 insertions(+), 2 deletions(-)
> > > 
> > 
> > Is there any way we can abstract this out a bit more instead of crapping
> > on generic code?

I don't like this change much too, however I think that this is the
most simple and straightforward.

Basically, Xen's swiotlb works like a new IOMMU implementation so we
need to initialize it like other IOMMU implementations (call the
detect and init functions in order).


> I was toying with something like this:
> 
> diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
> index 9f07cfc..e0cd388 100644
> --- a/arch/x86/kernel/pci-dma.c
> +++ b/arch/x86/kernel/pci-dma.c
> @@ -45,6 +45,25 @@ int iommu_detected __read_mostly = 0;
>   */
>  int iommu_pass_through __read_mostly;
>  
> +initcall_t __swiotlb_initcall_detect[] =
> +	{pci_xen_swiotlb_detect,
> +	 pci_swiotlb_detect,
> +	NULL};
> +
> +initcall_t __swiotlb_initcall_init[] = {
> +	pci_xen_swiotlb_init,
> +	pci_swiotlb_init,
> +	NULL};
> +
> +
> +initcall_t __iommu_initcall_detect[] = {
> +	gart_iommu_hole_init,
> +	detect_calgary,
> +	detect_intel_iommu,
> +	/* needs to be called after gart_iommu_hole_init */
> +	amd_iommu_detect,
> +	NULL};

I really don't think that this makes the code better. I prefer the
current simple (dumb) code.


>  /* Dummy device used for NULL arguments (normally ISA). */
>  struct device x86_dma_fallback_dev = {
>  	.init_name = "fallback device",
> @@ -130,24 +149,22 @@ static void __init dma32_free_bootmem(void)
>  
>  void __init pci_iommu_alloc(void)
>  {
> +	initcall_t *fn;
> +
>  	/* free the range so iommu could get some range less than 4G */
>  	dma32_free_bootmem();
>  
> -	if (pci_xen_swiotlb_detect() || pci_swiotlb_detect())
> -		goto out;
> -
> -	gart_iommu_hole_init();
> -
> -	detect_calgary();
> +	/* First do the SWIOTLB - if they work, skip the IOMMUs. */

btw, this comment is wrong. We check if we are forced to use SWIOTLB
by kernel command line here.

Even if SWIOTLB works, we see if hardware IOMMU is available. SWIOTLB
is a last resort. We prefer hardware IOMMU.
--
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/