Re: [Xen-devel] [PATCH] x86/pt: skip setup of posted format IRTE when gvec is 0

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 30.04.19 at 11:01, <chao.gao@xxxxxxxxx> wrote:
> On Tue, Apr 30, 2019 at 01:56:31AM -0600, Jan Beulich wrote:
>>In any event it doesn't look correct to skip migration altogether in
>>that case. I'd rather expect it to require getting done differently.
>>After all there still is a (CPU, vector) tuple associated with that
>>{,p}IRQ if it's not posted, and hvm_migrate_pirq() is a no-op if it is
>>posted.
> 
> Here, we try to set irq's target cpu to the cpu which the vmsi's target vcpu
> is running on to reduce IPI. But the 'dest_id' field which used to
> indicate the vmsi's target vcpu is missing, we don't know which cpu we should
> migrate the irq to. One possible choice is the 'chn->notify_vcpu_id'
> used in send_guest_pirq(). Do you think this choice is fine?

Well, the code you change is that binding the IRQ, not delivering
it. Is the event channel set up already at all at that point? See
also Roger's reply.

>>Finally it hasn't become clear to me why this is a UP-guest issue
>>only.
> 
> For SMP case, it happens to work. hvm_girq_dest_2_vcpu_id() would return
> -1 for SMP in most cases. And then we won't use VT-d PI if there is no
> dest vcpu. For UP case, hvm_girq_dest_2_vcpu_id() returns 0 without 
> matching.

"Happens to work" together with how hvm_girq_dest_2_vcpu_id()
works looks to mean "happens to sometimes work" (maybe "often",
but hardly "always"): The function easily can return other than -1
for multi-CPU guests as well. Which then is another reason to
consider fixing the issue in qemu instead.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel