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
|
Home