[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Gibson
Subject: Re: [Qemu-devel] [PATCH 09/17] memory: iommu support
Date: Thu, 2 May 2013 16:28:22 +1000
User-agent: Mutt/1.5.21 (2010-09-15)

On Thu, May 02, 2013 at 07:24:54AM +0200, Paolo Bonzini wrote:
> 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_!

Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]