[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Question about linear mapping of shadow page tables for 64bit HVM guest
Thank you for your explanation, Tim. Abe. On Mon, Nov 23, 2009 at 5:28 AM, Tim Deegan <Tim.Deegan@xxxxxxxxxx> wrote: > Hi, > > At 18:38 +0000 on 21 Nov (1258828734), Abe Petrov wrote: >> Linear mapping of shadow page tables is used to find shadow PTEs that >> map a given guest VA. If I understand the following macros correctly >> >> #define __sh_linear_l1_table ((shadow_l1e_t *)(SH_LINEAR_PT_VIRT_START)) >> #define __sh_linear_l2_table ((shadow_l2e_t *) >> \ >> (__sh_linear_l1_table + >> shadow_l1_linear_offset(SH_LINEAR_PT_VIRT_START))) >> >> there is an overlap between L1 and L2 (also L3 and L4) tables. That >> creates potential conflicts between different guest VAs. >> >> For example L1 shadow PTE for guest VA1 = 0x818000000000 (the same as >> SH_LINEAR_PT_VIRT_START) coincides with L2 shadow PTE for the guest >> VA2 = 0x0. So updating L1 shadow PTE for guest VA1 would overwrite L2 >> shadow PTE for the guest VA2. >> >> What am I missing? > > You're missing the comment just above that code, and the > non-'__'-prefixed linear pagetable accessors just below. :) > HVM shadow linear accesses don't actually use those macros. > > For PV guests, SH_LINEAR_PT_VIRT_START is in the VA range reserved for > Xen, so linear accesses to the shadows just use normal linear > pagetables, including accessing l2es through the subset of the l1 linear > map that covers SH_LINEAR_PT_VIRT_START (and so recursively to l3es and > l4es). The only reason we have a separate VA range and macro set for > shadow linear pagetables is that we had to preserve the semantics of the > original LINEAR_PT_VIRT_START linear map, which maps the guest's actual > pagetable entries, not the shadows. > > For HVM guests, since the shadows themselves don't have a linear mapping > established in an l4e, we have to use the monitor pagetables' > self-linear mapping to recurse as many times as we need, and the > shadow-linear mapping only once - that is, the l2e linear map is > __linear_l1_table + shadow_l1_linear_offset(SH_LINEAR_PT_VIRT_START)), not > __sh_linear_l1_table + shadow_l1_linear_offset(SH_LINEAR_PT_VIRT_START)). > >> Sorry for the novice question. > > Not at all -- linear pagetables are mind-twisting enough without having > three sets of pagetables involved at once. :) It helps if you think > about (LINEAR_PT_VIRT_START >> 39) and (SH_LINEAR_PT_VIRT_START >> 39) > as the indexes of the two entries in the monitor l4 table that point to > the monitor l4 itself and the shadow l4 respectively; then construct the > trie path that ends at the shadow pagtetable entry you want, and think > about what the VA that causes the MMU to take that path would look like. > > Cheers, > > Tim. > >> Thank you, >> >> Abe. >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@xxxxxxxxxxxxxxxxxxx >> http://lists.xensource.com/xen-devel > > -- > Tim Deegan <Tim.Deegan@xxxxxxxxxx> > Principal Software Engineer, Citrix Systems (R&D) Ltd. > [Company #02300071, SL9 0DZ, UK.] > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |