[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 00/13] dma: Let the DMA API take MemTxAttrs argument and prop

From: Edgar E. Iglesias
Subject: Re: [PATCH 00/13] dma: Let the DMA API take MemTxAttrs argument and propagate MemTxResult
Date: Thu, 17 Sep 2020 01:10:28 +0200

On Wed, 16 Sep 2020, 15:48 Philippe Mathieu-Daudé, <philmd@redhat.com> wrote:
On 9/4/20 5:44 PM, Philippe Mathieu-Daudé wrote:
> Salvaging cleanups patches from the RFC series "Forbid DMA write
> accesses to MMIO regions" [*], propagating MemTxResult and
> adding documentation.
> Philippe Mathieu-Daudé (12):
>   dma: Let dma_memory_valid() take MemTxAttrs argument
>   dma: Let dma_memory_set() take MemTxAttrs argument
>   dma: Let dma_memory_rw_relaxed() take MemTxAttrs argument
>   dma: Let dma_memory_rw() take MemTxAttrs argument
>   dma: Let dma_memory_read/write() take MemTxAttrs argument
>   dma: Let dma_memory_map() take MemTxAttrs argument

Talking with Laszlo, he wonders if we shouldn't enforce setting
MemTxAttrs attrs.secure = 0 in these calls.

Is there a concept of "secure DMA controller" in QEMU?




Yes, we have models of secure DMA devices out of tree. Actually, on the ZynqMP and Versal SoCs, there are secure registers that can configure any DMA device to issue secure or non-secure transactions at runtime. We just haven't modelled all of the control regs that allow that in upstream QEMU.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]