search for: cmpxchg8b

...=============================================== --- 2008-04-15.orig/tools/tests/test_x86_emulator.c 2008-04-01 11:10:21.000000000 +0200 +++ 2008-04-15/tools/tests/test_x86_emulator.c 2008-04-15 08:48:15.000000000 +0200 @@ -74,7 +74,7 @@ static int cmpxchg( return X86EMUL_OKAY; } -static int cmpxchg8b( +static int cmpxchg2( unsigned int seg, unsigned long offset, unsigned long old_lo, @@ -94,7 +94,7 @@ static struct x86_emulate_ops emulops = .insn_fetch = read, .write = write, .cmpxchg = cmpxchg, - .cmpxchg8b = cmpxchg8b + .cmpxchg2 = cmpxchg2 };...

...t; > #include <cstdint> > std::atomic<uint64_t> x (0); > int main() { > uint64_t i = x.load(std::memory_order_relaxed); > return 0; > } > > Apparently, with clang 6.0 it didn't generate libcalls to atomic functions, but just put in cmpxchg8b's, I guess? And with clang 7.0 this seems to have changed. > > For now, I can only test on amd64 due to this, since I don't have an easy workaround. This doesn't sound so good, but I'm glad we found out early. Did you file a bug to track this? (Sorry if you already did, I h...

...AtomicInlineWidth is reset as follows: >> For i386, the MaxAtomicInlineWidth should be 0 because no cmpxchg is supported. >> For i486, the MaxAtomicInlineWidth should be 32 because it supports cmpxchg. >> For others 32 bits x86 cpu, the MaxAtomicInlineWidth should be 64 because of cmpxchg8b. > > This seems to be somewhat undesirable. Does *anyone* care about real > i386 support at this point? NetBSD certainly doesn't and I think we are > already the odd man for a number of cases like this. Yes, and since this causes quite a number of regressions for us, I would real...

This change restricts the reading and setting of the head and tail pointers on 32bit X86 to 32bit for both correctness and performance reasons. On uniprocessor X86_32, the atomic64_read may be implemented as a non-locked cmpxchg8b. This may result in updates to the pointers done by the VMCI device being overwritten. On MP systems, there is no such correctness issue, but using 32bit atomics avoids the overhead of the locked 64bit operation. All this is safe because the queue size on 32bit systems will never exceed a 32bit val...

This change restricts the reading and setting of the head and tail pointers on 32bit X86 to 32bit for both correctness and performance reasons. On uniprocessor X86_32, the atomic64_read may be implemented as a non-locked cmpxchg8b. This may result in updates to the pointers done by the VMCI device being overwritten. On MP systems, there is no such correctness issue, but using 32bit atomics avoids the overhead of the locked 64bit operation. All this is safe because the queue size on 32bit systems will never exceed a 32bit val...

...==== --- 2008-06-12.orig/xen/arch/x86/mm.c 2008-06-12 09:08:36.000000000 +0200 +++ 2008-06-12/xen/arch/x86/mm.c 2008-06-12 09:08:42.000000000 +0200 @@ -1706,8 +1706,8 @@ int get_page(struct page_info *page, str return 0; } asm volatile ( - LOCK_PREFIX "cmpxchg8b %3" - : "=d" (nd), "=a" (y), "=c" (d), + LOCK_PREFIX "cmpxchg8b %2" + : "=d" (nd), "=a" (y), "=m" (*(volatile u64 *)(&page->count_info)) : "0" (d),...

...th is reset as follows: > >> For i386, the MaxAtomicInlineWidth should be 0 because no cmpxchg is supported. > >> For i486, the MaxAtomicInlineWidth should be 32 because it supports cmpxchg. > >> For others 32 bits x86 cpu, the MaxAtomicInlineWidth should be 64 because of cmpxchg8b. > > > > This seems to be somewhat undesirable. Does *anyone* care about real > > i386 support at this point? NetBSD certainly doesn't and I think we are > > already the odd man for a number of cases like this. > > > Yes, and since this causes quite a number o...

With pretty trivial user mode programs being able to crash the kernel due to the ref counter widths in Xen being more narrow than in Linux, I started an attempt to put together a kernel side fix. While addressing the plain hypercalls is pretty strait forward, dealing with multicalls (both when using them for lazy mmu mode batching and when explicitly using them in e.g. netback - the backends are

...es Product: Portable OpenSSH Version: 5.5p1 Platform: All OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: ssh AssignedTo: unassigned-bugs at mindrot.org ReportedBy: taviso at cmpxchg8b.com Created attachment 1877 --> https://bugzilla.mindrot.org/attachment.cgi?id=1877 Possible implementation of ForwardX11Timeout On several popular Linux distributions (like redhat), x11 access control is performed using SO_PEERCRED credentials, this breaks ssh -X, as once the untrusted coo...

Lguest currently requires a TSC, which breaks older machines and Matt Mackall who boots the host with "notsc". In addition, there is no good solution to changing TSC speeds (informing all the guests about the TSC impending change before it happens would be a great deal of code and have issues with disobedient guests). This patch makes the host determine if the TSC is both constant and

Lguest currently requires a TSC, which breaks older machines and Matt Mackall who boots the host with "notsc". In addition, there is no good solution to changing TSC speeds (informing all the guests about the TSC impending change before it happens would be a great deal of code and have issues with disobedient guests). This patch makes the host determine if the TSC is both constant and

...s: >>>>> For i386, the MaxAtomicInlineWidth should be 0 because no cmpxchg is supported. >>>>> For i486, the MaxAtomicInlineWidth should be 32 because it supports cmpxchg. >>>>> For others 32 bits x86 cpu, the MaxAtomicInlineWidth should be 64 because of cmpxchg8b. >>>> >>>> This seems to be somewhat undesirable. Does *anyone* care about real >>>> i386 support at this point? NetBSD certainly doesn't and I think we are >>>> already the odd man for a number of cases like this. >>> >>> &gt...

...d to install a domU HVM (Windows 2003) on a server of my hosting provider (OVH) : the distribution is a Debian Etch with Xen 3.3 compiled from source. But at the first screen the Windows Installer says that the process can not continue because my system does not have the instructions CPUID and CMPXCHG8B. Do you have any idea about this problem ? Thank you, Martin _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users

...5b4e2120e3a362: Linus Torvalds (1): Merge branch 'pm-fixes' of git://git.kernel.org/.../rafael/suspend-2.6 are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus.git master Rusty Russell (2): lguest: workaround cmpxchg8b_emu by ignoring cli in the guest. lguest: stop using KVM hypercall mechanism arch/x86/include/asm/lguest_hcall.h | 29 +++++++++++++--- arch/x86/lguest/boot.c | 61 +++++++++++++++++------------------ arch/x86/lguest/i386_head.S | 2 +- drivers/lguest/lguest_devi...

...5b4e2120e3a362: Linus Torvalds (1): Merge branch 'pm-fixes' of git://git.kernel.org/.../rafael/suspend-2.6 are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus.git master Rusty Russell (2): lguest: workaround cmpxchg8b_emu by ignoring cli in the guest. lguest: stop using KVM hypercall mechanism arch/x86/include/asm/lguest_hcall.h | 29 +++++++++++++--- arch/x86/lguest/boot.c | 61 +++++++++++++++++------------------ arch/x86/lguest/i386_head.S | 2 +- drivers/lguest/lguest_devi...

Dear testers, 7.0.0-rc1 was just tagged (from the branch at r338847). It's early in the release process, but I'd like to find out what the status is of the branch on our various platforms. Please run the test script, share the results, and upload binaries. Thanks, Hans

...the do-nothing hypercall to flush any stored calls. */ @@ -375,8 +377,8 @@ static void lguest_cpuid(unsigned int *ax, unsigned int *bx, case 1: /* Basic feature request. */ /* We only allow kernel to see SSE3, CMPXCHG16B and SSSE3 */ *cx &= 0x00002201; - /* SSE, SSE2, FXSR, MMX, CMOV, CMPXCHG8B, TSC, FPU. */ - *dx &= 0x07808111; + /* SSE, SSE2, FXSR, MMX, CMOV, CMPXCHG8B, TSC, FPU, PAE. */ + *dx &= 0x07808151; /* The Host can do a nice optimization if it knows that the * kernel mappings (addresses above 0xC0000000 or whatever * PAGE_OFFSET is set to) haven't chan...

...the do-nothing hypercall to flush any stored calls. */ @@ -375,8 +377,8 @@ static void lguest_cpuid(unsigned int *ax, unsigned int *bx, case 1: /* Basic feature request. */ /* We only allow kernel to see SSE3, CMPXCHG16B and SSSE3 */ *cx &= 0x00002201; - /* SSE, SSE2, FXSR, MMX, CMOV, CMPXCHG8B, TSC, FPU. */ - *dx &= 0x07808111; + /* SSE, SSE2, FXSR, MMX, CMOV, CMPXCHG8B, TSC, FPU, PAE. */ + *dx &= 0x07808151; /* The Host can do a nice optimization if it knows that the * kernel mappings (addresses above 0xC0000000 or whatever * PAGE_OFFSET is set to) haven't chan...

...a/arch/x86/lguest/boot.c +++ b/arch/x86/lguest/boot.c @@ -359,8 +359,12 @@ static void lguest_cpuid(unsigned int *ax, unsigned int *bx, case 1: /* Basic feature request. */ /* We only allow kernel to see SSE3, CMPXCHG16B and SSSE3 */ *cx &= 0x00002201; - /* SSE, SSE2, FXSR, MMX, CMOV, CMPXCHG8B, TSC, FPU. */ + /* SSE, SSE2, FXSR, MMX, CMOV, CMPXCHG8B, TSC, FPU, PAE. */ +#ifdef CONFIG_X86_PAE + *dx &= 0x07808151; +#else *dx &= 0x07808111; +#endif /* The Host can do a nice optimization if it knows that the * kernel mappings (addresses above 0xC0000000 or whatever * P...

...a/arch/x86/lguest/boot.c +++ b/arch/x86/lguest/boot.c @@ -359,8 +359,12 @@ static void lguest_cpuid(unsigned int *ax, unsigned int *bx, case 1: /* Basic feature request. */ /* We only allow kernel to see SSE3, CMPXCHG16B and SSSE3 */ *cx &= 0x00002201; - /* SSE, SSE2, FXSR, MMX, CMOV, CMPXCHG8B, TSC, FPU. */ + /* SSE, SSE2, FXSR, MMX, CMOV, CMPXCHG8B, TSC, FPU, PAE. */ +#ifdef CONFIG_X86_PAE + *dx &= 0x07808151; +#else *dx &= 0x07808111; +#endif /* The Host can do a nice optimization if it knows that the * kernel mappings (addresses above 0xC0000000 or whatever * P...