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

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

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Monday, May 23, 2016 4:09 PM
> To: Wu, Feng <feng.wu@xxxxxxxxx>
> Cc: andrew.cooper3@xxxxxxxxxx; dario.faggioli@xxxxxxxxxx;
> george.dunlap@xxxxxxxxxxxxx; Tian, Kevin <kevin.tian@xxxxxxxxx>; xen-
> devel@xxxxxxxxxxxxx; konrad.wilk@xxxxxxxxxx; keir@xxxxxxx
> Subject: RE: [PATCH 0/3] VMX: Properly handle pi descriptor and per-cpu
> blocking list
> 
> >>> On 20.05.16 at 12:46, <feng.wu@xxxxxxxxx> wrote:
> 
> >
> >> -----Original Message-----
> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> >> Sent: Friday, May 20, 2016 6:27 PM
> >> To: Wu, Feng <feng.wu@xxxxxxxxx>
> >> Cc: andrew.cooper3@xxxxxxxxxx; dario.faggioli@xxxxxxxxxx;
> >> george.dunlap@xxxxxxxxxxxxx; Tian, Kevin <kevin.tian@xxxxxxxxx>; xen-
> >> devel@xxxxxxxxxxxxx; konrad.wilk@xxxxxxxxxx; keir@xxxxxxx
> >> Subject: Re: [PATCH 0/3] VMX: Properly handle pi descriptor and per-cpu
> >> blocking list
> >>
> >> >>> On 20.05.16 at 10:53, <feng.wu@xxxxxxxxx> wrote:
> >> > I still have two opens, which needs comments/suggestions from you guys.
> >> > - What should we do for the per-cpu blocking list during vcpu hotplug?
> >>
> >> What do you mean with vcpu hotplug? vcpus never get removed
> >> from a VM (from hypervisor perspective), and all the guest may
> >> ever use need to be created before the guest starts.
> >
> > Thanks for the reply, Jan. First of all, I am not familiar with vcpu
> > hotplug/pcup hotplug,
> > and that is why I list them as two opens here. When I wrote "vcpu hotplug",
> > I was planning
> > to refer to the following case:
> > 1. use 'xl vcpu-set ${dom_id} ${vcpu_num}', where ${vcpu_num} is less than
> > the current
> > online vcpus.
> > 2. In the guest, use ' echo 1 > /sys/devices/system/cpu/cpuX/online ' to 
> > make
> > the vcpus
> > offline.
> >
> > Yes, I know the maximum vcpus are allocated for the guest, but I am not 
> > quite
> sure
> > whether the above operations will affect the blocking list. If you can 
> > elaborate
> a bit
> > more what hypervisor will do for the above operations, That should be very
> helpful.
> 
> The hypervisor just offlines the vCPU (in response to the guest
> invoking VCPUOP_down).
> 
> > such as, will the vcpu's state be changed, etc? And if the vcpu is current
> > in blocking
> > state, while try to offline it, it will still remain in the blocking list,
> > right, will this cause
> > some problems?
> 
> Since _VPF_down is just one of many possible pause flags, I don't
> see what problems you're suspecting. But maybe I'm overlooking
> something?

Thanks for the explanation. If hypervisor just offline the vCPU, I
think there is nothing special need to do here. Since the current
logic can handle the state transition well.

> 
> >> > - What should we do for the per-cpu blocking list during pcpu hotplug?
> >>
> >> I think it would help if you said what issue you see.
> >
> > I didn't see any issues related to this, this open just comes out in my mind
> > when I wrote
> > this patch to fix the bug. As mentioned above, when the pCPU is removed,
> > what is the
> > status of its blocking list? But thinking a bit more about this, I feel it
> > should work this way,
> > before the pCPU is removed, all the vCPUs running on it has been moved to
> > another
> > pCPU, right?
> 
> Yes.
> 
> > If this is the case, it can address part of my concern. Another
> > concern is
> > if a vCPU is blocking on a pCPU, then the pCPU is going to be unplugged,
> > what does
> > Xen do for the blocking vCPU?
> 
> A pCPU is never blocking "on a pCPU", it is always just blocking.

I think you meant "vCPU is never ...."

> vCPU-s currently having their v->processor set to the pCPU being
> hot removed would simply get migrated elsewhere. If that's not
> accompanied by respective PI blocking list adjustments, then I can
> only refer you back to the original series' review process, where
> it was (iirc) more than once that it was pointed out that getting out
> of sync v->processor and the PI list a vCPU sits on may casue
> issues. And if there is an issue here, I'm not sure what a good
> solution would be.

Okay, here is my understanding about the blocking and vCPU
migration things, if vCPU is blocking and its v->processor is pCPU 0,
at some point, pCPU0 is removed from the system, it will also
migrate the vCPU to another pCPU, say, pCPU1 as the response
to pCPU0 being unplugged, hence, v->processor = pCPU1, right?

If that is the case, I think the current code may have issues in the
above case, since 'NDST' filed in PI descriptor is still vCPU0 even
it is removed from the system. I need to consider how to handle
this case. But this is not an issue  in non pCPU hotplug scenario.

Thanks,
Feng

> 
> Jan


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