[Qemu-devel] Re: Status update

[Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>]

On Fri, Jul 02, 2010 at 09:03:39AM +0100, Stefan Hajnoczi wrote:
> > That's true, but it's fair to be concerned about the guest itself.
> > Imagine it runs some possibly malicious apps which program the hardware
> > to do DMA. That should be safe when a IOMMU is present.
> >
> > But suddenly the guest OS changes mappings and expects the IOMMU to
> > enforce them as soon as invalidation commands are completed. The guest
> > then reclaims the old space for other uses. This leaves an opportunity
> > for those processes to corrupt or read sensitive data.
> 
> As long as QEMU acts in the same way as real hardware we should be
> okay.  Will real hardware change the mappings immediately and abort
> the DMA from the device if it tries to access an invalidated address?
> 
> Stefan

Real, non-IOMMU aware hardware looks like this (simplified):

Device <-> IOMMU <-> Memory	(1)

Most QEMU translated devices would do exactly that. But AIO is something
like this:

Device + <---translation--- IOMMU	(2)
       ^
       |
       ---------R/W--------> Memory

There are two reasons this form isn't reducible to the former in case of
AIO:
1. It uses cpu_physical_memory_map().
2. The actual I/O happens on a separate thread.

Real hardware of form (1) has no problems since all access is serialized
through the IOMMU. That doesn't mean mapping updates happen instantly.
But software can wait (and be notified) for the updates to happen.

Real hardware of form (2) is comprised of devices which have their own
IOTLB, I think. But unlike cpu_physical_memory_map() in software-land,
these mappings can be updated during I/O. (These devices are
necessarily IOMMU-aware.)

As I see it, this mmaping trick is quite crucial to AIO and I'm not sure
there's a way around it. The solution I proposed is making the IOMMU
wait* for AIO to finish. Perhaps we can also break mmaping into smaller
chunks so they complete in a reasonable time.

* - Waiting here means to delay notifying the guest OS that invalidation
commands completed. This is the important part: if the guest is told the
mappings have been updated, then they really have to be.


	Eduard