search for: __monitor

What is the point of specifying "current" as the address to monitor? The memory location of interest really is irq_stat[cpu].__softirq_pending, and if that was used it would then also be possible to actually avoid sending IPIs when monitor/mwait are in use, as is being done on Linux. Jan _______________________________________________ Xen-devel mailing list

...(!current_set_polling_and_test()) { trace_cpu_idle_rcuidle(1, smp_processor_id()); if (this_cpu_has(X86_BUG_CLFLUSH_MONITOR)) { - smp_mb(); /* quirk */ + mb(); /* quirk */ clflush((void *)&current_thread_info()->flags); - smp_mb(); /* quirk */ + mb(); /* quirk */ } __monitor((void *)&current_thread_info()->flags, 0, 0); -- MST

...+ b/xen/arch/x86/acpi/cpu_idle.c Wed Feb 23 17:05:32 2011 +0800 @@ -569,7 +569,8 @@ static void acpi_dead_idle(void) { case ACPI_CSTATE_EM_FFH: /* Not treat interrupt as break event */ - mwait_idle_with_hints(cx->address, 0); + __monitor((void *)&mwait_wakeup(smp_processor_id()), 0, 0); + __mwait(cx->address, 0); break; case ACPI_CSTATE_EM_SYSIO: inb(cx->address); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensourc...

Hi Leslie, 2014-09-29 17:14 GMT+02:00 Leslie Rhorer <lrhorer at mygrande.net>: > > I just did a fresh installation of Debian Jessie on one of my > servers, but NUT won't configure and install. When I try to install, I get > the following: > > Setting up nut-client (2.7.2-1+b2) ... > Job for nut-monitor.service failed. See 'systemctl status >

mb() typically uses mfence on modern x86, but a micro-benchmark shows that it's 2 to 3 times slower than lock; addl that we use on older CPUs. So we really should use the locked variant everywhere, except that intel manual says that clflush is only ordered by mfence, so we can't. Note: some callers of clflush seems to assume sfence will order it, so there could be existing bugs around

mb() typically uses mfence on modern x86, but a micro-benchmark shows that it's 2 to 3 times slower than lock; addl that we use on older CPUs. So we really should use the locked variant everywhere, except that intel manual says that clflush is only ordered by mfence, so we can't. Note: some callers of clflush seems to assume sfence will order it, so there could be existing bugs around

mb() typically uses mfence on modern x86, but a micro-benchmark shows that it's 2 to 3 times slower than lock; addl that we use on older CPUs. So we really should use the locked variant everywhere, except that intel manual says that clflush is only ordered by mfence, so we can't. Note: some callers of clflush seems to assume sfence will order it, so there could be existing bugs around

mb() typically uses mfence on modern x86, but a micro-benchmark shows that it's 2 to 3 times slower than lock; addl that we use on older CPUs. So we really should use the locked variant everywhere, except that intel manual says that clflush is only ordered by mfence, so we can't. Note: some callers of clflush seems to assume sfence will order it, so there could be existing bugs around

Patch 1 removes CONFIG_SMP Patch 2 removes separate smp_{,r,w}mb()s as a result of patch 1 Patch 4 removes __ia64__ defines from the x86 arch tree Patch 3 is related to patch 4 and changes the VIOAPIC to emulate version 0x20 as a performance gain. It preceeds Patch 4 so as to be more clear about the functional change. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

I just did a fresh installation of Debian Jessie on one of my servers, but NUT won't configure and install. When I try to install, I get the following: Setting up nut-client (2.7.2-1+b2) ... Job for nut-monitor.service failed. See 'systemctl status nut-monitor.service' and 'journalctl -xn' for details. invoke-rc.d: initscript nut-client, action "start" failed.

...); \ outb((data), 0x23); \ } while (0) - -/* Stop speculative execution */ -static inline void sync_core(void) -{ - int tmp; - asm volatile("cpuid" : "=a" (tmp) : "0" (1) : "ebx","ecx","edx","memory"); -} static inline void __monitor(const void *eax, unsigned long ecx, unsigned long edx) @@ -508,33 +490,6 @@ static inline void load_esp0(struct tss_ regs->esp = new_esp; \ } while (0) -/* - * These special macros can be used to get or set a debugging register - */ -#define get_debugreg(var, register) \ - __asm_...

...); \ outb((data), 0x23); \ } while (0) - -/* Stop speculative execution */ -static inline void sync_core(void) -{ - int tmp; - asm volatile("cpuid" : "=a" (tmp) : "0" (1) : "ebx","ecx","edx","memory"); -} static inline void __monitor(const void *eax, unsigned long ecx, unsigned long edx) @@ -508,33 +490,6 @@ static inline void load_esp0(struct tss_ regs->esp = new_esp; \ } while (0) -/* - * These special macros can be used to get or set a debugging register - */ -#define get_debugreg(var, register) \ - __asm_...

Hi all, I've been looking at finding common ground between the VMI, Xen and other paravirtualization approaches, and after some discussion, we're getting somewhere. These first two patches are the fundamentals, stolen mainly from the VMI patches: removing assumptions about the kernel running in ring 0, and macro-izing all the obvious para-virtualize-needing insns. The third patch is

Hi all, I've been looking at finding common ground between the VMI, Xen and other paravirtualization approaches, and after some discussion, we're getting somewhere. These first two patches are the fundamentals, stolen mainly from the VMI patches: removing assumptions about the kernel running in ring 0, and macro-izing all the obvious para-virtualize-needing insns. The third patch is