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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 05.04.17 at 02:20, <chao.gao@xxxxxxxxx> wrote:
> 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.

Hmm, looking again I think I was confused when I did look last time.
The (non-obvious) use of APIC_DEST_NOSHORT in the call to
vlapic_match_dest() looks correct for Fixed and LowestPrio modes
(and is in fact independent of delivery mode selection), so there
indeed shouldn't be an issue here. I'm sorry for the extra trouble.

Jan


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