[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] Error accessing memory mapped by xenforeignmemory_map()



Hi,

On 31/10/2017 19:17, Brett Stahlman wrote:
> Ok. So I'm thinking the relevant address would be 0xffffffc000080000,
> which is where System.map places the kernel's "_text" segment. IIUC,
> aarch64 Linux uses 39-bit addresses in a range controlled by TTBR1,
> beginning at 0xffffff8000000000. I'm assuming the kernel's address
> space uses a direct, 1-to-1 mapping (i.e., guest virtual == guest
> physical). Correct? Also, should a signed or unsigned right shift be
> used to convert a kernel address to a pfn? I.e., would the pfn
> corresponding to 0xffffffc000080000 be 0xfffffffffc000080 or
> 0x000ffffffc000080?

The kernel does not direct map the memory (e.g guest virtual
!= guest physical). 0xffffffc000080000 would be virtual
address of the start of the kernel.

I don't think Linux is moving the kernel within the physical
address space after boot. Assuming you don't use UEFI in
the guest and you are using Xen 4.6 or later, the kernel
will be loaded at the guest physical address 0x40008000.

You can also find this information via xl create when it
is in verbose mode (xl -vvv create):

domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 
0x40008+0x7b4 at 0xffff94696000
domainbuilder: detail: xc_dom_alloc_segment:   kernel       : 0x40008000 -> 
0x407bc000  (pfn 0x40008 + 0x7b4 pages)
domainbuilder: detail: xc_dom_load_zimage_kernel: called
domainbuilder: detail: xc_dom_load_zimage_kernel: kernel seg 
0x40008000-0x407bc000

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
https://lists.xen.org/xen-users

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.