Re: [Qemu-devel] Supporting multiple CPU AddressSpaces and memory transaction attributes

["Edgar E. Iglesias" <edgar.iglesias@gmail.com>]

On Wed, May 13, 2015 at 11:28:38AM +0200, Paolo Bonzini wrote:
> 
> 
> On 13/05/2015 08:41, Edgar E. Iglesias wrote:
> > I think it would be nice if address_space_translate_for_iotlb
> > was allowed to modify the attributes so that an IOMMU in front
> > of a CPU could for example down-grade a secure to a non-secure accesse
> > (once we add IOMMU support in front of CPUs). If I understood correctly
> > the memattrs would stay as a separate field in the iotlb, so this
> > would be easy to implement?
> 
> Yes, it should.
> 
> > The naive implementation I have keeps pointers to AS and the memattrs
> > in the iotlb.  address_space_translate_for_iotlb walks any IOMMU
> > translate() fns, if it hits a RAM it returns the host addr as usual.
> 
> How is the TLB invalidated on IOMMU changes?

Hi Paolo,

I have a hack in the iommu model that triggers an AS change and
makes the CPU flush it's TLB:

        memory_region_notify_iommu(&s->masters[i].iommu, entry);
        /* Temporary hack.  */
        memory_region_transaction_begin();
        memory_region_set_readonly(&s->masters[i].iommu, false);
        memory_region_set_readonly(&s->masters[i].iommu, true);
        memory_region_transaction_commit();

It was not clear to me if CPUs should hook into the iommu notification
system or if we should make the iommu notification code signal changes
through AS change notifications.

The latter would be easy to get right I guess but we wouldn't be
able to have any granularity in the flushing so performance could
be better if the CPU somehow knows what parts have changed.

Cheers,
Edgar


> 
> Paolo
> 
> > If it hits MMIO behind IOMMUs it returns the first memsection, i.e
> > the one pointing to the iommu-ops and lets the IO access helpers
> > deal with the access via address_space_rw (for every IO access, slow).
>