Re: [Xen-devel] [Patch RFC 03/13] vt-d: Track the Device-TLB invalidation status in an invalidation table.

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 10.10.15 at 14:27, <quan.xu@xxxxxxxxx> wrote:
>> > >>> On 29.09.2015 at 17:24 <JBeulich@xxxxxxxx> wrote:
>> >>> On 16.09.15 at 15:23, <quan.xu@xxxxxxxxx> wrote:
>> > +        qinval_entry->q.inv_wait_dsc.hi.saddr = virt_to_maddr(
>> > +
>> &qi_table_pollslot(d)) >> 2;
>> > +        rcu_unlock_domain(d);
>> 
>> If you don't hold a reference to the domain, what prevents it from going 
>> away,
>> struct domain getting freed, and the write to the poll slot corrupting data 
>> if the
>> memory gets re-used? Plus, if you obtain a domain reference at the time you
>> enter it into domid_map[], you wouldn't have to be worried about failure 
>> above
>> (i.e. you could simply ASSERT() success of rcu_lock_domain_by_id()).
>> 
>> Considering the implementation of rcu_lock_domain_by_id() I also wonder
>> whether it wouldn't be more efficient to make domid_map[] an array of struct
>> domain pointers.
>> 
> Good catch!!
> Patch #11 can prevents it from going away.
> patch 11: 
> ##
> If the Device-TLB flush is still not completed, schedule and wait on a 
> waitqueue until the Device-TLB flush is 
> Completed, before schedule RCU asynchronous completion of domain destroy.
> ##

Not sure I understand what you're trying to tell me here: Do you
mean things are safe due to patch 11? If so, please recall that
things need to be safe after every individual patch. If not, what
exactly are you trying to say?

> And,
>  If it has got domain by rcu_lock_domain_by_id(), the domain structure is 
> protected by RCU lock from rcu_lock_domain_by_id() to 
> rcu_lock_domain_by_id().

???

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel