On 2012-09-19 06:40, 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. 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.
We could switch to async DMA, but most DMA-capable devices aren't prepared for rescheduling points in the middle of their code. This will require quite a bit of code review. > >> >> what's the diff between setup of bad descriptors and writing a >> while (1) loop in the guest CPU? >> > > While(1) in guest doesnt freeze all of QEMU (monitor still works and > stuff), wheras the DMA ops going in circles does, as locks are taken > by an infinite loop. That's the point. If we loop, we need at least a way to stop it by issuing a device or system reset. But I tend to think that detecting loops and failing/ignoring requests is easier implementable. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux
