Re: [Xen-devel] [PATCH v2 0/4] VMX: Properly handle pi descriptor and per-cpu blocking list

["Wu, Feng" <feng.wu@xxxxxxxxx>]

> -----Original Message-----
> From: Dario Faggioli [mailto:dario.faggioli@xxxxxxxxxx]
> Sent: Friday, June 24, 2016 6:29 PM
> To: Wu, Feng <feng.wu@xxxxxxxxx>; xen-devel@xxxxxxxxxxxxx
> Cc: keir@xxxxxxx; Tian, Kevin <kevin.tian@xxxxxxxxx>; jbeulich@xxxxxxxx;
> andrew.cooper3@xxxxxxxxxx; george.dunlap@xxxxxxxxxxxxx;
> konrad.wilk@xxxxxxxxxx
> 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.faggioli@xxxxxxxxxx]
> > > 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. If this is the case, I feel there aren’t
problems with it. Anyway, I have replied to George's mail and
based on his suggestion, I proposed a new method to handle
the case that the last assigned devices is detached. Could you
please have a look at it when you have time. If that works, I think
we don't need to the above changes anymore. Thanks in advance!

Thanks,
Feng
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel