* 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
|
Home