All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>,
	"patches@linaro.org" <patches@linaro.org>,
	Eric Auger <eric.auger@redhat.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [RFC PATCH v2 00/12] iommu: add MemTxAttrs argument to IOMMU translate function
Date: Thu, 17 May 2018 14:46:49 +0200	[thread overview]
Message-ID: <2d52e9bd-93e7-58fd-af73-8eccda3bcb63@redhat.com> (raw)
In-Reply-To: <CAFEAcA-o3M2ruUfU7hk89S=eGgCP=b+hPyKrSdSR79OP_Ug9vg@mail.gmail.com>

On 17/05/2018 12:48, Peter Maydell wrote:
> So I had an idea this morning for a slightly different way to approach
> this, which is that we add a concept of an iommu_idx, analogous to
> our existing TCG mmu_idx. Basically an iommu_idx represents a
> page table (kind of like what Arm calls a "translation regime"), so
> that for any particular iommu index and input address the output
> address and permissions are always the same. For the memory
> protection controller there would be two iommu_idxes, one for
> secure and one for non-secure.
> 
> The API changes would be something like:
>  * new method get_num_indexes() which returns the number of iommu indexes
>    this IOMMU implements (default implementation: return 1)
>  * translate method takes an iommu index (and not the txattrs)
>  * new method index_from_attrs() which takes a MemTxAttrs and
>    returns the iommu index that should be used (default implementation:
>    always return 0)
>  * memory_region_register_iommu_notifier() takes an iommu index
>  * the default 'replay' method does "for each supported index,
>    for each address, call @translate"
>  * vfio and vhost can register their notifiers using the index
>    returned by index_from_attrs(MEMTXATTRS_UNSPECIFIED)
>  * maybe they could call get_num_indexes() and bail out if the
>    IOMMU has support for multiple indexes?
>  * maybe they could be enhanced to support tracking multiple
>    page tables if necessary in future
> 
> I haven't worked through the details yet, but this seems to me
> more flexible than working directly with txattrs. It also means
> it's harder to accidentally write an iommu implementation that
> looks at more fields in the txattrs than its notifier interface
> claims are significant to it.

Yes, this also sounds good.  It does have the same issue for VFIO that
get_num_indexes() would be called too late to fail (and again, in a
place where it's hard to fail).

Maybe the index count and the index-from/to-attrs translation should be
static (index-to-attrs could use the same pair of MemTxAttrs for "which
bits matter" and "what value should they have"), so that VFIO can
inspect it and decide if it's okay to proceed with e.g. the first iommu_idx?

Thanks,

Paolo

  reply	other threads:[~2018-05-17 12:46 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-01  8:59 [Qemu-devel] [RFC PATCH v2 00/12] iommu: add MemTxAttrs argument to IOMMU translate function Peter Maydell
2018-05-01  8:59 ` [Qemu-devel] [RFC PATCH v2 01/12] Make tb_invalidate_phys_addr() take a MemTxAttrs argument Peter Maydell
2018-05-01  8:59 ` [Qemu-devel] [RFC PATCH v2 02/12] Make address_space_translate() " Peter Maydell
2018-05-01  8:59 ` [Qemu-devel] [RFC PATCH v2 03/12] Make address_space_map() " Peter Maydell
2018-05-01  8:59 ` [Qemu-devel] [RFC PATCH v2 04/12] Make address_space_access_valid() " Peter Maydell
2018-05-01  8:59 ` [Qemu-devel] [RFC PATCH v2 05/12] Make flatview_extend_translation() " Peter Maydell
2018-05-01  8:59 ` [Qemu-devel] [RFC PATCH v2 06/12] Make memory_region_access_valid() " Peter Maydell
2018-05-01  8:59 ` [Qemu-devel] [RFC PATCH v2 07/12] Make MemoryRegion valid.accepts callback " Peter Maydell
2018-05-01  8:59 ` [Qemu-devel] [RFC PATCH v2 08/12] Make flatview_access_valid() " Peter Maydell
2018-05-01  8:59 ` [Qemu-devel] [RFC PATCH v2 09/12] Make flatview_translate() " Peter Maydell
2018-05-01  8:59 ` [Qemu-devel] [RFC PATCH v2 10/12] Make address_space_get_iotlb_entry() " Peter Maydell
2018-05-01  8:59 ` [Qemu-devel] [RFC PATCH v2 11/12] Make flatview_do_translate() " Peter Maydell
2018-05-01  8:59 ` [Qemu-devel] [RFC PATCH v2 12/12] Add MemTxAttrs argument to IOMMU translate function Peter Maydell
2018-05-02  9:25 ` [Qemu-devel] [RFC PATCH v2 00/12] iommu: add " Paolo Bonzini
2018-05-15 16:28   ` Peter Maydell
2018-05-15 16:50     ` Paolo Bonzini
2018-05-17 10:48       ` Peter Maydell
2018-05-17 12:46         ` Paolo Bonzini [this message]
2018-05-17 13:03           ` Peter Maydell

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=2d52e9bd-93e7-58fd-af73-8eccda3bcb63@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=eric.auger@redhat.com \
    --cc=mst@redhat.com \
    --cc=patches@linaro.org \
    --cc=peter.maydell@linaro.org \
    --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.