| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Bootstrap in mini-os
Jayaraman, Bhaskar, le Fri 27 Jun 2008 02:55:58 +0800, a écrit :
> 1] I have been looking through its sources and I wanted to know what is the
> bootstrap code comprised of in Mini-os.
Things start from arch/x86/x86_32.S:_start, then see function
start_kernel.
> 2] The start_info pages seem to contain bootstrap pages in them and also the
> mini-os kernel text loads itself at virtual address 0x00 as directed by the
> lds script so does the bootstrap code come from Xen loader.
No, everything is contained in the mini-os source. All Xen does is
mapping the ELF at the virtual address given in the lds, and setup a
bootstrap page table.
> 3] Also I guess the start pfn begins after the bootstrap pfn as mentioned
> here??
See the documentation about day0 in start_info doc in xen/include/public/xen.h
In mini-os, what is called "start_pfn" is just the first pfn which is
available for data/heap/whatever.
> /* First page follows page table pages and 3 more pages (store page etc) */
> start_pfn = PFN_UP(to_phys(start_info.pt_base)) +
> start_info.nr_pt_frames + 3;
>
> If so why is the text virtual address being deducted from bootstrap page in
> to_phys ??
Because what is calculated above is not anything virtual, it's a PFN,
which are always numbered from 0, and thus you need to subtract the
VIRT_START offset.
> 4] So kernel text will reside before bootstrap code?
bootstrap code is _in_ the kernel. Have a look at an objdump -D of mini-os.
> Which is why I'm curious to know if this is part of bootloader code.
It is not.
> 5] What is being achieved by deducting the kernel text virtual address from
> the bootstrap virtual address?
What the macro says: going down from virtual address to physical
address.
> I mean why do we not want to account for that space while organizing mini-os
> memory?
Because it's easier to think of pages as starting from 0, wherever they
are virtually mapped.
> 6] Why are we Oring 7 with shared info page while mapping it with the
> hypervisor?
> HYPERVISOR_update_va_mapping(
> (unsigned long)shared_info, __pte(pa | 7), UVMF_INVLPG)
7 == _PAGE_PRESENT | _PAGE_RW | _PAGE_USER.
I guess a cleanup patch would indeed consist in replacing 7 with the OR
above.
> 7] Will this virtual address be listed in the mfn_list, the page frame list
> for this VM before this hypercall?
mfn_list does not reference virtual addresses, it lists MFNs. See the
comment in x86_32.S:
/* Unpleasant -- the PTE that maps this page is actually overwritten */
/* to map the real shared-info page! :-)
The MFN which was previously mapped at that place will still be
referenced in the mfn_list and Xen will still consider it to be
allocated to Mini-OS. Mini-OS could very well project it somewhere else,
but it doesn't for simplicity (not a big loss).
Samuel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home