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] [PATCH] Simplify paging_invlpg when flush is notrequired

To: "Tim Deegan" <Tim.Deegan@xxxxxxxxxx>, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH] Simplify paging_invlpg when flush is notrequired.
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Mon, 4 Feb 2008 21:54:26 +0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, "Li, Xin B" <xin.b.li@xxxxxxxxx>
Delivery-date: Mon, 04 Feb 2008 05:57:24 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20080204110454.GB15990@xxxxxxxxxxxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <D470B4E54465E3469E2ABBC5AFAC390F024D8F3D@xxxxxxxxxxxxxxxxxxxxxxxxxxxx><C3CB320B.13349%Keir.Fraser@xxxxxxxxxxxx> <20080204110454.GB15990@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AchnHfGjnw+TBMHpQ0+kyUMpmvPScAAFfy9w
Thread-topic: [Xen-devel] [PATCH] Simplify paging_invlpg when flush is notrequired.
>From: Tim Deegan
>Sent: 2008年2月4日 19:05
>At 08:55 +0000 on 03 Feb (1202028939), Keir Fraser wrote:
>> Is there a significant advantage to doing this? One other 
>comment is that I
>> don't like extra boolean 0/1 arguments to functions. I'd rather have
>> something like paging_invlpg() and paging_invlpg_noflush() 
>and only have the
>> boolean argument to paging.mode->invlpg().
>As someone (probably Kevin) pointed out before, the entire guest-walk
>in sh_invlpg is redundant because we maintain TLB flush discipline on
>shadow l2es ourselves.  Cleaning that up was on the list of 
>things to do
>when the out-of-sync shadows are done.  If we're going to change this
>code now, the right thing to do is to kill off sh_invlpg 
>entirely, except
>for the call to vtlb_flush().  Then there's no need for it to return a
>value at all. 

Well, I guess it should be Xin who since educated me about such
redundancy before. :-) But I'm inclined to keep this interface for several

* Shadow currently requires to intercept invlpg as what you mentioned
about vtlb and also future fast_emulation I posted before. Call those
vtlb-like invalidation inside sh_invlpg is cleaner

* I'm not sure how future out-of-sync logic may be implemented, but I
guess it may be a dynamic hook, and only active at some special 
points. If that's the case, sometimes TLB flush may be required and
others may not

But anyway, this is not important. We can also wait for out-of-sync
feature ready and then see how this interface may be affected.


Xen-devel mailing list