|   | 
      | 
  
  
      | 
      | 
  
 
     | 
    | 
  
  
     | 
    | 
  
  
    |   | 
      | 
  
  
    | 
         
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
 
 |   
 
 | 
    | 
  
  
    |   | 
    |