From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ewan Mellor Subject: Re: Re: [Xen-changelog] Create new vcpu_op() hypercall. Replaces old boot_vcpu() Date: Tue, 4 Oct 2005 22:10:05 +0100 Message-ID: <20051004211005.GA31207@uk.xensource.com> References: <20051003184236.GF29825@us.ibm.com> <20051004153828.GF17358@us.ibm.com> <20051004160544.GG17358@us.ibm.com> <7a928da7e42690192b2659cb33f5dc60@cl.cam.ac.uk> <20051004203920.GH17358@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20051004203920.GH17358@us.ibm.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On Tue, Oct 04, 2005 at 03:39:20PM -0500, Ryan Harper wrote: > * Keir Fraser [2005-10-04 11:31]: > > > > On 4 Oct 2005, at 17:05, Ryan Harper wrote: > > > > >>btw, this patch also regressed vcpu-{enable/disable} for dom0 and > > >>domU. > > > > > >Actually this was just the first changeset where I noticed. The break > > >is further back. I'll reply in a bit with the changeset where this was > > >broken. > > > > I see problems on smp save/restore -- secondary cpus end up looping > > forever (I think waiting for their state to be CPU_UP_PREPARE in > > play_dead()). I'm sure there's a similar problem in vcpu-up/down logic. > > I don't think it can be very hard to fix. :-) > > Actually, hotplug works fine via sysfs: > (echo 0 > /sys/devices/system/cpu/cpu1/online), but the store watches for > hotplug don't seem to get triggered. I can confirm the writes to the > store (with xs_tdb_dump), and with some debugging in the kernel I can > see that the watches never fire. > > Last changeset where vcpu-disable works is: > > changeset: 7141:a39510ad5c591ee84592924e718c90d746f90097 > user: emellor@ewan > date: Fri Sep 30 05:55:49 2005 > summary: Added cache-control headers to pages returned by HTTP server so that pages Or to put it another way, the changeset that broke it is 7142:Within the store, split the persistent information regarding a VM from the transient information regarding a domain. This suggests that the recent changes to the paths have broken something; presumably whatever is watching is watching for the wrong thing now. Do you know which path is being changed, and which path was being changed in the working changeset? Ewan.