| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] RE: question about shadow_blow_tables
Thanks a lot for your clarification. Now I'm clear that current solution is
safe.
Actually in the start I also doubt my suspicion, since such hole is severe and
unlikely nobody reports. So just post for your help on this part. :-)
Thanks,
Kevin
>From: Tim Deegan [mailto:Tim.Deegan@xxxxxxxxxx]
>Sent: 2007年11月27日 18:51
>
>Hi,
>
>At 18:32 +0800 on 27 Nov (1196188342), Tian, Kevin wrote:
>> Maybe I made some misunderstanding here. By comment of shadow_blow_
>> tables:
>> /* Deliberately free all the memory we can: this will tear
>down all of
>> * this domain's shadows */
>
>In this comment, "free" means only freeing as far as the
>domain's shadow
>free lists, not to domheap. Does that make more sense?
>
>> The implicit here is that all shadow pages of this domain
>will be released
>> as result. However when 'blow' is on-going on one cpu, the
>'blow-ed' pages
>> may be active on address translation on another cpu, if
>other vcpus are
>> not paused. I think anyway hardware should be prevented from walking
>> shadow pages which are torn down from another cpu...
>
>As I said, it's safe to do this concurrently with other CPUs
>reading the
>shadow pagetables, and we have the shadow lock to protect against
>concurrent writes.
>
>- other CPUs never see a half-written entry because of the logic in
> safe_write_entry().
>- l1es in other CPUs' TLBs are safe to leave until the final TLB flush
> because there's no intermediate stage mid-operation that
>requires rights
> to have been relinquished.
>- higher-level entries in other CPUs' TLBs are safe because we
>leave the
> contents of the shadow pagetables they point at alone until
>we're sure
> all the TLBs are flushed. (We never write to pages on the
>shadow free
> list and we check the TLB flush timestamps when we allocate them
> from the free list again.)
>
>Can you be clearer about what you think the risk is? If we've missed
>something then it's quite important, because it probably affects every
>other shadow operation as well.
>
>> So my question is, whether all shadow pages are indeed
>free-ed as result
>> of 'blow' option?
>
>Only as far as the free list. We never free shadow pages back to
>domheap until the allocation is changed or shadow mode is
>disabled. But
>I think it would still be safe even if we freed to domheap because the
>deferred-TLB-flush logic in page_alloc.c would do the right thing.
>
>> Or some IPI will be definitely triggered when free-ing one
>> shadow page referenced by multiple VCPUs, before final TLB flush?
>
>No. We do no synchronisation until the TLB flush at the end.
>
>Cheers,
>
>Tim.
>
>--
>Tim Deegan <Tim.Deegan@xxxxxxxxxx>
>Principal Software Engineer, Citrix Systems.
>[Company #5334508: XenSource UK Ltd, reg'd c/o EC2Y 5EB, UK.]
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home