All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@web.de>
To: Peter Xu <peterx@redhat.com>
Cc: qemu-devel@nongnu.org, imammedo@redhat.com, rth@twiddle.net,
	ehabkost@redhat.com, jasowang@redhat.com, marcel@redhat.com,
	mst@redhat.com, pbonzini@redhat.com, rkrcmar@redhat.com,
	alex.williamson@redhat.com, wexu@redhat.com,
	David kiarie <davidkiarie4@gmail.com>
Subject: Re: [Qemu-devel] [PATCH v5 15/18] intel_iommu: introduce IEC notifiers
Date: Thu, 28 Apr 2016 10:36:19 +0200	[thread overview]
Message-ID: <5721CB83.4080005@web.de> (raw)
In-Reply-To: <20160428082915.GF20143@pxdev.xzpeter.org>

On 2016-04-28 10:29, Peter Xu wrote:
> On Thu, Apr 28, 2016 at 09:26:01AM +0200, Jan Kiszka wrote:
>> On 2016-04-28 09:05, Peter Xu wrote:
>>> This patch introduces Intel VT-d IEC (Interrupt Entry Cache)
>>> invalidation notifier list. When vIOMMU receives IEC invalidate request,
>>> all the registered units will be notified with specific invalidation
>>> requests.
>>
>> This should be designed to be IOMMU-agnostic, i.e. become reusable for
>> the AMD implementation. I suspect we will have the same need for route
>> invalidations there as well...
> 
> Yes possibly...
> 
> I feel like there are lots of things that can be shared between
> Intel and AMD IOMMUs. I just do not know what is the most suitable
> "extent" that we should abstract these shared functionalities
> between the two, and how.

A rough indicator: if you add something that has "vtd" in its name to
non-vtd code, think twice about some reusable abstraction ;). So,
something like "vtd_get_iommu" could already be named and designed to
have two provides (e.g. allow an IOMMU to register itself as provider,
return that registered instance(s) when requested).

> 
> For example, AFAIU, a better solution for current IOMMU
> codes (including Intel and AMD) is to provide a common framework
> (like...  X86IOMMU?), abstract these shared things out into a
> framework, like per device name spaces, iotlb, IEC notifications,
> etc... However, that will need a lot of further work. Also, I still
> do not know whether this is a good idea even in the future.
> 
> So, will this be a good point that we start to think about common
> code blocks for both Intel and AMD IOMMU?

The core iommu code can still be refactored later on. I'm now more
concerned about the hooks you add to generic code, see above.

Jan

  reply	other threads:[~2016-04-28  8:36 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-28  7:05 [Qemu-devel] [PATCH v5 00/18] IOMMU: Enable interrupt remapping for Intel IOMMU Peter Xu
2016-04-28  7:05 ` [Qemu-devel] [PATCH v5 01/18] acpi: enable INTR for DMAR report structure Peter Xu
2016-04-28  7:05 ` [Qemu-devel] [PATCH v5 02/18] intel_iommu: allow queued invalidation for IR Peter Xu
2016-04-28  7:05 ` [Qemu-devel] [PATCH v5 03/18] intel_iommu: set IR bit for ECAP register Peter Xu
2016-04-28  7:05 ` [Qemu-devel] [PATCH v5 04/18] acpi: add DMAR scope definition for root IOAPIC Peter Xu
2016-04-28  7:05 ` [Qemu-devel] [PATCH v5 05/18] intel_iommu: define interrupt remap table addr register Peter Xu
2016-04-28  7:05 ` [Qemu-devel] [PATCH v5 06/18] intel_iommu: handle interrupt remap enable Peter Xu
2016-04-28  7:05 ` [Qemu-devel] [PATCH v5 07/18] intel_iommu: define several structs for IOMMU IR Peter Xu
2016-04-28  7:05 ` [Qemu-devel] [PATCH v5 08/18] intel_iommu: provide helper function vtd_get_iommu Peter Xu
2016-04-28  7:05 ` [Qemu-devel] [PATCH v5 09/18] intel_iommu: add IR translation faults defines Peter Xu
2016-04-28  7:05 ` [Qemu-devel] [PATCH v5 10/18] intel_iommu: Add support for PCI MSI remap Peter Xu
2016-04-28  7:32   ` Jan Kiszka
2016-04-28  8:06     ` Peter Xu
2016-04-28  7:05 ` [Qemu-devel] [PATCH v5 11/18] q35: ioapic: add support for emulated IOAPIC IR Peter Xu
2016-04-28  7:05 ` [Qemu-devel] [PATCH v5 12/18] ioapic: introduce ioapic_entry_parse() helper Peter Xu
2016-04-28  7:05 ` [Qemu-devel] [PATCH v5 13/18] intel_iommu: add support for split irqchip Peter Xu
2016-04-28  7:05 ` [Qemu-devel] [PATCH v5 14/18] q35: add "intremap" parameter to enable IR Peter Xu
2016-04-28  7:05 ` [Qemu-devel] [PATCH v5 15/18] intel_iommu: introduce IEC notifiers Peter Xu
2016-04-28  7:26   ` Jan Kiszka
2016-04-28  8:29     ` Peter Xu
2016-04-28  8:36       ` Jan Kiszka [this message]
2016-04-28  8:49         ` Peter Xu
2016-04-28 15:56           ` David Kiarie
2016-04-29  2:43             ` Peter Xu
2016-04-28  7:05 ` [Qemu-devel] [PATCH v5 16/18] ioapic: register VT-d IEC invalidate notifier Peter Xu
2016-04-28  7:05 ` [Qemu-devel] [PATCH v5 17/18] ioapic: keep RO bits for IOAPIC entry Peter Xu
2016-04-29 19:42   ` Radim Krčmář
2016-04-28  7:05 ` [Qemu-devel] [PATCH v5 18/18] ioapic: clear remote irr bit for edge-triggered interrupts Peter Xu
2016-04-29 19:46   ` Radim Krčmář
2016-04-28  7:12 ` [Qemu-devel] [PATCH v5 00/18] IOMMU: Enable interrupt remapping for Intel IOMMU Peter Xu
2016-04-28  7:19 ` Jan Kiszka
2016-04-28  9:18   ` Peter Xu
2016-04-28  9:32     ` Jan Kiszka
2016-04-29 19:52     ` Radim Krčmář
2016-05-03  3:22       ` Peter Xu
2016-05-03  4:38         ` Jan Kiszka
2016-05-03  5:30           ` Peter Xu
2016-05-03  5:40             ` Jan Kiszka
2016-05-03  6:00               ` Peter Xu
2016-05-03  6:09                 ` Jan Kiszka
2016-05-09 11:50           ` Paolo Bonzini
2016-04-28  9:30 ` [Qemu-devel] [PATCH 19/18] intel_iommu: Add support for Extended Interrupt Mode Jan Kiszka
2016-04-29  2:54   ` Peter Xu

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=5721CB83.4080005@web.de \
    --to=jan.kiszka@web.de \
    --cc=alex.williamson@redhat.com \
    --cc=davidkiarie4@gmail.com \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=marcel@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rkrcmar@redhat.com \
    --cc=rth@twiddle.net \
    --cc=wexu@redhat.com \
    /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.