Hi,
when using xm mem-set on current (7278) unstable, you''ll see
[2005-10-10 10:25:51 xend] ERROR (SrvBase:87) Request mem_target_set failed.
Traceback (most recent call last):
File "/usr/lib/python2.4/site-packages/xen/web/SrvBase.py", line 85,
in perform
return op_method(op, req)
File
"/usr/lib/python2.4/site-packages/xen/xend/server/SrvDomain.py", line
132, in op_mem_target_set
return self.call(self.dom.setMemoryTarget
TypeError: unsubscriptable object
in xend.log.
The fix is trivial, a comma is missing, see (first) attached patch.
HOWEVER, this still does not make balllooning work.
Nobody ever writes to /proc/xen/balloon.
I guess some message should go over xenbus and someone should then
write to it''s balloon file. For dom0, we could do it directly in
XendDomainInfo.setMemoryTarget(). See attached second patch. It''s
a hack and certainly not the right solution.
Who should do it?
Best,
--
Kurt Garloff <kurt@garloff.de> [Koeln, DE]
Physics:Plasma modeling <garloff@plasimo.phys.tue.nl> [TU Eindhoven, NL]
Linux: SUSE Labs (Director) <garloff@suse.de> [Novell Inc]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
On Mon, Oct 10, 2005 at 12:46:39PM +0200, Kurt Garloff wrote:> Hi, > > when using xm mem-set on current (7278) unstable, you''ll see > > [2005-10-10 10:25:51 xend] ERROR (SrvBase:87) Request mem_target_set failed. > Traceback (most recent call last): > File "/usr/lib/python2.4/site-packages/xen/web/SrvBase.py", line 85, in perform > return op_method(op, req) > File "/usr/lib/python2.4/site-packages/xen/xend/server/SrvDomain.py", line 132, in op_mem_target_set > return self.call(self.dom.setMemoryTarget > TypeError: unsubscriptable object > > in xend.log. > > The fix is trivial, a comma is missing, see (first) attached patch. > > > HOWEVER, this still does not make balllooning work. > Nobody ever writes to /proc/xen/balloon.Kurt, could you please retest with today''s unstable? I have put your first patch in (thanks for that) and we have made some changes to the xenstore watch interface recently, so that may help with the second problem. The idea is that the memory/target value gets written by Xend, and and the balloon driver holds a watch on that value in the store. When the watch fires, the balloon driver should respond by setting the new target (drivers/xen/balloon/balloon.c:watch_target). Watches have been broken in various ways over the last few days, and the bugs we know about there have now been fixed, so I would be interested to know whether your bug has been fixed in the process. Cheers, Ewan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ewan, On Wed, Oct 12, 2005 at 02:06:13PM +0100, Ewan Mellor wrote:> Kurt, could you please retest with today''s unstable? I have put your first > patch in (thanks for that) and we have made some changes to the xenstore watch > interface recently, so that may help with the second problem.It seems to work now (tested with 7313), indeed. Thanks for fixing.> The idea is that the memory/target value gets written by Xend, and and the > balloon driver holds a watch on that value in the store. When the watch > fires, the balloon driver should respond by setting the new target > (drivers/xen/balloon/balloon.c:watch_target).The kernel watches data from a userspace file? So the kernel understands the tdb/xenstore format? I wonder whether that''s the cleanest way to implement this feature. Best, -- Kurt Garloff, Director SUSE Labs, Novell Inc. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Fri, Oct 14, 2005 at 10:40:17AM +0200, Kurt Garloff wrote:> > The idea is that the memory/target value gets written by Xend, and and the > > balloon driver holds a watch on that value in the store. When the watch > > fires, the balloon driver should respond by setting the new target > > (drivers/xen/balloon/balloon.c:watch_target). > > The kernel watches data from a userspace file? > So the kernel understands the tdb/xenstore format? > I wonder whether that''s the cleanest way to implement this feature.It''s not a userspace file, as such, but a daemon running in domain 0. The daemon isolates domains from the tdb format, exposing a filesystem-style heirarchical namespace, and maintaining transaction semantics, firing callbacks when portions of the namespace change, and maintaining an implicit root for each connection. It is not necessary for drivers such as the balloon driver to understand the exact layout of the store, but they do need to know how to contact the store and the path from the domain''s implicit root to the details in which they are interested. All changes in domain configuration and state are handled in this way. Ewan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> The kernel watches data from a userspace file? > So the kernel understands the tdb/xenstore format? > I wonder whether that''s the cleanest way to implement this feature.IIRC it just watches the Xenstore node via xenstored: the kernel doesn''t read the xenstore structures directly. It makes things the same for every dom... Btw, balloon driver doesn''t do the full xenbus device registration that the front/back drivers - just hooks in for a simple notification. Cheers, Mark> > Best,_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel