Re: [Xen-ia64-devel] [PATCH]: vcpu_match_tr_entry & vcpu_ptc_ga

[Isaku Yamahata <yamahata@xxxxxxxxxxxxx>]

Hi Tristan.

In fact traversing p2m tables (domain->arch.mm) is also racy.
There are readers and writers of p2m tables so that
access of p2m tables also must be protected somehow.
I haven't dug into this SMP issue so I'm not sure that
a smart way other than locking is possible.

Just a thought.
According to SDM only single ptc.ga must be issued at a time
otherwise the result is undefined. Is it exploited?

thanks

On Fri, Mar 31, 2006 at 10:43:48AM +0100, Tristan Gingold wrote:
> Thank you for your comments.
> 
> The race condition you pointed is in fact for ia64_do_page_fault:
> 
>       fault = vcpu_translate(current,address,is_data,0,&pteval,&itir,&iha);
>       if (fault == IA64_NO_FAULT) {
>               pteval = translate_domain_pte(pteval,address,itir);
>               
> vcpu_itc_no_srlz(current,is_data?2:1,address,pteval,-1UL,(itir>>2)&0x3f);
>               return;
>       }
> Between vcpu_translate and vcpu_itc_no_srlz, a ptc.ga must be taken into 
> account.  I am looking for other possible races, but currently I don't see 
> other race point.
> 
> The obivous solution is a lock: between these two points, the tr_purge must 
> be 
> delayed.  We could add a 'tlb_protected' field in each vcpu.
> This solution is quite simple but maybe heavy weight.
> 
> Any other solution ?
> 
> Tristan.
> 
> 
> 
> _______________________________________________
> Xen-ia64-devel mailing list
> Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-ia64-devel
> 

-- 
yamahata

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel