[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: |
Peter Xu |
Subject: |
Re: [Qemu-devel] [PATCH v5 15/18] intel_iommu: introduce IEC notifiers |
Date: |
Thu, 28 Apr 2016 16:49:49 +0800 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
On Thu, Apr 28, 2016 at 10:36:19AM +0200, Jan Kiszka wrote:
> 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).
Yes, thanks for the hints. :)
Before that, I was considering that the AMD guy who is going to add
its support will better consider this and finally make sure the two
coops well (anyway, I know nothing about AMD IOMMU before reading
recent patches, and there is still no amd_iommu.c yet for me to read
at..). But you are right, best to start consider it from the very
beginning.
>
> >
> > 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.
Will try to make them look better in v6. Hopefully there will have
no vtd_*() in common codes. ;)
Thanks!
-- peterx
- Re: [Qemu-devel] [PATCH v5 10/18] intel_iommu: Add support for PCI MSI remap, (continued)
- [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