On 24/06/16 14:42, Wu, Feng wrote: > > >> -----Original Message----- >> From: Dario Faggioli [mailto:dario.faggi...@citrix.com] >> Sent: Friday, June 24, 2016 6:29 PM >> To: Wu, Feng <feng...@intel.com>; xen-devel@lists.xen.org >> Cc: k...@xen.org; Tian, Kevin <kevin.t...@intel.com>; jbeul...@suse.com; >> andrew.coop...@citrix.com; george.dun...@eu.citrix.com; >> konrad.w...@oracle.com >> Subject: Re: [PATCH v2 0/4] VMX: Properly handle pi descriptor and per-cpu >> blocking list >> >> On Fri, 2016-06-24 at 06:33 +0000, Wu, Feng wrote: >>>> -----Original Message----- >>>> From: Dario Faggioli [mailto:dario.faggi...@citrix.com] >>>> In your case, AFAICUI, it's: >>>> - the vCPU should block, waiting for an event >>>> - the event is _not_ arrived, so we indeed should block >>>> - we do *not* block, due to some other reason >>>> >>>> That does not look right to me... what about the fact that we >>>> wanted to >>>> actually wait for the event? :-O >>> I understand your point. In my understanding, currently, vcpu_block() >>> is >>> for guest's HLT operation, which means, guest has nothing to do. In >>> this case, even we return (not blocking), seems the function is not >>> broken. >>> >> So, basically, you're saying that the vcpu has nothing to do, and in >> fact it executed an HLT instruction, and you want to let it continue to >> run? :-O > > Here is my understanding, if the guest has nothing to do, it will > call HLT, and Xen hypervisor will call vcpu_block(), if we don't > block the vCPU and return to guest, guest will continue to run > HLT if it still has nothing to do.
As it happens, most operating systems will handle this situation just fine; but I'm not sure this is something we want to rely on. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
