Re: [Qemu-devel] [RFC 0/13] Support for guest visible IOMMUs

2012-04-20 Thread Kevin Wolf
Am 20.04.2012 06:16, schrieb David Gibson:
 I'm really hoping I can get some extra review of this code path.  I
 believe it's correct, but it's not straightforward to test, since it
 will not be exercise by correct guest software.

Sounds like a good case for qtest. Did you consider that?

Kevin



Re: [Qemu-devel] [RFC 0/13] Support for guest visible IOMMUs

2012-04-20 Thread David Gibson
On Fri, Apr 20, 2012 at 12:39:36PM +0200, Kevin Wolf wrote:
 Am 20.04.2012 06:16, schrieb David Gibson:
  I'm really hoping I can get some extra review of this code path.  I
  believe it's correct, but it's not straightforward to test, since it
  will not be exercise by correct guest software.
 
 Sounds like a good case for qtest. Did you consider that?

Only in the sense that I really hope to be able to find time sometime
to get my head around qtest so I can use it for this amongst other
things.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson




[Qemu-devel] [RFC 0/13] Support for guest visible IOMMUs

2012-04-19 Thread David Gibson
Here is the latest update of my series of patches adding
infrastructure to allow the emulation of guest visible IOMMUs.  I
think this is conceptually ready to go, but I'm sending it as an RFC
for now because it needs a bit more testing and review, particularly
of the invalidation paths.  I believe the first two preliminary
patches are already on their way invia the USB tree.

The big change since the last version is improved handling of IOMMU
invalidations versus dma_memory_map():

It's no longer necessary to have a cancel callback which must
synchronously cancel any current usage of a dma_memory_map() buffer.
Instead, we delay the completion of invalidate operations until
outstanding maps are gone.  Later patches do add a cancel callback to
accelerate that freeing up, but it no longer has the potentially
tricky to accomplish synchronous requirements.

I'm really hoping I can get some extra review of this code path.  I
believe it's correct, but it's not straightforward to test, since it
will not be exercise by correct guest software.

There are also some more minor updates based on the previous round of
feedback.