WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

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

<Prev in Thread] Current Thread [Next in Thread>