Re: Re: [Xen-changelog] Create new vcpu_op() hypercall. Replaces old boot_vcpu()

[Ewan Mellor <ewan@xensource.com>]

On Tue, Oct 04, 2005 at 03:39:20PM -0500, Ryan Harper wrote:

> * Keir Fraser <Keir.Fraser@cl.cam.ac.uk> [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.