[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

 


Rackspace

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