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, 1 Apr 2009 17:01:23 -0400
From:	"Herrera-Bendezu, Luis" <lherrera@...ris.com>
To:	"Hans J. Koch" <hjk@...utronix.de>
Cc:	<linux-kernel@...r.kernel.org>
Subject: RE: UIO: uio_mem does not handle devices above 4 GB address

Hans, 

-----Original Message-----
From: Hans J. Koch [mailto:hjk@...utronix.de] 
Sent: Wednesday, April 01, 2009 4:11 PM
To: Herrera-Bendezu, Luis
Cc: linux-kernel@...r.kernel.org
Subject: Re: UIO: uio_mem does not handle devices above 4 GB address


On Wed, Apr 01, 2009 at 01:20:49PM -0400, Herrera-Bendezu, Luis wrote:
>> I am working on a PPC440EPx board with some FPGAs located at
>> addresses above 4 GB

> That's not exactly a good idea on a 32-bit processor. Can't you remap
> that chip select to a decent address?
Well PPC440EPx implements a 32-bit effective address (EA) space. EA
is expanded into virtual address and then translated to 33-bit (8 GB)
real address by the MMU so real addresses > 4 GB are valid and used by
this CPU.

>> and kernel version 2.6.28.7. The UIO driver is
>> used to access the FPGAs. I get following error when trying to read
>> FPGA registers:
>> Machine check in kernel mode.
>> Data Read PLB Error
>> 
>> The problem is traced to member addr in struct uio_mem:
>> struct uio_mem {
>>     unsigned long     addr;
>>     unsigned long     size;
>>     int               memtype;
>>     void __iomem      *internal_addr;
>>     struct uio_map    *map;
>> };
>> 
>> When UIO_MEM_PHYS is used with device address > 32-bit then
>> uio_mmap_physical() remaps address using idev->info->mem[mi].addr
>> thus loosing high address bits.
>> 
>> One way to solve this problem is to change addr member to:
>>     phys_addr_t       addr;

> That alone won't solve the problem.

>> 
>> and modify corresponding attributes in uio.c. Only concern is that
>> uio_vma_fault() calls virt_to_page() and vmalloc_to_page() where both
>> have addr arg (unsigned long) and (const void *) respectively for
>> powerpc. But these functions are only used for UIO_MEM_LOGICAL and
>> UIO_MEM_VIRTUAL.

> That probably won't work without large modifications.
Can you elaborate a little more on the mods needed?

>> 
>> Any alternative approach?

> Yes, fix your hardware design.
As described above this CPU can to address up to 8 GB.
>
> Thanks,
> Hans

Thanks,
Luis
--
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