From mboxrd@z Thu Jan 1 00:00:00 1970 From: Samuel Thibault Subject: Re: Bootstrap in mini-os Date: Thu, 26 Jun 2008 23:49:33 +0100 Message-ID: <20080626224933.GG4628@implementation> References: <7F0FB2108857B5449321AEA91CF47903185A6F6F68@hkgmail01.lsi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline In-Reply-To: <7F0FB2108857B5449321AEA91CF47903185A6F6F68@hkgmail01.lsi.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Jayaraman, Bhaskar" Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org Jayaraman, Bhaskar, le Fri 27 Jun 2008 02:55:58 +0800, a =E9crit : > 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 als= o the mini-os kernel text loads itself at virtual address 0x00 as directe= d 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 mention= ed 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 et= c) */ > start_pfn =3D PFN_UP(to_phys(start_info.pt_base)) + > start_info.nr_pt_frames + 3; >=20 > If so why is the text virtual address being deducted from bootstrap pag= e 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-o= s. > 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 mi= ni-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 h= ypervisor? > HYPERVISOR_update_va_mapping( > (unsigned long)shared_info, __pte(pa | 7), UVMF_INVLPG) 7 =3D=3D _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! :-) =20 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