Im trying to understand a little here:
1) what is cr3 pointing to when in ring 0 i.e. when hypervisor is in control
(in a scenario when hypervisor is just booting AND when hypervisor got
control due to a hypercall ) ?
2) The memory layout mentions that 0xffff830000000000 - 0xffff87ffffffffff
[5TB, 5*2^40 bytes, PML4:262-271]
is directly mapped.
but even the calculation of kernel addresses in __pa does not involve any
page table translations. Isnt that as well directly mapped ?
3) Contrary to the above observation some room is made for xen text in
memory management module
/* Enough page directories to map the Xen text and static data. */
l3_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")))
l3_xenmap[L3_PAGETABLE_ENTRIES];
l2_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")))
l2_xenmap[L2_PAGETABLE_ENTRIES];
Am i right in thinking this is for translations without context switch
during hypercalls from VMs ?
Thanks in advance
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Hi, At 15:38 -0700 on 22 Jun (1308757083), Ashwini Bhat wrote:> Im trying to understand a little here: > > 1) what is cr3 pointing to when in ring 0 i.e. when hypervisor is in control > (in a scenario when hypervisor is just booting AND when hypervisor got > control due to a hypercall ) ?In a PV guest CR3 points to the same thing as it did just before the hypercall; Xen is mapped into every address space just like the kernel is in linux. In a HVM guest there''s a special set of pagetables for each vcpu, called the monitor tables, that contains only Xen; the hardware switches to them on vmexit. During boot, and in some other contexts there''s a special "idle" pagetable that xen can run on, again containing only Xen.> 2) The memory layout mentions that 0xffff830000000000 - 0xffff87ffffffffff > [5TB, 5*2^40 bytes, PML4:262-271] > is directly mapped. > but even the calculation of kernel addresses in __pa does not involve any > page table translations. Isnt that as well directly mapped ?Hypervisor addresses are mapped at XEN_VIRT_START; the physical addresses are laid out contiguously at xen_phys_start. See __virt_to_maddr() for the translation.> 3) Contrary to the above observation some room is made for xen text in > memory management module > /* Enough page directories to map the Xen text and static data. */ > l3_pgentry_t __attribute__ ((__section__ (".bss.page_aligned"))) > l3_xenmap[L3_PAGETABLE_ENTRIES]; > l2_pgentry_t __attribute__ ((__section__ (".bss.page_aligned"))) > l2_xenmap[L2_PAGETABLE_ENTRIES]; > > Am i right in thinking this is for translations without context switch > during hypercalls from VMs ?No; those are the L3 and L2 tables used to map the hypervisor text and data (and bss). They''re statically allocated so they can be set up before the memory allocators are initialized. The idle pagetable''s L4 table is also statically allocated, for the same reason. Tim. -- Tim Deegan <Tim.Deegan@citrix.com> Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, Jun 23, 2011 at 2:25 AM, Tim Deegan <Tim.Deegan@citrix.com> wrote:> Hi, > > At 15:38 -0700 on 22 Jun (1308757083), Ashwini Bhat wrote: > > Im trying to understand a little here: > > > > 1) what is cr3 pointing to when in ring 0 i.e. when hypervisor is in > control > > (in a scenario when hypervisor is just booting AND when hypervisor got > > control due to a hypercall ) ? > > In a PV guest CR3 points to the same thing as it did just before the > hypercall; Xen is mapped into every address space just like the kernel > is in linux. > > In a HVM guest there''s a special set of pagetables for each vcpu, called > the monitor tables, that contains only Xen; the hardware switches to > them on vmexit. > > During boot, and in some other contexts there''s a special "idle" > pagetable that xen can run on, again containing only Xen. > > > 2) The memory layout mentions that 0xffff830000000000 - > 0xffff87ffffffffff > > [5TB, 5*2^40 bytes, PML4:262-271] > > is directly mapped. > > but even the calculation of kernel addresses in __pa does not involve > any > > page table translations. Isnt that as well directly mapped ? > > Hypervisor addresses are mapped at XEN_VIRT_START; the physical > addresses are laid out contiguously at xen_phys_start. See > __virt_to_maddr() for the translation. > > > 3) Contrary to the above observation some room is made for xen text in > > memory management module > > /* Enough page directories to map the Xen text and static data. */ > > l3_pgentry_t __attribute__ ((__section__ (".bss.page_aligned"))) > > l3_xenmap[L3_PAGETABLE_ENTRIES]; > > l2_pgentry_t __attribute__ ((__section__ (".bss.page_aligned"))) > > l2_xenmap[L2_PAGETABLE_ENTRIES]; > > > > Am i right in thinking this is for translations without context switch > > during hypercalls from VMs ? > > No; those are the L3 and L2 tables used to map the hypervisor text > and data (and bss). They''re statically allocated so they can be set up > before the memory allocators are initialized. The idle pagetable''s L4 > table is also statically allocated, for the same reason. > > Tim. > > -- > Tim Deegan <Tim.Deegan@citrix.com> > Principal Software Engineer, Xen Platform Team > Citrix Systems UK Ltd. (Company #02937203, SL9 0BG) >Thats very helpful. Would like to know where can I get hold of the structure(or where should I look for) of the "idle page tables" ? and also monitor tables. Like I tried to read through the hypervisor assuming its 4 level. But after the second stage, I see 00000''s... Like is it two stage or three stage. Also, if I am not wrong in understanding, I see that for x86_64 , the page tables are 4 stage. which is to convert from pfn to mfn. Please correct me if I am wrong. Thanks. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
At 11:05 -0700 on 24 Jun (1308913517), Ashwini Bhat wrote:> Thats very helpful. Would like to know where can I get hold of the > structure(or where should I look for) of the "idle page tables" ? and also > monitor tables.At this point you''re into things that grep or ctags can tell you.> Like I tried to read through the hypervisor assuming its 4 level. But after > the second stage, I see 00000''s... > Like is it two stage or three stage. Also, if I am not wrong in > understanding, I see that for x86_64 , the page tables are 4 stage.Yes; that''s an architectural requirement. If you want to use 64-bit virtual addresses you need 64-bit page tables.> which is to convert from pfn to mfn. Please correct me if I am wrong.No; pagetables convert from virtual addresses to MFNs. For HVM guests there is a separate ''p2m'' table that holds the translation from pfn to mfn, and in some cases that''s stored in 64-bit pagetable format (because it''s convenient for the shadow pagetable code and it''s the format thet NPT uses). Tim. -- Tim Deegan <Tim.Deegan@citrix.com> Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel