[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] RE: [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? -Xin _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |