[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2] x86/passthrough: fix migration of MSI when using posted interrupts



On 10/31/19 7:56 AM, Jan Beulich wrote:
> On 31.10.2019 15:52, Joe Jin wrote:
>> On 10/31/19 1:01 AM, Jan Beulich wrote:
>>> On 30.10.2019 19:01, Joe Jin wrote:
>>>> On 10/30/19 10:23 AM, Roger Pau Monné wrote:
>>>>> On Wed, Oct 30, 2019 at 09:38:16AM -0700, Joe Jin wrote:
>>>>>> On 10/30/19 1:24 AM, Roger Pau Monné wrote:
>>>>>>> Can you try to add the following debug patch on top of the existing
>>>>>>> one and report the output that you get on the Xen console?
>>>>>>
>>>>>> Applied debug patch and run the test again, not of any log printed,
>>>>>> attached Xen log on serial console, seems pi_update_irte() not been
>>>>>> called for iommu_intpost was false.
>>>>>
>>>>> I have to admit I'm lost at this point. Does it mean the original
>>>>> issue had nothing to do with posted interrupts?
>>>>
>>>> Looks when inject irq by vlapic_set_irq(), it checked by
>>>> hvm_funcs.deliver_posted_intr rather than iommu_intpost:
>>>>
>>>>  176     if ( hvm_funcs.deliver_posted_intr )
>>>>  177         hvm_funcs.deliver_posted_intr(target, vec);
>>>>
>>>> And deliver_posted_intr() would be there, when vmx enabled:
>>>>
>>>> (XEN) HVM: VMX enabled
>>>> (XEN) HVM: Hardware Assisted Paging (HAP) detected
>>>> (XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB
>>>
>>> I can't see the connection. start_vmx() has
>>>
>>>     if ( cpu_has_vmx_posted_intr_processing )
>>>     {
>>>         alloc_direct_apic_vector(&posted_intr_vector, 
>>> pi_notification_interrupt);
>>>         if ( iommu_intpost )
>>>             alloc_direct_apic_vector(&pi_wakeup_vector, 
>>> pi_wakeup_interrupt);
>>>
>>>         vmx_function_table.deliver_posted_intr = vmx_deliver_posted_intr;
>>>         vmx_function_table.sync_pir_to_irr     = vmx_sync_pir_to_irr;
>>>         vmx_function_table.test_pir            = vmx_test_pir;
>>>     }
>>>
>>> i.e. the hook is present only when posted interrupts are
>>> available in general. I.e. also with just CPU-side posted
>>> interrupts, yes, which gets confirmed by your "apicv=0"
>>> test. Yet with just CPU-side posted interrupts I'm
>>> struggling again to understand your original problem
>>> description, and the need to fiddle with IOMMU side code.
>>
>> Yes, on my test env, cpu_has_vmx_posted_intr_processing == true && 
>> iommu_intpost == false,
>> with this, posted interrupts been enabled.
> 
> And what's the theory then again for needing to modify IOMMU
> code in this case?

Idea is when dev msix vector been updated, we need to let vcpu know to avoid
to lost interrupt. Not sure we can do this or other path?

Thanks,
Joe



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.