Re: [Xen-devel] [PATCH v3 4/6] Pause/Unpause the domain before/after assigning PI hooks

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On Sun, 2016-09-18 at 08:37 +0000, Wu, Feng wrote:
> > From: Dario Faggioli [mailto:dario.faggioli@xxxxxxxxxx]
> > So why this is all of the sudden becoming one? Am I completely off
> > with
> > my recollection (or in general :-P)? Or what am I missing about the
> > issue we are trying to address with this new bits of the work?
> 
> The issue discussed between Jan and me is that now we have four
> PI hooks: vmx_pi_switch_from, vmx_pi_switch_to, vmx_vcpu_block,
> and vmx_pi_do_resume. The previous assumption in vmx_vcpu_block()
> is that when we are running this function, the NDST field should have
> the same meaning with the current pCPU the vCPU is running on.
>
I'm sorry, but I'm still not getting it. Feel free to drop me, if I'm
doing more harm than good, but really, I can't parse this sentence into
something that makes me better understand the problem at hand.

"The previous assumption": "previous" with respect to what?

"the field should have the same meaning with the current pCPU the vCPU
is running on", what's this meaning you're mentioning, and how would it
be the same?

> However, I found this is not true in some scenarios, such as,
> vmx_pi_switch_to() hasn't been installed or executed before
> vmx_vcpu_block() gets called, in which case, we may hit the ASSERT
> in it. In previous version, I suggested we remove the ASSERT in
> vmx_vcpu_block() and set NDST explicitly in it. But seems maintainer
> doesn't like this idea. 
>
And this is not helping either. An ASSERT() being hit means something
wrong happened. Whether or not to remove (or change) an ASSERT() is not
a matter of "like".

If we hit the ASSERT() but nothing is wrong with the code, then it is
the ASSERT() itself that is wrong (buggy), and we must remove it, like
it or not.

OTOH, if we hit a non buggy ASSERT(), then it means that the ASSERT()
has done its job in finding something wrong in the code, and we should
leave it alone and fix the problem.

How's possible for the solution here to be "either remove the ASSERT()
_OR_ change the code"? That really makes few sense to me... :-O

Thanks and Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: signature.asc
Description: This is a digitally signed message part

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