| Message ID | 20200904154439.643272-1-philmd@redhat.com |
|---|---|
| Headers | show |
| Series | dma: Let the DMA API take MemTxAttrs argument and propagate MemTxResult | expand |
This series is fully review. Paolo, does it belong to your tree? 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. > > [*] https://www.mail-archive.com/qemu-block@nongnu.org/msg72924.html > > Klaus Jensen (1): > pci: pass along the return value of dma_memory_rw > > Philippe Mathieu-Daudé (12): > docs/devel/loads-stores: Add regexp for DMA functions > dma: Document address_space_map/address_space_unmap() prototypes > dma: Let dma_memory_set() propagate MemTxResult > dma: Let dma_memory_rw() propagate MemTxResult > dma: Let dma_memory_read() propagate MemTxResult > dma: Let dma_memory_write() propagate MemTxResult > 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 > > docs/devel/loads-stores.rst | 2 + > include/hw/pci/pci.h | 7 +- > include/hw/ppc/spapr_vio.h | 11 ++- > include/sysemu/dma.h | 156 +++++++++++++++++++++++++++------- > dma-helpers.c | 16 ++-- > hw/arm/musicpal.c | 13 +-- > hw/arm/smmu-common.c | 3 +- > hw/arm/smmuv3.c | 14 +-- > hw/core/generic-loader.c | 3 +- > hw/display/virtio-gpu.c | 8 +- > hw/dma/pl330.c | 12 ++- > hw/dma/sparc32_dma.c | 16 ++-- > hw/dma/xlnx-zynq-devcfg.c | 6 +- > hw/dma/xlnx_dpdma.c | 10 ++- > hw/hyperv/vmbus.c | 8 +- > hw/i386/amd_iommu.c | 16 ++-- > hw/i386/intel_iommu.c | 28 +++--- > hw/ide/ahci.c | 9 +- > hw/ide/macio.c | 2 +- > hw/intc/spapr_xive.c | 3 +- > hw/intc/xive.c | 7 +- > hw/misc/bcm2835_property.c | 3 +- > hw/misc/macio/mac_dbdma.c | 10 ++- > hw/net/allwinner-sun8i-emac.c | 21 +++-- > hw/net/ftgmac100.c | 25 ++++-- > hw/net/imx_fec.c | 32 ++++--- > hw/nvram/fw_cfg.c | 12 ++- > hw/pci-host/pnv_phb3.c | 5 +- > hw/pci-host/pnv_phb3_msi.c | 9 +- > hw/pci-host/pnv_phb4.c | 7 +- > hw/sd/allwinner-sdhost.c | 14 +-- > hw/sd/sdhci.c | 35 +++++--- > hw/usb/hcd-dwc2.c | 8 +- > hw/usb/hcd-ehci.c | 6 +- > hw/usb/hcd-ohci.c | 28 +++--- > hw/usb/libhw.c | 3 +- > hw/virtio/virtio.c | 6 +- > 37 files changed, 385 insertions(+), 189 deletions(-) >
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? Thanks, Phil.
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? > > Thanks, > > Phil. > Hi, 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. Cheers, Edgar <div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 16 Sep 2020, 15:48 Philippe Mathieu-Daudé, <<a href="mailto:philmd@redhat.com">philmd@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 9/4/20 5:44 PM, Philippe Mathieu-Daudé wrote:<br> > Salvaging cleanups patches from the RFC series "Forbid DMA write<br> > accesses to MMIO regions" [*], propagating MemTxResult and<br> > adding documentation.<br> > <br> > Philippe Mathieu-Daudé (12):<br> > dma: Let dma_memory_valid() take MemTxAttrs argument<br> > dma: Let dma_memory_set() take MemTxAttrs argument<br> > dma: Let dma_memory_rw_relaxed() take MemTxAttrs argument<br> > dma: Let dma_memory_rw() take MemTxAttrs argument<br> > dma: Let dma_memory_read/write() take MemTxAttrs argument<br> > dma: Let dma_memory_map() take MemTxAttrs argument<br> <br> Talking with Laszlo, he wonders if we shouldn't enforce setting<br> MemTxAttrs attrs.secure = 0 in these calls.<br> <br> Is there a concept of "secure DMA controller" in QEMU?<br> <br> Thanks,<br> <br> Phil.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Hi, </div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Cheers,</div><div dir="auto">Edgar </div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div></div>
On 9/4/20 11:44 AM, Philippe Mathieu-Daudé wrote: > Salvaging cleanups patches from the RFC series "Forbid DMA write > accesses to MMIO regions" [*], propagating MemTxResult and > adding documentation. > > [*] https://www.mail-archive.com/qemu-block@nongnu.org/msg72924.html > > Klaus Jensen (1): > pci: pass along the return value of dma_memory_rw > Paolo is on PTO. Are we waiting for him to merge this?
On 9/23/20 5:24 PM, John Snow wrote: > On 9/4/20 11:44 AM, Philippe Mathieu-Daudé wrote: >> Salvaging cleanups patches from the RFC series "Forbid DMA write >> accesses to MMIO regions" [*], propagating MemTxResult and >> adding documentation. >> >> [*] https://www.mail-archive.com/qemu-block@nongnu.org/msg72924.html >> >> Klaus Jensen (1): >> pci: pass along the return value of dma_memory_rw >> > > Paolo is on PTO. Are we waiting for him to merge this? I think so. This series now needs a rebase due to a change in hw/display/virtio-gpu.c. I'll respin when Paolo is back (or someone willing to queue this). Regards, Phil.