From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Leif Lindholm <leif.lindholm@linaro.org>,
Ryan Harkin <ryan.harkin@linaro.org>,
Jeremy Linton <jeremy.linton@arm.com>
Cc: edk2-devel-01 <edk2-devel@lists.01.org>
Subject: Re: [PATCH v2 3/4] ArmPkg/ArmDmaLib: clean up abuse of device address
Date: Tue, 15 Nov 2016 10:19:54 +0100 [thread overview]
Message-ID: <CAKv+Gu_ZmFkfECvHjNdGTV0h5FFupZWPP2tAwGe5R54EPXzkjw@mail.gmail.com> (raw)
In-Reply-To: <20161114151614.GR27644@bivouac.eciton.net>
On 14 November 2016 at 16:16, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> On Sat, Nov 12, 2016 at 02:02:27PM +0100, Ard Biesheuvel wrote:
>> In preparation of adding support to ArmDmalib for DMA bus masters whose
>> view of memory is offset by a constant compared to the CPU's view, clean
>> up some abuse of the device address.
>>
>> The device address is not defined in terms of the CPU's address space,
>> and so it should not be used in CopyMem () or cache maintenance operations
>> that require a valid mapping. This not only applies to the above use case,
>> but also to the DebugUncachedMemoryAllocationLib that unmaps the
>> primary, cached mapping of an allocation, and returns a host address
>> which is an uncached alias offset by a constant.
>>
>> Since we should never access the device address from the CPU, there is
>> no need to record it in the MAPINFO struct. Instead, record the buffer
>> address in case of double buffering, since we do need to copy the contents
>> (in case of a bus master write) and free the buffer (in all cases) when
>> DmaUnmap() is called.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>
> For the fix itself:
> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
>
> However, can we wait for a few Tested-by:s to ensure this fix does not
> reveal any companion bugs?
>
Perhaps, yes.
In case anyone is up to doing that, please find the branch here
https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/log/?h=armdmalib-offset
However, given that the split CPU/bus master view is introduced in the
next patch, the only use case where the device address differs from
the host address is when using the DebugUncachedMemoryAllocationLib,
which is currently broken AFAICT (it attempts to unmap the linear
mapping of the allocation by setting the memory attributes to '0',
which triggers an assert in the ArmPkg MMU code)
next prev parent reply other threads:[~2016-11-15 9:19 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-12 13:02 [PATCH v2 0/4] ArmPkg: more ArmDmaLib fixes Ard Biesheuvel
2016-11-12 13:02 ` [PATCH v2 1/4] ArmPkg/ArmDmaLib: use DMA buffer alignment from CPU arch protocol Ard Biesheuvel
2016-11-14 15:18 ` Leif Lindholm
2016-11-12 13:02 ` [PATCH v2 2/4] ArmPkg/ArmDmaLib: fix incorrect device address of double buffer Ard Biesheuvel
2016-11-14 15:13 ` Leif Lindholm
2016-11-12 13:02 ` [PATCH v2 3/4] ArmPkg/ArmDmaLib: clean up abuse of device address Ard Biesheuvel
2016-11-14 15:16 ` Leif Lindholm
2016-11-15 9:19 ` Ard Biesheuvel [this message]
2016-11-15 11:34 ` Ryan Harkin
2016-11-15 13:07 ` Ard Biesheuvel
2016-11-15 18:01 ` Leif Lindholm
2016-11-30 16:45 ` Leif Lindholm
2016-11-12 13:02 ` [PATCH v2 4/4] ArmPkg/ArmDmaLib: add support for fixed host-to-device DMA offset Ard Biesheuvel
2016-11-14 15:17 ` Leif Lindholm
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAKv+Gu_ZmFkfECvHjNdGTV0h5FFupZWPP2tAwGe5R54EPXzkjw@mail.gmail.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox