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

[Ryan Harper <ryanh@xxxxxxxxxx>]

* Ewan Mellor <ewan@xxxxxxxxxxxxx> [2005-10-04 16:11]:
> On Tue, Oct 04, 2005 at 03:39:20PM -0500, Ryan Harper wrote:
> 
> > * Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> [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@xxxxxxxxxx

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel