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

Re: [Xen-devel] Issue policing writes from Xen to PV domain memory

>>> On 06.05.14 at 21:01, <aravindp@xxxxxxxxx> wrote:
> This happens only when the access listener first attaches to a PV domain for 
> write events. It occurs in the window between mem_access has been enabled and 
> the listener is ready to handle events. I have not seen it happen once the 
> listener starts handling events. And I have not run in to this issue with 
> execute violations. 

Which is still only describing observations, not anything leading to an
understanding of why this is happening.

> So I tried a couple of things. One was to check if the ring was full before 
> sending a write violation emanating from Xen. If the ring was full instead of 
> calling mem_access_send_req() which would end up calling schedule(),  I 
> allowed the PTE to be created with the same default permissions which would 
> then cause the pagefault to be retried indirectly giving the listener more 
> time to handle events. This way the write would be policed. This is what the 
> change looks like on top of the original patch.
> ...
> +unsigned int mem_event_check_ring_availability(struct mem_event_domain *med)
> +{
> +    int avail_req = RING_FREE_REQUESTS(&med->front_ring);
> +
> +    mem_event_ring_lock(med);
> +    avail_req = mem_event_ring_available(med);
> +    mem_event_ring_unlock(med);
> +    return avail_req;
> +}

With this it is already clear that this can't be a solution: By the time the
caller evaluates the return value, the ring may have become full.

> The other approach I took was to detect if the write violation was emanating 
> from Xen when the ring was full and sending that fact down to wait_event(). 
> If the context was Xen, then instead of calling wait(), wait_event() would 
> call process_pending_softirqs(). This is how wait_event() would look with 
> this change:
> ...

A common code change like this can only ever be acceptable if it
addresses a common problem, but definitely not to work around a
non-understood problem.

I can only repeat what I said above: You first need to understand
why the ring is (or appears to be) full. But even with that clarified
you still need to have a proper solution for the case where the ring
might end up being full for valid reasons. And as also said earlier, I
am of the opinion that the behavior regarding Xen accesses would
ideally not differ between HVM, PVH, and PV.


Xen-devel mailing list



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