Re: [Qemu-devel] [PATCH 00/13] IOMMU: Enable interrupt remapping for Intel IOMMU

[Peter Xu]

On Fri, Feb 19, 2016 at 10:58:12AM +0100, Paolo Bonzini wrote:
> 
> 
> On 19/02/2016 10:29, Peter Xu wrote:
> > On Fri, Feb 19, 2016 at 09:34:40AM +0100, Jan Kiszka wrote:
> >> On 2016-02-19 08:43, Peter Xu wrote:
> >>> Actually there are several people within my working team knows that
> >>> I would be working on this, and I believe none of us do know your
> >>> work too... Or there must be someone telling me so...
> >>
> >> I guess we would have to match sets of people know to find out who
> >> forgot to mention the outreachy project ;) - anyway, this can always 
> >> happen.
> 
> I knew about the outreachy project and forgot to mention it... but then,
> I only learnt about your effort yesterday.  :)

Yes, it's nobody's bad except myself if the outreachy link is public
for such a long time. I'd need to ask more and do more pre-search on
anything I may work on in the future.

> 
> >> I didn't look into your approach in all details yet, and Rita also just
> >> started, she told me. So one question on yours - which looks appealing
> >> from the invasiveness POV - is how you determine the MSI source with
> >> only a single target region? I do find your changes on the IOAPIC, but
> >> none on the PCI infrastructure, which is confusing given that you say
> >> that works, no?
> > 
> > Do we need to know the source of the MSI interrupt to
> > translate/deliver it? Maybe I got something missing, but could you
> > explain why we need it?
> 
> I think you're not verifying the SVT, SID and SQ fields in the IRTE.

Yes. I have not taken SID verification into consideration, as
mentioned in the cover letter and code comments. I'd say that if
without the MemTxAttrs you mentioned below, current v1 patch does
not suite to add this feature.

> 
> The source ID can be passed to the IOMMU using the MemTxAttrs mechanism.

I see that MemTxAttrs is not enabled yet? It's dropped in all the
accessors like memory_region_write_accessor()?

> 
> >>> So what I was planning is that, this series will be the start. And
> >>> the above two is the first-step goal (and I may need kvm-ioapic as
> >>> well though).
> >>
> >> KVM support is actually a key thing, that's why we started the project
> >> on integrating the patches with the split irqchip work. There was a
> >> consensus with Paolo long ago that full in-kernel irqchip will no longer
> >> gain any additional support that is needed for IR.
> 
> Agreed.
> 
> > Do you have any link to the discussion? I am just curious about it,
> > thanks in advance.
> 
> I couldn't find anything in address@hidden, sorry.
> 
> >>>> - Radim was telling me to look on this as well. How do your efforts
> >>>> correlate?
> 
> FWIW, Radim was thinking of interrupt remapping in the kvm-ioapic, which
> we have decided to set aside.

Does it mean that we are planning not to support kernel_irqchip for
IR? Any quick reason?

Thanks.
Peter