similar to: [PATCH] sedf get in XendClient API

This patch -Displays[1] current parameters for running domains ala xm list -Allow users to set[2] one or more parameters[3] without having to provide values for parameters they do not wish to change -Adds additional testing of sched-sedf via new xm-test testcases. With this patch applied, test 02_sedf_period_lower_neg.py exposes a bug[4]. I''ll follow up this email with a patch for

9d1fd58ff602 was bogous in not letting a new domain being created if its scheduling parameters --when running under the sedf scheduler-- were not fully specified, making creation fail like in this example here below: 2012-06-16 07:37:47 Z executing ssh ... root@10.80.248.105 xl create /etc/xen/debian.guest.osstest.cfg libxl: error: libxl.c:3619:sched_sedf_domain_set: setting domain sched sedf:

sched_sedf.c used o have its own mechanism for producing tracing-alike kind of information (domain block, wakeup, etc.). Nowadays, with an even not so high number of pCPUs/vCPUs, just trying to enable this makes the serial console completely unusable, produces tons of very hard to parse and interpreet logging and can easily livelock Dom0. Moreover, pretty much the same result this is struggling to

Hi list, I''m using xen 3.0.0 and wonder how to obtain the 6 DOMU scheduling parameters from my DOM0 domain. Sort opposite of the sched-sedf xm sub-command Can someone help me ? Pierre _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users

Hi, I''ve installed xen-unstable 4.2 from actual git (last commit was 4dc7dbef5400f0608321d579aebb57f933e8f707). When I start a domU with xm all is fine include the cpu_weight I configured in my domU config. When I start the domU with xl then all my domU have the default cpu_weight of 256 instead of the configured one. Was the name of cpu_weight being changed for xl command ? My domU

Hi, I''ve installed xen-unstable 4.2 from actual git (last commit was 4dc7dbef5400f0608321d579aebb57f933e8f707). When I start a domU with xm all is fine include the cpu_weight I configured in my domU config. When I start the domU with xl then all my domU have the default cpu_weight of 256 instead of the configured one. Was the name of cpu_weight being changed for xl command ? My domU

Please CC as I''m not subscribed to valgrind-developers. Under Xen the toolstack is responsible for managing the domains in the system, e.g. creating, destroying, and otherwise manipulating them. To do this it uses a number of ioctls on the /proc/xen/privcmd device. Most of these (the MMAPBATCH ones) simply set things up such that a subsequenct mmap call will map the desired guest

Hi, there are two issues wich cost me some time to figure out and maybe it made sense if someone put them into the documentation and / or wiki, because without these addressed my system ran pretty instable and wasn''t very usable. This applies to xen-3.0 and kernel 2.6.12.6-xen: 1) Networking issue With the default bridged setup, networking was quite flaky, e.g. samba access from dom0

Is there a way to setup cpu scheduling commands from inside the config file for a domU ? Or it can only be done after the domU has been started ? -- regards, Anand Gupta _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users

Here are some small format changes in xm.1 to make sedf more readable, should start getting to the device section proper today. -Sean -- __________________________________________________________________ Sean Dague Mid-Hudson Valley sean at dague dot net Linux Users Group http://dague.net

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> -- 1.7.10.4

Xen patchbot -unstable wrote: > # HG changeset patch > # User emellor@leeni.uk.xensource.com > # Node ID da24df1ea484cf72dc9d367d52e828777e0e20cd > # Parent c1bb4eb565296bdb00aed84fcc877befbcebd8e9 > Improve error handling, in particular fixing the ProtocolError that is thrown > when a domain is specified by the user that does not exist. Added a few > error codes -- many

The following patches implement XML-RPC for Xend. The first patch just adds a new server for Xend that exposes the same functions exposed by the S-Expression/HTTP server expect by XML-RPC. There is no change to the code paths taken for any xm commands so it''s a rather safe patch to include. The second patch changes XendClient to use XML-RPC and makes a few subsequent changes to xm

When using sedf scheduler in a cpupool the system might panic when setting sedf scheduling parameters for a domain. Signed-off-by: juergen.gross@ts.fujitsu.com 1 file changed, 4 insertions(+) xen/common/sched_sedf.c | 4 ++++ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

This patch adds new control messages for vcpu hotplug events. Via the xm vcpu_hotplug sub-program, VCPUS in domains can be enabled/disabled when CONFIG_HOTPLUG_CPU is enabled in the target domain''s kernel. Currently there is nothing that tracks whether a VCPU is up or down. My previous [1]patch added a new per-VCPU flag (VCPUF_down) which could be used to keep track of which VCPUS are

I rebooted xenU from console (dom2) and exited (ctr-]). xm list does not report 2 anymore yet I can log into 2 via console and it is running just fine. Is this a bug? I''ll pull/rebuild and see what happens.. (this is xen-2.0, cset 1.1321.1.1, rh7.3 dom0/dom1) ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on

Hi, Dan, This patch fixes strange behavior on IA64, that IDLE is scheduled more than Dom0 with default sEDF scheduler. The key point is reprogram_ac_timer at the end of ac_timer dispatcher, which programs local apic timer with expire of next ac_timer on x86. Higher precision lapic timer can trigger ac_timer more precisely than simply done in PIT interrupt handler. That works perfectly on x86

Right now xm will return 1 if you run `xm list non_existant_domain` Wouldnt it be a better idea to have a specific error code for this error so that scripts wrapping around xm can better determine if the domain does not exist or if xm just failed for whatever reason? ~Shaun _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com

Hi. I found this issue with IA64 box while looking at the c/s of 18204:21dd1fdb73d8, but I believe the things is same with x86 box. I''m not sure whether this patch coexist with the old ioemu which is to be removed soon. So it might be desirable to apply this patch after deleting the internal ioemu tree. thanks, xm: Don''t spawn vncviewer twice. Without this patch, vncviewer

Hi all, I installed SLES 10.0b3 with XEN on some test-systems and created a SLES 10.0b3-image for use with domU''s. The installation and booting of this domU was no problem, but on some systems the host dom0 restarts if I generate some IP-traffic from the guest. This happens on an old AMD Athlon 1,3GHz, an old Intel P3 and an Intel desktop with P4 HT/VT/EM64T but not on an Intel