Re: [Xen-devel] Bootstrap in mini-os

[Samuel Thibault <samuel.thibault@xxxxxxxxxxxxx>]

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