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

Re: [Xen-devel] [PATCH v11 1/6] passthrough: don't migrate pirq when it is delivered through VT-d PI



On Fri, Mar 31, 2017 at 04:38:02AM -0600, Jan Beulich wrote:
>>>> On 31.03.17 at 05:27, <chao.gao@xxxxxxxxx> wrote:
>>>>>This then also raises the question whether the call to
>>>>>hvm_girq_dest_2_vcpu_id() is actually legitimate for lowest
>>>>>priority delivery mode.
>>>> 
>>>> For lowest priority delivery mode, if VT-d PI is enabled, the result (the
>>>> destination vcpu) is overrided by vector_hashing_dest() to keep the 
>>>> existing behavior. I think the only point we should keep in mind is
>>>> for cases other than lowest priority delivery mode, pi_find_dest_vcpu()
>>>> and hvm_girq_dest_2_vcpu_id() give the same destination vcpu.
>>>
>>>Well, the override is done for the iommu_intpost case. The remark
>>>on hvm_girq_dest_2_vcpu_id(), however, was made in general.
>> 
>> Ok. You meant the method using in hvm_girq_dest_2_vcpu_id() may not match 
>> the method
>> used by real hardware. I will check it.
>
>I mean that the method used there is pretty clearly "fixed" mode
>handling. Thanks for checking.

I think the method is ok here. It is an optimization to reduce the IPI between
CPUs. Only the cases that the destination vcpu is a single vcpu can use this
optimization. For lowest priority delivery case, we can regard the destination
vcpus that match the 'dest_mode' and 'dest' here as possible destination vcpus.
To emulate hardware accurately, I think we can use this optimization
when a msi has multiple possible destination vcpus.

Thank
Chao

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

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