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/
Home Products Support Community News


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

To: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Subject: Re: [Xen-devel] Question about linear mapping of shadow page tables for 64bit HVM guest
From: Abe Petrov <abe.petrov@xxxxxxxxx>
Date: Tue, 24 Nov 2009 15:04:19 -0500
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 24 Nov 2009 12:04:39 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=xZO0B4+QJ+H0QI1I1rmsZiBxCquhcqABEny03FPg0P8=; b=XuIYarr2WhX+SeW6VJ6hzKmFjdTABkFxhFqB3gQDV/eqDM6PpaJj4EVOfAt+JMFLlN V/Y5iIqk6osqK614EN+kCZGMuXjWO6ZeqhV5afwtkLGDtvW9F6CMxKkyr3Q9s14Niyuy 5ZFRaXT7CGcFV0InViqQtcV1OhpxWo79nGHTo=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qfht4JTkIm+o0jNA+c+xv+qTYvvXgzziOqKUfbxK/z2Zk+2fsGmvAUBf+bd+hErjvl NlOmvUw7h5lJbxaDXRddT0HuNufvlLJpoUk/mlnSh43h+xdA9RThkTQjAcwXOZmIFir5 ayvFBnUq5uQFr6c9EVNOUOdN6xs/p7cyMT5SI=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20091123102852.GD14284@xxxxxxxxxxxxxxxxxxxxxxx>
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> <20091123102852.GD14284@xxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thank you for your explanation, Tim.


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

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