On Thu, 3 Sep 2020 at 14:37, Laszlo Ersek <[email protected]> wrote: > Peter mentions an approach at the end of > <https://bugs.launchpad.net/qemu/+bug/1886362/comments/5> that I believe > to understand, but -- according to him -- it seems too much work.
It also would only be effective for MMIO, not for qemu_irq lines... > I don't think such chains work unto arbitrary depths on physical > hardware either. Real hardware by and large doesn't get designed with this kind of DMA-to-self as a consideration either, but unfortunately it's not really very useful as a model to base QEMU's behaviour on: (1) real hardware is usually massively parallel, so the logic that handles incoming MMIO is decoupled anyway from logic that does outgoing DMA. (Arguably the "do all DMA in a bottom-half" idea is kind of following the hardware design.) Similarly simple "raise this outbound signal" logic just works as an instantaneous action that causes the device on the other end to change its state/do something parallel, whereas for QEMU we need to actually call some code in the device on the other end and so we serialize this stuff, sandwiching a bit of "device B code" in the middle of a run of "device A code". So a lot more of this stuff "just happens to work" on h/w than we get with QEMU. (2) if software running on real h/w does do something silly with programming a device to DMA to itself then the worst case is generally that they manage to wedge that device (or the whole machine, if you're really unlucky), in which case the response is "don't do that then". There isn't the same "guest code can escape the VM" security boundary that QEMU needs to guard against [*]. [*] I do wonder about hardware-device-passthrough setups; I don't think I would care to pass through an arbitrary device to an untrusted guest... thanks -- PMM
