Re: [Qemu-devel] [PATCH 09/17] memory: iommu support

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 1794 bytes --]

On Thu, May 02, 2013 at 07:24:54AM +0200, Paolo Bonzini wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Il 02/05/2013 05:05, David Gibson ha scritto:
> >>> I think the problem is that we do not have reference counting,
> >>> and this makes it simpler to manage the lifetime.  It can be
> >>> changed later.
> > I don't really follow this logic.  In the existing case, the iommu 
> > target is always system memory, and there's already 
> > address_space_memory which always exists.
> 
> But does the tce->iommu address space always exist?  Can you have
> multiple domains and so on?

I'm not sure exactly what you mean here.  We have multiple
"partitionable endpoints" that are somewhat equivalent to iommu
domains on intel - each corresponds to a different DMA address space.
By convention, though, these are configured by firmware and never
changed during runtime.  For simplicity in the qemu guest case, we
only ever have one partitionable endpoint per (guest) PCI host
bridge.  That's not really a limitation, because pseries can happily
support multiple host bridges (even dozens or hundreds).

> I can surely change it if you prefer, after all you're the only user
> right now (address_space_memory always exists).  But I'm not 100% sure
> it will create more problems than it solves.

Well, we're talking here about the *target* address space of the
iommu.  So that's address_space_memory for us too.  In fact I don't
know of any realistic cases where the target AS won't be
address_space_memory, although it's certainly theoretically possible.

-- 
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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]