From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ryan Harper Subject: Re: Re: [Xen-changelog] Create new vcpu_op() hypercall. Replaces old boot_vcpu() Date: Tue, 4 Oct 2005 16:17:44 -0500 Message-ID: <20051004211744.GI17358@us.ibm.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> <20051004211005.GA31207@uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20051004211005.GA31207@uk.xensource.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: Ewan Mellor Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org * Ewan Mellor [2005-10-04 16:11]: > 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? The vcpu hotplug watch is triggered on any writes to /cpu. It will then examine the node value to see if the change was made to /cpu/cpu#/availability, (e.g. /cpu/1/availability), if the full path of the change is correct, it examines the change values which are either 'online' or 'offline' and invokes the vcpu_up/down handlers if the write is a state change. I only ever see one trigger and the value is 'cpu' but I can confirm that tdb sees the full write ('/cpu/1/availabilty', 'offline'). -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx (512) 838-9253 T/L: 678-9253 ryanh@us.ibm.com