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. > > > >
