WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Question about linear mapping of shadow page tables for

To: Abe Petrov <abe.petrov@xxxxxxxxx>
Subject: Re: [Xen-devel] Question about linear mapping of shadow page tables for 64bit HVM guest
From: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Date: Mon, 23 Nov 2009 10:28:52 +0000
Cc: "gianluca.guida@xxxxxxxxxxxxx" <gianluca.guida@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 23 Nov 2009 02:29:19 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <ee81c6150911211038l6587797eh39b4828d7aad8e35@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <ee81c6150911211038l6587797eh39b4828d7aad8e35@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.18 (2008-05-17)
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

<Prev in Thread] Current Thread [Next in Thread>