qemu-devel
[Top][All Lists]
Advanced

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

RE: Implementing IOMMU support for SDHCI


From: Sai Pavan Boddu
Subject: RE: Implementing IOMMU support for SDHCI
Date: Tue, 3 Mar 2020 06:05:35 +0000

Hi Peter,

> -----Original Message-----
> From: Peter Maydell <address@hidden>
> Sent: Friday, February 28, 2020 3:56 PM
> To: Sai Pavan Boddu <address@hidden>
> Cc: address@hidden; QEMU Developers <address@hidden>;
> Edgar Iglesias <address@hidden>
> Subject: Re: Implementing IOMMU support for SDHCI
> 
> On Fri, 28 Feb 2020 at 10:08, Sai Pavan Boddu <address@hidden> wrote:
> > [Sai Pavan Boddu] Our idea is to create dma helper function which can
> > also pass the MemTxAttr i.e like dma_memory_rw_attr (AddressSpace *as,
> dma_addr_t addr,
> >                                      void *buf, dma_addr_t len,
> >                                      DMADirection dir,
> >                                      MemTxAttrs attr) which needs to
> > be used in sdhci,  with "AddressSpace *as" pointing to smmu.
> 
> Yes, you want to be able to pass MemTxAttrs from devices using the dma
> APIs. (Or you could just call dma_barrier() yourself before directly using an
> address_space_* function.) Plumbing that through is straightforward.
> 
> As an aside, we are enormously inconsistent about whether devices use
> dma_memory_* functions or just directly do address_space_* calls. I think
> the intention is that the dma_memory_* include necessary memory barriers,
> but it's not clear to me at least when the barriers are necessary or why we
> have this family of functions that some devices use and most just don't.
> 
> > I see we don’t need QOM variant of MemTxAttr for this functionality,
> >but thought it would be good to use  " object_add_link_property/
> >object_set_link_property " to set the values from machine file's.
> >I would drop this idea, and look for other options to set the attributes.
> 
> The attributes of a transaction are set by the thing generating the
> transactions (either the CPU, or the DMA device, whatever it is). Typically
> they're either fixed, or possibly configurable at a hardware level, or
> sometimes configurable by software.
> I don't think any of those scenarios are ones where you'd want the board
> model to be passing in a MemTxAttr at device creation time.
[Sai Pavan Boddu] Yeah ok, this makes sense. Only things which me might need to 
configure are master id's and trust zone settings if possible.
May be we can set them at soc emulation level i.e "hw/arm/xlnx-zynqmp.c"

Regards,
Sai Pavan
> 
> thanks
> -- PMM

reply via email to

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