[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH V13 4/7] xen/arm: Data abort exception (R/W) mem_events.



Hi Ian,

On 12/03/15 15:35, Ian Campbell wrote:
> On Thu, 2015-03-12 at 16:19 +0100, Tamas K Lengyel wrote:
>>
>>>  out:
>>                 > +    if ( flush )
>>                 > +    {
>>                 > +        flush_tlb_domain(d);
>>                 > +        iommu_iotlb_flush(d, sgfn, egfn - sgfn);
>>                 > +    }
>>                 
>>                 Is moving the flush out of the loop an independent bug
>>                 fix? If so please
>>                 do in a separate commit with a rationale in the commit
>>                 log. If it is
>>                 somehow related to the changes here then please
>>                 mention it in this
>>                 commit log, since it's a bit subtle.
>>         
>>         
>>         Right, it's not a bugfix and not required to be outside the
>>         loop, I think I just moved it because it made sense to me to
>>         flush it only once instead at every iteration. I'll place it
>>         back.
> 
>>
>> Sorry, the flush wasn't actually part of the loop to begin with. I
>> just moved it under the label out so that the TLB gets flushed when
>> the memaccess setting hypercall gets preempted. I will just set a
>> separate label for it before out so that the existing behavior is
>> preserved but the tlb is still flushed when memaccess is preempted.
> 
> I wonder why this isn't needed for the other uses of goto out, i.e. on
> the relinquish check.

relinquish is only done when the domain is destroyed. So the flush is
not strictly necessary :).


> I'm not convinced this isn't just a straight up bug. Anyone remember any
> reasoning why we don't flush on exit if any work has been done?

Actually the flush is necessary is 3 cases:
        - ALLOCATE
        - INSERT
        - REMOVE

I don't count RELINQUISH because the guest is not scheduled anymore when
it happens.

REMOVE can never fail. In the case of ALLOCATE/INSERT, we redo the
mapping (REMOVE) which will issue a flush.

So for now we are safe. But I think, in general, the flush would be
better after the out label.

It would avoid missing flushing if one day we decide to implement
preemption on more use-case (such as INSERT/ALLOCATE).

Regards,


-- 
Julien Grall

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.