All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: aik@ozlabs.ru, alex.williamson@redhat.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 3/4] vfio: Move container list to iommu MemoryRegion
Date: Mon, 29 Apr 2013 13:38:06 +0200	[thread overview]
Message-ID: <517E5B9E.1020006@redhat.com> (raw)
In-Reply-To: <20130429110047.GL20202@truffula.fritz.box>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Il 29/04/2013 13:00, David Gibson ha scritto:
> 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.

Let me know. :)

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

Why should VFIO be any special in this?  It is reassuring to me that
the VFIO maintainer thinks the same. :)

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

There is only one MemoryRegion per PCI host bridge, and the PCI host
bridge cannot disappear before the VFIO devices on it are torn down.
So the lifetime should not be a problem.

Paolo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRflueAAoJEBvWZb6bTYbybdkP/A5jrip69S4OB6XyDen7GkFy
YdX1SSs23zrVJ/PjrSqGCw4caXUecqp4b+49NCMFOF9Sy7ypvPWZvR84qpSRnFD9
oXYBpKZ3HPI0j0i/Ga84Lhz0ylyhfjTBel2jpAlJJq+odjdaHBttrQbWJIOCikMD
/mPStcU3FoQRp8KysIv0rro56IR9L0sAz7MuuJT0to7NfZHC1HrwrwJJYanB3hGN
OTTYUwRf+l9jZv5JgqanK2YcyDo0j43bvri03rdiKpJ0bj8BCQqxVOhg5TjtK3P6
EK2ABspt/q2LKWkfiC6xeudQoqcdjq2CfjqM5zqFuYExbh80MlTo5/I9hGF3zebw
naCD4qxrV/KwcrbCEqU+ieAvY1rj0ALcdSizBDPp+zemF2QzS87uXS1wjYPIvFar
oMuKnPAuAqwu7+g6uIqOFc24AIPiLwoJbnSAkiZ89wSqySKIbQj7vYJYoodxPidC
rZUr0VmspAKTfaW6lsb08KiepFaj4jySpB6bgS++hZZtPPgZ7ApUc8Yr2oZlrw8r
N+IDwPDigvFOMNSCej2YyIfZfi1CvkG/sJacCF3z+uHPIjwAu5Fy3s/gM7f27WXW
k0Dfak5l/i8QPWD6kZly6meoc+vTwiOVfKZPhLowrFG+C6G36LRuSiaDvHzS5vvM
6rar2khtc7sB+20wWDSD
=bzBg
-----END PGP SIGNATURE-----

  reply	other threads:[~2013-04-29 11:38 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-26  6:02 [Qemu-devel] [0/4] RFC: Preparations for VFIO and guest IOMMUs (v2) David Gibson
2013-04-26  6:02 ` [Qemu-devel] [PATCH 1/4] Fix vmw_pvscsi.c for iommu support changes David Gibson
2013-04-26  8:19   ` Paolo Bonzini
2013-04-26 11:04     ` David Gibson
2013-04-26  6:02 ` [Qemu-devel] [PATCH 2/4] vfio: Associate VFIO groups with (guest) IOMMU address spaces David Gibson
2013-04-26  6:02 ` [Qemu-devel] [PATCH 3/4] vfio: Move container list to iommu MemoryRegion David Gibson
2013-04-26  8:23   ` Paolo Bonzini
2013-04-26 11:31     ` David Gibson
2013-04-26 13:40       ` Paolo Bonzini
2013-04-27  9:49         ` David Gibson
2013-04-27 12:17           ` Paolo Bonzini
2013-04-28  1:58             ` David Gibson
2013-04-29  8:11               ` Paolo Bonzini
2013-04-29 11:00                 ` David Gibson
2013-04-29 11:38                   ` Paolo Bonzini [this message]
2013-04-29 11:56                     ` David Gibson
2013-04-29 13:44                       ` Paolo Bonzini
2013-04-30  2:05                         ` David Gibson
2013-04-30  2:23                           ` David Gibson
2013-04-30  7:30                             ` Paolo Bonzini
2013-04-30  7:54                               ` David Gibson
2013-04-29  2:11             ` [Qemu-trivial] [PATCH] memory: give name every AddressSpace Alexey Kardashevskiy
2013-04-29  2:11               ` [Qemu-devel] " Alexey Kardashevskiy
2013-04-29  8:16               ` [Qemu-trivial] " Paolo Bonzini
2013-04-29  8:16                 ` [Qemu-devel] " Paolo Bonzini
2013-04-29  8:21                 ` [Qemu-trivial] " Alexey Kardashevskiy
2013-04-29  8:21                   ` [Qemu-devel] " Alexey Kardashevskiy
2013-04-29  9:25                   ` [Qemu-trivial] " Paolo Bonzini
2013-04-29  9:25                     ` [Qemu-devel] " Paolo Bonzini
2013-04-29 11:09                     ` [Qemu-trivial] " David Gibson
2013-04-29 11:09                       ` [Qemu-devel] " David Gibson
2013-04-30  2:14                     ` Alexey Kardashevskiy
2013-04-26  6:02 ` [Qemu-devel] [PATCH 4/4] vfio: Only use memory listeners when appropriate David Gibson
2013-04-26 15:42 ` [Qemu-devel] [0/4] RFC: Preparations for VFIO and guest IOMMUs (v2) Alex Williamson
2013-04-27  9:51   ` David Gibson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=517E5B9E.1020006@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=aik@ozlabs.ru \
    --cc=alex.williamson@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.