[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [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? >> > - 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. 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. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |