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] Shadow Page Tables in Xen

To: priya sehgal <priyagps@xxxxxxxxxxx>
Subject: Re: [Xen-devel] Shadow Page Tables in Xen
From: Gianluca Guida <glguida@xxxxxxxxx>
Date: Fri, 24 Apr 2009 15:23:40 +0200
Cc: Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 24 Apr 2009 06:24:08 -0700
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=bJBuejmLtTdepJwWl22vvTZPe22xQIieaX5mlJ7e9JM=; b=kQ394Ij87ci+9tlU6mcW8+7U996J1AhT5tjY71sTKOKOfdQ6toZiG0AtTDL6eTM0JC Gs5flfxf4KZzurtB0rB2zgs+0ZKntJCE+pr2JuYvGv99z60jzwPJgZImAlMSFYElFuZT Z/eA0oLDWkiGLy9PKqmxvt5dOAJVPh9Fb8KHQ=
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=MBEGPl+qt94vkCq5DjrGkFOOvO3tUUs+yT0GA4N7ehlvJNZm1dnayab26EpTc6fv55 nCdEF/jUSrTe5Ci9wxczLKONwlb2Dlal86abLcoP0uALxXdtSsKmxY0s8M5lTEQZjRHp UaT7hFH6BB0MXplji8n/tlrmFIb9kibGJcL0c=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <873816.56715.qm@xxxxxxxxxxxxxxxxxxxxxxxxx>
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: <873816.56715.qm@xxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Fri, Apr 24, 2009 at 6:33 AM, priya sehgal <priyagps@xxxxxxxxxxx> wrote:
>> Ok that seems, but please note that at the moment shadows
>> always set the DIRTY bit (unless we're tracking a VRAM
>> address), so you might have to set the dirty bit clean when
>> propagating the shadow, which is a bit too intrusive
>> perhaps. But yes, that would work.
> I see one problem, which we might introduce by making the SPTE entries of
> all the pages in the group RW, but not marking their corresponding GPTE entry 
> as DIRTY -- if the Guest writes to a page (marked as RW in SPTE) and makes it 
> dirty, there is no way Hypervisor will know about it, and so it cannot mark 
> GPTE's entry as DIRTY. This might lead to inconsistency between the shadow 
> and guest page tables. Also, the OS running inside the guest will not see 
> correct picture about the dirty pages, thereby not flushing the dirty pages.

Yes, that's a common problem when you "prefetch" write accesses in
shadows. You can just set dirty (as in log_dirty) pages that have
guest's ptes dirty. Of course you must be very careful in case you
have an entry coming from a splintered L1 in shadow (that is the guest
sets the PSE bit) because in that case you have to check at the guest
L2 (guest PDE level) the dirty bit.

Anyway, I think it's kind of clear that I was trying to convince you
to the idea of getting rid of shadow_blow_tables at each log dirty
cleanup, since this feature you have in mind is both intrusive and
very specific, and perhaps not worth it. Of course, you might prove my
non-proved assumption wrong. :)


It was a type of people I did not know, I found them very strange and
they did not inspire confidence at all. Later I learned that I had been
introduced to electronic engineers.
                                                  E. W. Dijkstra

Xen-devel mailing list

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