[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Shadow Page Tables in Xen


  • To: priya sehgal <priyagps@xxxxxxxxxxx>
  • 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
  • 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=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

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. :)

Thanks,
Gianluca

-- 
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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.