vmalloc_to_pfn在Linux 32系统上返回32位地址.为什么要砍掉PAE物理地址的较高位? [英] vmalloc_to_pfn returns 32 bit address on Linux 32 system. Why does it chop off higher bits of PAE physical address?

问题描述

我正在使用 vmalloc_to_pfn()获取32位PAE Linux系统上的物理地址.看起来vmalloc_to_pfn()返回"unsigned long"，这意味着在32位系统上为32位，在64位系统上为64位.在64位Linux上，unsigned long是64位，我没有问题.

I'm using vmalloc_to_pfn() to get the physical address on a 32-bit PAE Linux system. It looks like vmalloc_to_pfn() returns "unsigned long" which means it is 32 bit on a 32 bit system, 64 bit on a 64-bit system. On 64-bit Linux, unsigned long is 64 bit and I've no issues.

问题: 使用此功能将虚拟转换为物理:

Problem: Using this function to convert virtual to physical:

VA: 0xf8ab87fc 使用vmalloc_to_pfn的PA: 0x36f7f7fc .但我实际上期望: 0x136f7f7fc .

VA: 0xf8ab87fc PA using vmalloc_to_pfn: 0x36f7f7fc. But I'm actually expecting: 0x136f7f7fc.

物理地址介于4到5 GB之间.但是我无法获得确切的物理地址，只能得到截断的32位地址.还有另一种获取真实物理地址的方法吗?

The physical address falls between 4 to 5 GB. But I can't get the exact physical address, I only get the chopped off 32-bit address. Is there another way to get true physical address?

推荐答案

我自己正在研究此语言，并且使用32位-因此，这并不是一个确切的答案.但是仔细研究相同的内容，我可以看到vmalloc_to_pfn的来源说:

I am myself studying this, and am on 32 bit - so this is not exactly an answer. But digging through the same stuff, I can see the source for vmalloc_to_pfn says:

/*
 * Map a vmalloc()-space virtual address to the physical page frame number.
 */
unsigned long vmalloc_to_pfn(const void *vmalloc_addr)
{
        return page_to_pfn(vmalloc_to_page(vmalloc_addr));
}
EXPORT_SYMBOL(vmalloc_to_pfn);

因此，它实际上不应返回地址-它应返回页面帧号"(PFN).与此相关:

So, it should not actually return an address - it should return a "page frame number" (PFN). In relation to that:

http://www.tldp.org/LDP/tlk/mm/memory.html

再次使用上面的示例，进程Y的虚拟页面帧号1映射到物理页面帧号4，该物理页面帧号从0x8000(4 x 0x2000)开始.加0x194字节偏移量后，我们得到的最终物理地址为0x8194.

Using the above example again, process Y's virtual page frame number 1 is mapped to physical page frame number 4 which starts at 0x8000 (4 x 0x2000). Adding in the 0x194 byte offset gives us a final physical address of 0x8194.

因此，显然，应该将PFN乘以PAGE_SIZE以获得实际地址-这使它变得奇怪，您怎么会得到在Linux 32系统上返回32位地址"的信息，根本(但是话又说回来，我也不是专家-也许PFN等效于32位地址?).问题OP中一个模块的最小工作示例，以及在两个平台上进行比较的输出，都应该是有序的.

So apparently, one should multiply the PFN by PAGE_SIZE to get an actual address - which then makes it strange, how come you got "returns 32 bit address on Linux 32 system" to work at all (but then again, I'm no expert - maybe PFN is equivalent to an address for 32 bit?). Probably a minimal working example of a module in the question OP, and output on both platforms for comparison, would have been in order.

无论如何，我只是注意到您所拥有的-物理地址扩展(PAE)可能会在分页中有所作为；显然，在页面全局目录(PGD)中存储为PFN的值是特定于体系结构的，并且根据其定义不同:

In any case, I just have noticed what you have - that Physical Address Extension (PAE) may make a difference in paging; apparently, the value stored as a PFN in Page Global Directory (PGD) is architecture-specific, and is defined differently depending on it:

typedef unsigned long   pgdval_t; // arch/x86/include/asm/pgtable-2level_types.h
typedef u64     pgdval_t;  // arch/x86/include/asm/pgtable-3level_types.h
typedef unsigned long   pgdval_t; // arch/x86/include/asm/pgtable_64_types.h

总结-仅使用vmalloc_to_pfn()可能并不是获取实际地址的全部内容.

To summarize - just using vmalloc_to_pfn() is probably not the whole story in getting the physical address.

这篇关于vmalloc_to_pfn在Linux 32系统上返回32位地址.为什么要砍掉PAE物理地址的较高位?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！