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.  :)

>> 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.

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

>>> 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 k...@vger.kernel.org, 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.

Paolo

Reply via email to