From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chao Peng Subject: Re: [PATCH v8 03/13] x86: maintain COS to CBM mapping for each socket Date: Fri, 29 May 2015 10:43:00 +0800 Message-ID: <20150529024259.GC18422@pengc-linux.bj.intel.com> References: <1432197704-20816-1-git-send-email-chao.p.peng@linux.intel.com> <1432197704-20816-4-git-send-email-chao.p.peng@linux.intel.com> <556731A2020000780007E99B@mail.emea.novell.com> Reply-To: Chao Peng Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <556731A2020000780007E99B@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: wei.liu2@citrix.com, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com, dario.faggioli@citrix.com, Ian.Jackson@eu.citrix.com, xen-devel@lists.xen.org, will.auld@intel.com, keir@xen.org, dgdegra@tycho.nsa.gov List-Id: xen-devel@lists.xenproject.org On Thu, May 28, 2015 at 02:17:54PM +0100, Jan Beulich wrote: > >>> On 21.05.15 at 10:41, wrote: > > For each socket, a COS to CBM mapping structure is maintained for each > > COS. The mapping is indexed by COS and the value is the corresponding > > CBM. Different VMs may use the same CBM, a reference count is used to > > indicate if the CBM is available. > > > > Signed-off-by: Chao Peng > > Reviewed-by: Andrew Cooper > > --- > > Changes in v8: > > * Move the memory allocation and CAT initialization code to CPU_UP_PREPARE. > > * Add memory freeing code in CPU_DEAD path. > > Changes like this imo invalidate any tags given for earlier versions. Sure, I will remove it. > > +static int cat_cpu_init(unsigned int cpu) > > +{ > > + int rc; > > + const struct cpuinfo_x86 *c = cpu_data + cpu; > > + > > + if ( !cpu_has(c, X86_FEATURE_CAT) ) > > + return 0; > > + > > + if ( test_bit(cpu_to_socket(cpu), cat_socket_enable) ) > > + return 0; > > + > > + if ( cpu == smp_processor_id() ) > > + do_cat_cpu_init(&rc); > > + else > > + on_selected_cpus(cpumask_of(cpu), do_cat_cpu_init, &rc, 1); > > This now being called in the context of CPU_UP_PREPARE, I can't see > how this works at all: Neither would the CPU's cpu_data[] instance be > initialized by that time, nor would you be able to IPI that CPU, nor can I > see how the if() branch could ever get entered. Was this tested at all? Ah, yes! So it sounds really a little difficult to move the memory allocation from CPU_STARTING to CPU_PREPARA for this case. Chao