On 2020/7/21 下午9:44, Peter Maydell wrote:
On Tue, 21 Jul 2020 at 14:21, Jason Wang <jasow...@redhat.com> wrote:
On 2020/7/21 下午8:31, Peter Maydell wrote:
On Wed, 15 Jul 2020 at 09:36, Jason Wang <jasow...@redhat.com> wrote:
I think the point is to make DMA to MMIO work as real hardware.
I wouldn't care to give a 100% guarantee that asking a real
h/w device to DMA to itself didn't cause it to misbehave :-)
It's more likely to happen-to-work because the DMA engine bit
of a real h/w device is going to be decoupled somewhat from
the respond-to-memory-transactions-for-registers logic, but
it probably wasn't something the designers were actively
thinking about either...
I think some device want such peer to peer transactions:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/driver-api/pci/p2pdma.rst
That's a device DMAing to another device, not DMAing to *itself*
(device-to-another-device DMA should work fine in QEMU). And only
a very few devices will ever be sensible targets of the DMA --
basically things like nvme that have a looks-like-memory area,
or special cases like doorbell registers.
Well, my understanding is:
- it's not about whether or not we have an actual device that can do DMA
into itself but whether it's allowed by PCI spec
- it's not really matter whether or not it tries to DMA into itself.
Devices could be taught to DMA into each other's RX:
e1000e(1) RX DMA to e1000e(2) MMIO (RX)
e1000e(2) RX DMA to e1000e(1) RX
So we get re-reentrancy again.
Yeah, this is the interesting part for QEMU. How should we
structure devices that do DMA so that we can be sure that
the device emulation at least doesn't crash? We could have
a rule that all devices that do DMA must always postpone
all of that DMA to a bottom-half, but that's a lot of
refactoring of a lot of device code...
It looks to me the issue happens only for device with loopback
I think in principle we have a problem for any device that
(a) has memory mapped registers and (b) does DMA reads
whose address is guest-controlled. Loopback isn't a
requirement -- if the guest programs, say, an RX descriptor
base address to point at the device's own registers, you
get exactly the same kind of unexpected-reentrancy.
Right, so about the solution, instead of refactoring DMA I wonder we can
simply detect and fail the RX by device itself.
Thanks
thanks
-- PMM