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:	Tue, 25 Mar 2014 12:39:39 -0400
From:	Christopher Covington <cov@...eaurora.org>
To:	Arnd Bergmann <arnd@...db.de>
CC:	linux-arm-kernel@...ts.infradead.org,
	Catalin Marinas <catalin.marinas@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Russell King <linux@....linux.org.uk>,
	Jonathan Austin <Jonathan.Austin@....com>,
	Nicolas Pitre <nico@...aro.org>
Subject: Re: [PATCH] ARM: Use 64-bit DMA addresses for LPAE+VirtIO-MMIO

Hi Arnd,

On 03/21/2014 07:52 PM, Arnd Bergmann wrote:
> On Friday 21 March 2014 23:27:24 Catalin Marinas wrote:
>> On 21 Mar 2014, at 19:44, Christopher Covington <cov@...eaurora.org> wrote:
>>> On 03/21/2014 12:27 PM, Catalin Marinas wrote:
>>>>> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
>>>>> index 1f8fed9..a62bcc9 100644
>>>>> --- a/arch/arm/mm/Kconfig
>>>>> +++ b/arch/arm/mm/Kconfig
>>>>> @@ -617,6 +617,7 @@ config ARM_LPAE
>>>>>     bool "Support for the Large Physical Address Extension"
>>>>>     depends on MMU && CPU_32v7 && !CPU_32v6 && !CPU_32v5 && \
>>>>>             !CPU_32v4 && !CPU_32v3
>>>>> +   select ARCH_DMA_ADDR_T_64BIT if VIRTIO_MMIO
>>>>
>>>> That's the wrong place to enable ARCH_DMA_ADDR_T_64BIT. Do you have a
>>>> platform with >32-bit physical address space? If yes, it should be
>>>> selected there.
>>>
>>> The platforms I'm currently using are models like the Versatile Express
>>> RTSM/FVP. I can respin with changes to ARCH_VEXPRESS and ARCH_VIRT instead.
>>
>> But do you use RAM beyond 32-bit on such models?
> 
> I think the more important question here is what the normal behavior is
> for these platforms. I believe in most cases you don't have RAM above
> the boundary, so we should not enable the option by default as it can
> have noticeable overhead (we'd turn it on all the time if it didn't).

I don't understand why people concerned with the overhead of 64-bit pointers
to memory are turning on LPAE.

> In either case, platforms that need this support can always
> 'select' it, while a kernel built only for platforms that don't
> need it can offer this as a user-selectable option.

I was hoping to fix the issue of things mysteriously breaking at runtime,
regardless of what the user or randconfig selects. I'll have to investigate
the details, but it seems like one could enforce zone DMA at run-time if the
memory size is greater than the DMA pointers are able to address.

Thanks,
Christopher

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.
--
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