Re: [PATCH edk2-staging 00/19] IntelUndiPkg/GigUndiDxe: build fixes for AARCH64/ARM/GCC

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

On Thu, 28 Mar 2019 at 11:46, Ryszard Knop <ryszard.knop@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.knop@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.