|
[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |