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). -- error compiling committee.c: too many arguments to function
