[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 Thu, Oct 31, 2019 at 07:52:23AM -0700, 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.

I'm still quite lost. My reading of the Intel VT-d spec is that the
posted interrupt descriptor (which contains the PIRR) is used in
conjunction with a posted interrupt remapping entry in the iommu, so
that interrupts get recorded in the PIRR and later synced by the
hypervisor into the vlapic IRR when resuming the virtual CPU.

How is the PIRR filled if there's no interrupt remapping entry
pointing to it?

I have to admit I'm not super-familiar with the implementation in Xen,
so it's likely I'm missing something.

Roger.

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