Re: [Qemu-arm] [Qemu-devel] [PATCH RFC] bcm2835_dma: add emulation of Raspberry Pi DMA controller

[Andrew Baumann]

> From: Peter Maydell [mailto:address@hidden
> Sent: Thursday, 3 March 2016 8:22 AM
> 
> On 3 March 2016 at 16:16, Gerd Hoffmann <address@hidden> wrote:
> > usb emulation has this problem too.
> >
> > uhci queue heads can go in circles.  The emulation code keeps a linked
> > list of active queue heads, which is (among other bookkeeping things)
> > used to detect when we run in circles.  It's a legal thing to do for a
> > guest btw, so you can see that happening in practice.
> >
> > until recently ehci could be tricked into running in loops too, by
> > creating a circular chain of IDTs.  Which is not legal according to
> > specs, so this went unnoticed for a while.  But a malicious guest can do
> > it nevertheless.  That one was fixed by stopping IDT processing in case
> > no data was transfered.  This is possible because the ehci controller
> > writes back the status to the IDT, so we can figure there is nothing to
> > do (because we already processed that IDT) without additional
> > bookkeeping, by simply checking the status.
> >
> > From a brief look at the patch it seems you can not use the later for
> > the bcm2835 dma controller, I can't spot a place where the some status
> > is written back to the dma contol block ...
> 
> I guess a more general approach to the problem would be to have
> a (hopefully easy) way to say "if this has been going on for too
> long then arrange to defer continued processing of it til later,
> and for now resume the guest". That's too big a can of worms for
> this patch, though. (And for something that's only used in TCG
> emulation we care much less about malicious guests than for devices
> that can be used with KVM.)

It seems like the ultimate solution here is to model the concurrency of DMA. 
Run each DMA engine as its own thread, including modelling the ability to 
pause/abort transfers, and provide some suitable scheduling/resource 
arbitration mechanism, and then you don’t need to worry about whether a guest 
can tie up one of those threads in a loop, because it can't hurt anyone else. 
Of course, this is much more complex to implement.

But in this particular case, I _really_ hope that we don't have to worry about 
virtual raspberry pi's in multi-tenant hosting! :)

Thanks for the feedback,
Andrew