[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v5 15/18] intel_iommu: introduce IEC notifiers
From: |
Jan Kiszka |
Subject: |
Re: [Qemu-devel] [PATCH v5 15/18] intel_iommu: introduce IEC notifiers |
Date: |
Thu, 28 Apr 2016 10:36:19 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 |
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
- [Qemu-devel] [PATCH v5 10/18] intel_iommu: Add support for PCI MSI remap, (continued)
- [Qemu-devel] [PATCH v5 10/18] intel_iommu: Add support for PCI MSI remap, Peter Xu, 2016/04/28
- [Qemu-devel] [PATCH v5 11/18] q35: ioapic: add support for emulated IOAPIC IR, Peter Xu, 2016/04/28
- [Qemu-devel] [PATCH v5 13/18] intel_iommu: add support for split irqchip, Peter Xu, 2016/04/28
- [Qemu-devel] [PATCH v5 12/18] ioapic: introduce ioapic_entry_parse() helper, Peter Xu, 2016/04/28
- [Qemu-devel] [PATCH v5 14/18] q35: add "intremap" parameter to enable IR, Peter Xu, 2016/04/28
- [Qemu-devel] [PATCH v5 15/18] intel_iommu: introduce IEC notifiers, Peter Xu, 2016/04/28
[Qemu-devel] [PATCH v5 16/18] ioapic: register VT-d IEC invalidate notifier, Peter Xu, 2016/04/28
[Qemu-devel] [PATCH v5 17/18] ioapic: keep RO bits for IOAPIC entry, Peter Xu, 2016/04/28
[Qemu-devel] [PATCH v5 18/18] ioapic: clear remote irr bit for edge-triggered interrupts, Peter Xu, 2016/04/28
Re: [Qemu-devel] [PATCH v5 00/18] IOMMU: Enable interrupt remapping for Intel IOMMU, Peter Xu, 2016/04/28
Re: [Qemu-devel] [PATCH v5 00/18] IOMMU: Enable interrupt remapping for Intel IOMMU, Jan Kiszka, 2016/04/28