From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kip Macy Subject: Re: [RESUBMIT] [PATCH] xen, tools: pincpu use vcpu and cpumap_t Date: Wed, 11 May 2005 13:41:50 -0700 Message-ID: References: <20050426223109.GC14932@us.ibm.com> <4277AC20.7060804@hp.com> <20050503235807.GB11696@us.ibm.com> <4280BE49.1050102@hp.com> <20050510145952.GB7305@us.ibm.com> <20050510155500.GD7305@us.ibm.com> <428221C7.3020708@hp.com> <3d8eece20505111330385b95aa@mail.gmail.com> Reply-To: Kip Macy Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <3d8eece20505111330385b95aa@mail.gmail.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Christian.Limpach@cl.cam.ac.uk Cc: Ian Pratt , Mike Wray , Ryan Harper , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Yes, this patch obviously conflicts with mine. The GETVCPUCONTEXT patch has not gone in yet, nor have I received feedback. Should I resolve the conflicts and re-submit? On 5/11/05, Christian Limpach wrote: > On 5/11/05, Mike Wray wrote: > > Ryan Harper wrote: > > > * Ryan Harper [2005-05-10 10:01]: > > > > > >>* Mike Wray [2005-05-10 09:08]: > > >> > > >>>So it looks like we need to try again. > > >>>Apologies if this is because of changes after > > >>>you submitted the patch. > > >>> > > >>>I also had two failed hunks, which I fixed manually: > > >>> > > >>>1 out of 1 hunk FAILED -- saving rejects to file xen/arch/x86/domain= .c.rej > > >>>1 out of 5 hunks FAILED -- saving rejects to file xen/common/dom0_op= s.c.rej > > >> > > >> > > >>I'll update it against current unstable and resubmit. Thanks. > > > > > > > > > Updated against 2005-05-10 nightly unstable snapshot. > > > > > > > Thanks, I'll apply it. >=20 > I've applied this already -- but it needs some more changes like > moving the vcpu_to_cpu and cpumap arrays out of getdomaininfo into the > new getvcpucontext, allowing this to scale beyond MAX_VIRT_CPUS. > Also, I think sparse vcpu allocations aren't handled right for these > two arrays, which moving them to getvcpucontext will also fix. > Patches for this would be highly appreciated! >=20 > christian >