On 2020/7/21 下午8:31, Peter Maydell wrote:
> On Wed, 15 Jul 2020 at 09:36, Jason Wang <email address hidden> 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:
>
>> For
>> e1000e and other networking devices we need make sure such DMA doesn't
>> break anything.
> 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
Simply git grep loopback in hw/net tells me we probably need only to
audit dp8393x and rtl8139.
On 2020/7/21 下午8:31, Peter Maydell wrote: to-memory- transactions- for-registers logic, but
> On Wed, 15 Jul 2020 at 09:36, Jason Wang <email address hidden> 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-
> 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/Documentat ion/driver- api/pci/ p2pdma. rst
>
>> For
>> e1000e and other networking devices we need make sure such DMA doesn't
>> break anything.
> 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
Simply git grep loopback in hw/net tells me we probably need only to
audit dp8393x and rtl8139.
Qiang, want to help to audit those devices?
Thanks
>
> thanks
> -- PMM
>