linux-kernel - Re: [PATCH -tip] x86: fix iommu=soft boot option

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: <4B0CF0CA.30807@kernel.org>
Date:	Wed, 25 Nov 2009 00:54:34 -0800
From:	Yinghai Lu <yinghai@...nel.org>
To:	Ingo Molnar <mingo@...e.hu>
CC:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH -tip] x86: fix iommu=soft boot option

Ingo Molnar wrote:
> * Yinghai Lu <yinghai@...nel.org> wrote:
> 
>> FUJITA Tomonori wrote:
>>> "x86: Handle HW IOMMU initialization failure gracefully" patchset
>>> handled this option properly however somehow I broke it during cleanup
>>> after that. Sorry.
>>>
>>> =
>>> From: FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
>>> Subject: [PATCH -tip] x86: fix iommu=soft boot option
>>>
>>> iommu=soft boot option forces the kernel to use swiotlb.
>>>
>>> Signed-off-by: FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
>>> ---
>>>  arch/x86/kernel/pci-swiotlb.c |    4 +++-
>>>  1 files changed, 3 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/arch/x86/kernel/pci-swiotlb.c b/arch/x86/kernel/pci-swiotlb.c
>>> index e36e71d..e3c0a66 100644
>>> --- a/arch/x86/kernel/pci-swiotlb.c
>>> +++ b/arch/x86/kernel/pci-swiotlb.c
>>> @@ -50,6 +50,8 @@ static struct dma_map_ops swiotlb_dma_ops = {
>>>   */
>>>  int __init pci_swiotlb_init(void)
>>>  {
>>> +	int use_swiotlb = swiotlb | swiotlb_force;
>>> +
>>>  	/* don't initialize swiotlb if iommu=off (no_iommu=1) */
>>>  #ifdef CONFIG_X86_64
>>>  	if (!no_iommu && max_pfn > MAX_DMA32_PFN)
>>> @@ -63,5 +65,5 @@ int __init pci_swiotlb_init(void)
>>>  		dma_ops = &swiotlb_dma_ops;
>>>  	}
>>>  
>>> -	return swiotlb_force;
>>> +	return use_swiotlb;
>>>  }
>> before your cleanup patchset:
>> for AMD 64bit, MEM > 4g, no AGP, iommu=soft
>> 1. if BIOS have correct gart setting, Kernel will use gart
>> 2. if BIOS does not have correct gart setting, Kernel will use swiotlb
>>
>> for AMD 64bit, MEM > 4g, no AGP, no "iommu=soft"
>> 1. if BIOS have correct gart setting, Kernel will use gart
>> 2. if BIOS does not have correct gart setting, Kernel will allocate some RAM, and set range in AMD NB, and use gart iommu
> 
> So the question is, how many people relied on the previous behavior of 
> 'iommu=soft' not really falling back to the swiotlb code but preventing 
> the quirk from running.
> 
> Are you aware of specific versions of distributions adding iommu=soft 
> and relying on that? Should we be careful about changing the previous 
> behavior?

only remember that SLES 9 SP3 (?) at some point has problem with AMD 10h ( quad core version)
when memory > 4 g (with USB controller ?)
because the gart code only check K8 device id, and didn't check 10h device id. so gart iommu is not used.
and happenly swiotlb code has problem with that kernel version.

thinking we should keep old behavior, until some day we can remove them all.

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