[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] x86/pt: skip setup of posted format IRTE when gvec is 0
On Tue, Apr 30, 2019 at 11:08:54AM +0200, Roger Pau Monné wrote: >On Tue, Apr 30, 2019 at 01:19:19PM +0800, Chao Gao wrote: >> When testing with an UP guest with a pass-thru device with vt-d pi >> enabled in host, we observed that guest couldn't receive interrupts >> from that pass-thru device. Dumping IRTE, we found the corresponding >> IRTE is set to posted format with "vector" field as 0. >> >> We would fall into this issue when guest used the pirq format of MSI > >I think the above sentence is a bit confusing. I would rather say that >the guest is routing interrupts from passthrough devices over event >channels using pirqs. Yes. It is better than it was. > >> (see the comment xen_msi_compose_msg() in linux kernel). As 'dest_id' >> is repurposed, skip migration which is based on 'dest_id'. > >Like Jan, I wonder why the device model (I assume QEMU) issues a >XEN_DOMCTL_bind_pt_irq hypercall when the guest is attempting to route >this interrupts over an event channel, attempting to bind it to a >vector seems like a bug in the device model. > >I would also consider whether it would make sense to not expose the >XENFEAT_hvm_pirqs feature when doing passthrough if posted interrupts >are supported, performance wise it's better to use posted interrupts >rather than routing them over event channels (which requires Xen >interaction). It is reasonable. But I think currently guest can add "xen_nopv" to its kernel boot options to avoid using evtchn. There might be some cases even with pass-thru devices (such as, guest uses polling mode driver for pass-thru devices), we care more about the efficiency of delivering virtual interrupts. So a separate option for evtchn in guest kernel seems like a better choice. Thanks Chao > >Note that I think this whole XENFEAT_hvm_pirqs is a big hack which >abuses a hardware interface, and I would like to see it removed. > >Thanks, Roger. > >_______________________________________________ >Xen-devel mailing list >Xen-devel@xxxxxxxxxxxxxxxxxxxx >https://lists.xenproject.org/mailman/listinfo/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |