Re: [Qemu-devel] [RFC v1 3/7] memory: iommu support

[Blue Swirl]

On Fri, Oct 12, 2012 at 2:45 AM, Benjamin Herrenschmidt
<address@hidden> wrote:
> On Thu, 2012-10-11 at 15:42 +0200, Paolo Bonzini wrote:
>> Il 11/10/2012 15:26, Avi Kivity ha scritto:
>> > +struct MemoryRegionIOMMUOps {
>> > +    /* Returns a TLB entry that contains a given address. */
>> > +    IOMMUTLBEntry (*translate)(MemoryRegion *iommu, target_phys_addr_t 
>> > addr,
>> > +                               bool is_write);
>> > +};
>>
>> Do map/unmap still make sense in this model?  Ben & David, what were
>> your plans there?
>
> To keep it under the rug for as long as we could ? :-)
>
> The problem with map and unmap is invalidations. How do you convey to
> the devices having done a map that the guest has invalidated a
> translation entry.

Also in Sparc32, IOMMU uses a table in RAM which the guest can change,
so a callback to update the translation tables should be available. On
Sparc64 there's IOTLB but also a fallback to TSB translation table in
memory. We could rely on the guest issuing demaps/flushes when the
memory changes and invalidate the translations then.

>
> Especially nasty on PAPR where the invalidation is a hcall which is
> assumed to be synchronous.
>
> We have simply not solved the problem for now. The risk due to the
> possible access beyond the end of life of a translation is negligible as
> long as we are not playing funny mapping tricks with emulated devices
> (which we might do with some in the future... but not today) and the
> scope of the problem is limited to the guest corrupting itself.
>
> Cheers,
> Ben.
>
>