All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Fedin <p.fedin@samsung.com>
To: 'Alex Williamson' <alex.williamson@redhat.com>
Cc: kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu,
	'Marc Zyngier' <marc.zyngier@arm.com>,
	'Thomas Gleixner' <tglx@linutronix.de>,
	'Jason Cooper' <jason@lakedaemon.net>,
	'Manish Jaggi' <mjaggi@caviumnetworks.com>,
	'Pranavkumar Sawargaonkar' <pranavkumar@linaro.org>,
	'Bharat Bhushan' <Bharat.Bhushan@freescale.com>
Subject: RE: [PATCH v2 0/3] Introduce MSI hardware mapping for VFIO
Date: Thu, 03 Dec 2015 16:16:54 +0300	[thread overview]
Message-ID: <00eb01d12dcc$e20df980$a629ec80$@samsung.com> (raw)
In-Reply-To: <1449091979.15753.134.camel@redhat.com>

 Hello!

> I like that you're making this transparent
> for the user, but at the same time, directly calling function pointers
> through the msi_domain_ops is quite ugly.

 Do you mean dereferencing info->ops->vfio_map() in .c code? I can introduce some wrappers in include/linux/msi.h like msi_domain_vfio_map()/msi_domain_vfio_unmap(), this would not conceptually change anything.

>  There needs to be a real, interface there that isn't specific to vfio.

 Hm... What else is going to use this?
 Actually, in my implementation the only thing specific to vfio is using struct vfio_iommu_driver_ops. This is because we have to perform MSI mapping for all "vfio domains" registered for this container. At least this is how original type1 driver works.
 Can anybody explain me, what these "vfio domains" are? From the code it looks like we can have several IOMMU instances belonging to one VFIO container, and in this case one IOMMU == one "vfio domain". So is my understanding correct that "vfio domain" is IOMMU instance?
 And here come completely different ideas...
 First of all, can anybody explain, why do i perform all mappings on per-IOMMU basis, not on per-device basis? AFAIK at least ARM SMMU knows about "stream IDs", and therefore it should be capable of distinguishing between different devices. So can i have per-device mapping? This would make things much simpler.
 So:
 Idea 1: do per-device mappings. In this case i don't have to track down which devices belong to which group and which IOMMU...
 Idea 2: What if we indeed simply simulate x86 behavior? What if we just do 1:1 mapping for MSI register when IOMMU is initialized and forget about it, so that MSI messages are guaranteed to reach the host? Or would this mean that we would have to do 1:1 mapping for the whole address range? Looks like (1) tried to do something similar, with address reservation.
 Idea 3: Is single device guaranteed to correspond to a single "vfio domain" (and, as a consequence, to a single IOMMU)? In this case it's very easy to unlink interface introduced by 0002 of my series from vfio, and pass just raw struct iommu_domain * without any driver_ops? irqchip code would only need iommu_map() and iommu_unmap() then, no calling back to vfio layer.

Cc'ed to authors of all mentioned series

> [1] http://www.spinics.net/lists/kvm/msg121669.html,
> http://www.spinics.net/lists/kvm/msg121662.html
> [2] http://www.spinics.net/lists/kvm/msg119236.html

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia



  reply	other threads:[~2015-12-03 13:16 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-24 13:50 [PATCH v2 0/3] Introduce MSI hardware mapping for VFIO Pavel Fedin
2015-11-24 13:50 ` [PATCH v2 1/3] vfio: Introduce map and unmap operations Pavel Fedin
2015-11-24 13:50 ` [PATCH v2 2/3] gicv3, its: Introduce VFIO " Pavel Fedin
2015-11-24 13:50 ` [PATCH v2 3/3] vfio: Introduce generic MSI mapping operations Pavel Fedin
2015-12-02 21:32 ` [PATCH v2 0/3] Introduce MSI hardware mapping for VFIO Alex Williamson
2015-12-03 13:16   ` Pavel Fedin [this message]
2015-12-03 14:49     ` Marc Zyngier
2015-12-03 17:05     ` Alex Williamson

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='00eb01d12dcc$e20df980$a629ec80$@samsung.com' \
    --to=p.fedin@samsung.com \
    --cc=Bharat.Bhushan@freescale.com \
    --cc=alex.williamson@redhat.com \
    --cc=jason@lakedaemon.net \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=marc.zyngier@arm.com \
    --cc=mjaggi@caviumnetworks.com \
    --cc=pranavkumar@linaro.org \
    --cc=tglx@linutronix.de \
    /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.