On Wed, Sep 19, 2012 at 03:12:12PM +0300, Avi Kivity wrote: > On 09/19/2012 02:46 PM, Edgar E. Iglesias wrote: > > On Wed, Sep 19, 2012 at 10:55:30AM +0300, Avi Kivity wrote: > >> On 09/19/2012 07:40 AM, Peter Crosthwaite wrote: > >> > On Wed, Sep 19, 2012 at 2:32 PM, Edgar E. Iglesias > >> > <edgar.igles...@gmail.com> wrote: > >> >> On Wed, Sep 19, 2012 at 02:25:48PM +1000, Peter Crosthwaite wrote: > >> >>> Ping for PMM, > >> >>> > >> >>> This is the root case of your block on the SDHCI series - this is a > >> >>> discussion on resolution to bogus infinite looping DMA. For current > >> >>> participants in this discussion, heres our thread on the same topic > >> >>> over in SD land: > >> >>> > >> >>> http://lists.gnu.org/archive/html/qemu-devel/2012-08/msg01017.html > >> >>> > >> >>> With the findings here and acknowledgement that this is a general > >> >>> problem, we either need to declare this issue of scope for SDHCI, or > >> >>> work with these guys (in the immediate future) on the DMA infinite > >> >>> loop problem flagged here. I dont mind if SDHCI+ADMA is the guinea pig > >> >>> here, but can we get a decisive plan for going forward with this issue > >> >>> if it is going to continue to block SDHCI. > >> >>> > >> >>> Thanks to Igor for identifying the overlap between these discussions. > >> >> > >> >> Hi, > >> >> > >> >> A couple of dumb questions. > >> >> > >> >> What is the reason for the blocker? that possible guest dos is worse > >> >> than no functionality at all? > >> >> > >> >> Can't you put the DMA/IO processing into the background? > >> > > >> > I dont know a way do do asynchronous DMA unless I am missing something > >> > here. > >> > >> You could schedule a bottom half and do the accesses from there. Solves > >> nothing though. > >> > >> > So what happens is we have a device that walks a SG list > >> > synchronously while holding all the locks and stuff being discussed > >> > here. If that SG list infinite loops then crash. > >> > >> Did you mean loop, or recursion into the memory region that initiates DMA? > > > > I think we were discussing the loop issue (I hadn't thought of recursion > > issues before) :) > > > > Jan's point of resetability was interesting. > > > > Processing a finite amount of dma descriptors and scheduling bh's > > to continously get back and continue processing should be OK no? > > > > Yes. > > > That would avoid the lockups and allow the device to be reset at > > any time. Or am I missing something? > > > > Not that I can see. If real hardware can be looped, so can qemu. I'm > only worried about recursion and deadlocks (while real hardware can > deadlock, we'd prefer to avoid that).
Agreed, thanks