From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Dan Magenheimer" Subject: RE: "cpus" config parameter broken? Date: Thu, 10 Jan 2008 15:53:21 -0700 Message-ID: <20080110155321125.00000003216@djm-pc> References: Reply-To: "dan.magenheimer@oracle.com" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser , Ian Pratt , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org > > So modulo-izing the cpus parameter code will eliminate this > > case, but I still wonder if vcpu_set_affinity should reject any > > mask that has bits set beyond max_pcpu instead of silently > > ignoring those bits. Seems like an accident waiting to happen > > and indeed I got bitten by it. > > > > Which is why I proposed tightening the definition of all affinity > > masks (and strings representing masks) to "if you try to enable > > a bit in the cpumask that refers to a non-existent processor, you > > will get an error" > = > That doesn't play nicely with CPU hotplug (not supported yet, = > but could well > be in future) where the online_map could be continually = > changing. The model > I'm aiming for in Xen is to remember all the CPUs requested by the > toolstack, but only schedule onto the subset that are = > actually online right > now (obviously). The implementation of this is of course = > quite simple given > the CPU hotplug is not supported right now. Agreed, but even with CPU hotplug there will be some max_pcpu value on any given machine. That's why I said "non-existent processor" in the proposal even though you said "offline processor". Dan