qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 3/4] vfio: Move container list to iommu MemoryRe


From: David Gibson
Subject: Re: [Qemu-devel] [PATCH 3/4] vfio: Move container list to iommu MemoryRegion
Date: Mon, 29 Apr 2013 21:00:47 +1000
User-agent: Mutt/1.5.21 (2010-09-15)

On Mon, Apr 29, 2013 at 10:11:06AM +0200, Paolo Bonzini wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Il 28/04/2013 03:58, David Gibson ha scritto:
> >>> Ok, knowing about changes that happen in the IOMMU mapping is
> >>> indeed out of scope of MemoryListeners.  What about adding a
> >>> NotifierList? Then VFIO can register a notifier and use it to
> >>> learn about "events" in the IOMMU mapping.  The notifier data
> >>> can be a MemoryRegionSection or IOMMUTableEntry, whatever you
> >>> find more convenient.
> > For the generic case a Notifier could work in principle.  Neither
> > of those structures is suitable as the data though: constructing a 
> > MemoryRegionSection for every page we map into the IOTLB is far
> > too heavyweight, and the IOMMUTLBEntry doesn't contain the IOVA.
> 
> It did in Avi's patch set.  I removed it because it was unused.  I can
> add it back if you need it.

Ok, I think I will need it.

> > Thinking over, I think what that mostly amounts to, is that if the 
> > VFIO aspects of the address space are already wired up by the host 
> > bridge, then the individual vfio-pci devices need a way of going
> > from their qemu iommu address space (which they get from
> > pci_dev->iommu) to the vfio specific information about that address
> > space.
> 
> That can be done with just a hash table, no?

Well, yes it can.  But I think that having a whole parallel lookup
structure within vfio is a worse ugliness than having a single opaque
vfio pointer in the MemoryRegion strcuture.

It does also require making sure the lifetime handling is correct.
The entry from the hash table must be removed before the corresponding
MemoryRegion is free()ed; otherwise we could end up using the same
pointer for a newly constructed MemoryRegion, and get a false lookup
in the hash.  Whether that happens essentially never, or almost
immediately in practice depends on the malloc() implementation, of
course.

-- 
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: signature.asc
Description: Digital signature


reply via email to

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