|
|
|
|
|
|
|
|
|
|
xen-devel
[Xen-devel] RE: [PATCH][RESEND] only BSP can really do clear_all_shadow_
>>> 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
|
|
|
|
|