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


[Xen-devel] RE: [PATCH][RESEND] only BSP can really do clear_all_shadow_

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: [Xen-devel] RE: [PATCH][RESEND] only BSP can really do clear_all_shadow_status
From: "Li, Xin B" <xin.b.li@xxxxxxxxx>
Date: Fri, 21 Apr 2006 05:10:13 +0800
Cc: xen-devel Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 20 Apr 2006 14:16:02 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcZhYqvPgitWY3h8Rw+RGMd1Ajha6QDWrjlA
Thread-topic: [PATCH][RESEND] only BSP can really do clear_all_shadow_status
>>> Why can only VCPU0 do this? Is the argument to
>>> clear_all_shadow_status() always current domain? If so that should
>>> probably be asserted, or the argument removed.
>> Both Jun and I think clear_all_shadow_status is overkilled,
>> update_pagetables should have done the cleanup things, so we thought
>> about removing it, but the test shows that removing it 
>breaks windows 
>> on
>> PAE xen, and I'm looking at this issue.
>> Actually, this patch should be a right direction, and changeset 9626 
>> has
>> alrealdy changed shadow.c like what this patch does to shadow32.c.
>Okay. But weren't we going to *get rid* of shadow32.c at some 
>point? :-)
>> For long term, maybe we will move to per vcpu shadow.
>I wondered about that but wasn't convinced it'd help with scalability. 
>Fundamentally, if VCPU-A updates a guest pte that is in 
>VCPU-B's shadow 
>cache, B's shadowed version has to be modified no later than the next 
>TLB flush on VCPU-B. So there will still be potentially significant 
>synchronisation across shadow caches although maybe some cunningness 
>can avoid bad behaviour in most cases.

Yes, I thought about this issue too, but not clear yet. A good smp guest
should guarantee the consistency of TLB, so we can make them consistent
in per-vcpu shadow?

Xen-devel mailing list

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