search for: schedop_block

minios: fix and enforce block_domain atomicity To ensure that the timer event is not lost, block_domain requires that event delivery is disabled. SCHEDOP_block re-enables them, so for coherency (and fixing a bug actually), we should re-disable them after. Also, make sure that the caller disabled them. Signed-off-by: Samuel Thibault <samuel.thibault@eu.citrix.com> diff -r 4965e711fee8 extras/mini-os/arch/x86/time.c --- a/extras/mini-os/arch/x86/tim...

...ange + * + * HYPERVISOR_domctl + * All generic sub-operations, with the exception of: + * * XEN_DOMCTL_iomem_permission (not yet implemented) + * * XEN_DOMCTL_irq_permission (not yet implemented) + * + * HYPERVISOR_sched_op + * All generic sub-operations, with the exception of: + * * SCHEDOP_block -- prefer wfi hardware instruction + * + * HYPERVISOR_console_io + * All generic sub-operations + * + * HYPERVISOR_xen_version + * All generic sub-operations + * + * HYPERVISOR_event_channel_op + * All generic sub-operations + * + * HYPERVISOR_physdev_op + * No sub-operations are curren...

...; @@ -781,6 +782,11 @@ asmlinkage void do_trap_hypervisor(struct cpu_user_regs *regs) case HSR_EC_DATA_ABORT_GUEST: do_trap_data_abort_guest(regs, hsr.dabt); break; + case HSR_EC_WFI_WFE: + if ( list_empty(&current->arch.vgic.inflight_irqs) ) + do_sched_op_compat(SCHEDOP_block, 0); + regs->pc += hsr.len ? 4 : 2; + break; default: printk("Hypervisor Trap. HSR=0x%x EC=0x%x IL=%x Syndrome=%"PRIx32"\n", hsr.bits, hsr.ec, hsr.len, hsr.iss); diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c index 39b9775.....

...o->evtchn_pending_sel); smp_mb__after_clear_bit(); /* Event pending already? */ if ( test_bit(port, &d->shared_info->evtchn_pending[0]) ) + break; + if( v->vcpu_info->evtchn_upcall_pending ) break; do_sched_op(SCHEDOP_block, 0); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

...n + * Versions of Xen prior to 3.0.2 provided only the following legacy version * of this hypercall, supporting only the commands yield, block and shutdown: * long sched_op(int cmd, unsigned long arg) * @cmd == SCHEDOP_??? (scheduler operation). * @arg == 0 (SCHEDOP_yield and SCHEDOP_block) * == SHUTDOWN_* code (SCHEDOP_shutdown) + * + * This legacy version is available to new guests as: + * long HYPERVISOR_sched_op_compat(enum sched_op cmd, unsigned long arg) */ /* @@ -44,12 +74,17 @@ /* * Halt execution of this domain (all VCPUs) and notify the system controller. *...

...n + * Versions of Xen prior to 3.0.2 provided only the following legacy version * of this hypercall, supporting only the commands yield, block and shutdown: * long sched_op(int cmd, unsigned long arg) * @cmd == SCHEDOP_??? (scheduler operation). * @arg == 0 (SCHEDOP_yield and SCHEDOP_block) * == SHUTDOWN_* code (SCHEDOP_shutdown) + * + * This legacy version is available to new guests as: + * long HYPERVISOR_sched_op_compat(enum sched_op cmd, unsigned long arg) */ /* @@ -44,12 +74,17 @@ /* * Halt execution of this domain (all VCPUs) and notify the system controller. *...

...chn); } The clear of the pending is needed to ensure that any subsequent calls to block_on() don''t return immediately. regards, john # HG changeset patch # User john.levon@sun.com # Node ID 15aea7d020cd13b1f13692518f10051e401962df # Parent fbeb0a5b7219630839986cf4cdb1b813618cbdce Add SCHEDOP_block_on. Signed-off-by: John Levon <john.levon@sun.com> diff -r fbeb0a5b7219 -r 15aea7d020cd docs/src/interface.tex --- a/docs/src/interface.tex Thu Mar 9 16:24:57 2006 +0000 +++ b/docs/src/interface.tex Thu Mar 9 21:55:15 2006 -0800 @@ -1721,13 +1721,17 @@ \hypercall{sched\_op(unsigned long...

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

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

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:

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

Hi. This patchset implements ia64/xen domU support based on ia64/pv_ops frame work which was sent as another patchest. Changes from take 5 are rebased to Linux 2.6.26-rc3, bug fix ivt.S paravirtualization and multi entry point support. I believe these patches can be applied to the linux ia64 repository. This patchset does the followings. - Some preparation work. Mainly importing header files to

Hi. This patchset implements ia64/xen domU support based on ia64/pv_ops frame work which was sent as another patchest. Changes from take 5 are rebased to Linux 2.6.26-rc3, bug fix ivt.S paravirtualization and multi entry point support. I believe these patches can be applied to the linux ia64 repository. This patchset does the followings. - Some preparation work. Mainly importing header files to