On Thu, 28 Mar 2019 at 11:46, Ryszard Knop <ryszard.k...@linux.intel.com> wrote: > > On Wed, 2019-03-27 at 16:32 +0100, Ard Biesheuvel wrote: > > On Tue, 29 Jan 2019 at 14:55, Ryszard Knop < > > ryszard.k...@linux.intel.com> wrote: > > > +Team > > > > > > > As it turns out, this driver is still broken for non-1:1 mapped DMA. > > > > In particular, I am hitting a crash on > > > > E1000MemCopy ( > > (UINT8 *) (UINTN) CpbReceive->BufferAddr, > > (UINT8 *) (UINTN) ReceiveDescriptor->buffer_addr, > > TempLen > > ); > > > > (around line 676 in e1000.c), which uses the DMA address > > 'ReceiveDescriptor->buffer_addr' in a memory copy operation performed > > by the CPU. This causes a crash on systems where the DMA address is > > not also a valid CPU address. > > Huh, this is new... I don't have access to any system behaving this > way, so I can't test this, but E1000.c -> E1000TxRxConfigure links > RxDesc->buffer_addr to the physical addresses, that descriptor is used > by the hardware to DMA data where needed, and we try to copy from that > same physical address later, while we should copy from unmapped > addresses instead. >
Indeed. > This probably should be solved by having a separate array/something > with CurRxInd -> unmapped addresses, but I'll have to talk with my team > to solve this in a sensible way. > > In the meantime, maybe you know if there's a way to simulate this > situation under QEMU or something? > I am using an arm64 board with modified firmware to emulate different PCIe host bridge configurations. I don't know whether QEMU has support for non-1:1 mapped DMA on x86, but it does emulate various boards (such as the raspberry pi 2 iirc) where the CPU and device addressing is not 1:1. _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
