search for: sched_op

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

...iff -r fdf241ea6ff4 extras/mini-os/include/x86/x86_32/hypercall-x86_32.h --- a/extras/mini-os/include/x86/x86_32/hypercall-x86_32.h Wed Nov 28 21:29:18 2012 +0100 +++ b/extras/mini-os/include/x86/x86_32/hypercall-x86_32.h Wed Nov 28 22:53:42 2012 +0100 @@ -172,6 +172,14 @@ return _hypercall2(int, sched_op, cmd, arg); } +static inline int +HYPERVISOR_shutdown( + unsigned int reason) +{ + struct sched_shutdown shutdown = { .reason = reason }; + return _hypercall2(int, sched_op, SCHEDOP_shutdown, &shutdown); +} + static inline long HYPERVISOR_set_timer_op( uint64_t timeout) diff -r fdf241ea6...

...#include <xen/interface/event_channel.h> /* + * Guest Scheduler Operations + * + * The SCHEDOP interface provides mechanisms for a guest to interact + * with the scheduler, including yield, blocking and shutting itself + * down. + */ + +/* * The prototype for this hypercall is: - * long sched_op_new(int cmd, void *arg) + * long HYPERVISOR_sched_op(enum sched_op cmd, void *arg, ...) + * * @cmd == SCHEDOP_??? (scheduler operation). * @arg == Operation-specific extra argument(s), as described below. + * ... == Additional Operation-specific extra arguments, described below. * - * **NOTE...

...#include <xen/interface/event_channel.h> /* + * Guest Scheduler Operations + * + * The SCHEDOP interface provides mechanisms for a guest to interact + * with the scheduler, including yield, blocking and shutting itself + * down. + */ + +/* * The prototype for this hypercall is: - * long sched_op_new(int cmd, void *arg) + * long HYPERVISOR_sched_op(enum sched_op cmd, void *arg, ...) + * * @cmd == SCHEDOP_??? (scheduler operation). * @arg == Operation-specific extra argument(s), as described below. + * ... == Additional Operation-specific extra arguments, described below. * - * **NOTE...

Hi all, With the new vm-tools we are trying to get top like capabilities going correctly. Currently we have a program vm-list that has some of this capability but is dependent on the cpu time given by libxc calls (xc_get_dom_info & xc_domain_get_cpu_usage). These two functions give you how much time (in nanoseconds, why is this not documented) the domain has been actively used. Approaches:

Keir, The patch below is necessary to get ia64 building on current xen-unstable.hg. Thanks, Alex Signed-off-by: Alex Williamson <alex.williamson@hp.com> --- diff -r 3983e4f1b054 xen/arch/ia64/Rules.mk --- a/xen/arch/ia64/Rules.mk Sun Mar 12 10:03:33 2006 +0100 +++ b/xen/arch/ia64/Rules.mk Mon Mar 13 09:36:01 2006 -0700 @@ -12,7 +12,7 @@ CPPFLAGS += -I$(BASEDIR)/include -I$(BA

Some hardware (e.g. Dell Studio laptops) require special functions to be called on physical cpu 0 in order to avoid occasional hangs. When running as dom0 under Xen this could be achieved only via special boot parameters (vcpu pinning) limiting the hypervisor in it's scheduling decisions. This patch series is adding a generic function to be able to temporarily pin a (virtual) cpu to a

Some hardware (e.g. Dell Studio laptops) require special functions to be called on physical cpu 0 in order to avoid occasional hangs. When running as dom0 under Xen this could be achieved only via special boot parameters (vcpu pinning) limiting the hypervisor in it's scheduling decisions. This patch series is adding a generic function to be able to temporarily pin a (virtual) cpu to a

...$0x82 " It is initialized in hypercall_page_initialise(void *hypercall_page) at the time when control panel creates the domain. Later, domain can simply the corresponding entry to issue a hypercall. For the subroutine of the HYPERVISOR_xxx, usually it is do_xxx. For example, __HYPERVISOR_sched_op should be do_sched_op. For more information, please refer to hypercall_table in xen/arch/x86/x86_{32,64}/entry.S. Thanks Ke T S wrote: > Hi, > > Can someone let me know what exactly the array "hypercall_page " > contains? Are they function pointers? > > How do I know...

Greetings all. Some small question regarding schedule poll operation hypercall. 1. struct sched_poll poll.timeout is measured in what unit of time? Secs, ms? ns? 2. After issuing the hypercall_sched_op(SCHEDOP_poll, &poll); if no timeout is used in poll struct how long will I yield the CPU? 3. If I issue the hypercall and the event never comes is it possible to to yield the CPU for ever? Thanks you very much for answering these questions. Daniel Castro -- +-=====--------------------------...

Some hardware (e.g. Dell Studio laptops) require special functions to be called on physical cpu 0 in order to avoid occasional hangs. When running as dom0 under Xen this could be achieved only via special boot parameters (vcpu pinning) limiting the hypervisor in it's scheduling decisions. This patch series is adding a generic function to be able to temporarily pin a (virtual) cpu to a

Some hardware (e.g. Dell Studio laptops) require special functions to be called on physical cpu 0 in order to avoid occasional hangs. When running as dom0 under Xen this could be achieved only via special boot parameters (vcpu pinning) limiting the hypervisor in it's scheduling decisions. This patch series is adding a generic function to be able to temporarily pin a (virtual) cpu to a

Some hardware (e.g. Dell Studio laptops) require special functions to be called on physical cpu 0 in order to avoid occasional hangs. When running as dom0 under Xen this could be achieved only via special boot parameters (vcpu pinning) limiting the hypervisor in it's scheduling decisions. This patch series is adding a generic function to be able to temporarily pin a (virtual) cpu to a

Some hardware (e.g. Dell Studio laptops) require special functions to be called on physical cpu 0 in order to avoid occasional hangs. When running as dom0 under Xen this could be achieved only via special boot parameters (vcpu pinning) limiting the hypervisor in it's scheduling decisions. This patch series is adding a generic function to be able to temporarily pin a (virtual) cpu to a

As discussed in a previous e-mail, this patch series implements yield for the credit scheduler. This allows a VM to actually yield (give up the cpu to another VM) when it wants to. This has been shown to be effective when used in the spinlock code to avoid wasting time spinning when another vcpu is not currently scheduled. _______________________________________________ Xen-devel mailing list

This patch pretty prints the hypercall section for $xenperf -f Each hypercall count is tagged by its name. Reference: http://lists.xensource.com/archives/html/xen-ia64-devel/2006-08/msg00261.html Signed-off-by Ken Hironaka <kenny@logos.ic.i.u-tokyo.ac.jp> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com

Some hardware (e.g. Dell Studio laptops) require special functions to be called on physical cpu 0 in order to avoid occasional hangs. When running as dom0 under Xen this could be achieved only via special boot parameters (vcpu pinning) limiting the hypervisor in it's scheduling decisions. This patch series is adding a generic function to be able to temporarily pin a (virtual) cpu to a

Some hardware (e.g. Dell Studio laptops) require special functions to be called on physical cpu 0 in order to avoid occasional hangs. When running as dom0 under Xen this could be achieved only via special boot parameters (vcpu pinning) limiting the hypervisor in it's scheduling decisions. This patch series is adding a generic function to be able to temporarily pin a (virtual) cpu to a

Some hardware (e.g. Dell Studio laptops) require special functions to be called on physical cpu 0 in order to avoid occasional hangs. When running as dom0 under Xen this could be achieved only via special boot parameters (vcpu pinning) limiting the hypervisor in it's scheduling decisions. This patch series is adding a generic function to be able to temporarily pin a (virtual) cpu to a