Re: [Qemu-devel] [PATCH 08/13] iommu: Introduce IOMMU emulation infrastructure

[Benjamin Herrenschmidt]

On Tue, 2012-05-15 at 18:58 -0500, Anthony Liguori wrote:

> Even ancient PIO devices really don't block indefinitely.
> 
> > In our case (TCEs) it's a hypervisor call, not an MMIO op, so to some
> > extent it's even more likely to do "blocking" things.
> 
> Yes, so I think the right thing to do is not model hypercalls for sPAPR as 
> synchronous calls but rather as asynchronous calls.  Obviously, simply ones 
> can 
> use a synchronous implementation...
> 
> This is a matter of setting hlt=1 before dispatching the hypercall and 
> passing a 
> continuation to the call that when executed, prepare the CPUState for the 
> hypercall return and then set hlt=0 to resume the CPU.

Is there any reason not to set that hlt after the dispatch ? IE. from
within the hypercall, for the very few that want to do asynchronous
completion, do something like spapr_hcall_suspend() before returning ?

> > It would have been possible to implement a "busy" return status with the
> > guest having to try again, unfortunately that's not how Linux has
> > implemented it, so we are stuck with the current semantics.
> >
> > Now, if you think that dropping the lock isn't good, what do you reckon
> > I should do ?
> 
> Add a reference count to dma map calls and a flush_pending flag.  If 
> flush_pending && ref > 0, return NULL for all map calls.
> 
> Decrement ref on unmap and if ref = 0 and flush_pending, clear flush_pending. 
> You could add a flush_notifier too for this event.
> 
> dma_flush() sets flush_pending if ref > 0.  Your TCE flush hypercall would 
> register for flush notifications and squirrel away the hypercall completion 
> continuation.

Ok, I'll look into it, thanks. Any good example to look at for how that
continuation stuff works ?

> VT-d actually has a concept of a invalidation completion queue which delivers 
> interrupt based notification of invalidation completion events.  The above 
> flush_notify would be the natural way to support this since in this case, 
> there 
> is no VCPU event that's directly involved in the completion event.

Cheers,
Ben.

> Regards,
> 
> Anthony Liguori
> 
> > Cheers,
> > Ben.
> >
> >