[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] regression from c/s 22071:c5aed2e049bc (ept: Put locks around ept_get_entry) ?
- To: Olaf Hering <olaf@xxxxxxxxx>
- From: Keir Fraser <keir@xxxxxxx>
- Date: Fri, 17 Dec 2010 14:18:34 +0000
- Cc: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, Christoph Egger <Christoph.Egger@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>
- Delivery-date: Fri, 17 Dec 2010 06:19:43 -0800
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:user-agent:date :subject:from:to:cc:message-id:thread-topic:thread-index:in-reply-to :mime-version:content-type:content-transfer-encoding; bh=pDvailyjTr89AYPXfMCM51IzeNa8FMLuy6H/vCp4K2c=; b=XisYpaCksFEDwMdmJfL70DPMTo4ZmHpCRySnGBXXdhl6CswKiNbxwmOLhRj4VoT9Wv JdzSHVF0FPgdv7sgRAyUgZ2FbQycYYY+Y2Ca4nqi7erCyZvnbjaYd6OklGUtXmDdrWMp WheFK2w4v4C0+005o9GT+Y/fYXTTHWDhtBEPM=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=Ug6vGh/clun/NkrEPcQBx4LR2DUg+Fyt4zGPHZlL0h/3dGAX0HYO9J4enhbtIbVFkS Os/0rRQw8hM4OJyP2uPQgYXhExTYo3mjRHdb1+FwcerByJf3IXfFFGobrhVhJfdL8tTi 6KnaDM1rBOKC6uesEEVn4bXIc09SkpUuyrRS8=
- List-id: Xen developer discussion <xen-devel.lists.xensource.com>
- Thread-index: Acud9Um/2LOzdXHdGEC2zzmFdGyNJA==
- Thread-topic: [Xen-devel] regression from c/s 22071:c5aed2e049bc (ept: Put locks around ept_get_entry) ?
On 17/12/2010 14:03, "Olaf Hering" <olaf@xxxxxxxxx> wrote:
> On Thu, Dec 16, Keir Fraser wrote:
>
>> Excellent. I will lay groundwork and fix pte_{read,write}_atomic directly in
>> -unstable and -4.0-testing. I will then post a proposed fix for EPT to the
>> list. I don't know that code so well and I may not otherwise catch all
>> places that require use of the new accessor macros.
>
> Keir,
>
> this failure may be related to the changes that went just into
> xen-unstable, fails in openSuSE 11.2 and 11.3 on 32bit:
Oops, I stared at the atomic_write64() implementation a while, I had an old
version to basically copy across, and still I got it wrong. It's fixed by
xen-unstable c/s 22572.
Thanks,
Keir
> make[2]:âEnteringâdirectoryâ`/usr/src/packages/BUILD/xen-unstable.hg-4.1.22571
> /xen/arch/x86'
> gccâ-fomit-frame-pointerâ-fmessage-length=0â-O2â-Wallâ
> -D_FORTIFY_SOURCE=2â-fstack-protectorâ-funwind-tablesâ
> -fasynchronous-unwind-tablesâ-O1â-fno-omit-frame-pointerâ
> -fno-optimize-sibling-callsâ-m32â-march=i686â-gâ-fno-strict-aliasingâ
> -std=gnu99â-Wallâ-Wstrict-prototypesâ-Wno-unused-valueâ
> -Wdeclaration-after-statementââ-nostdincâ-fno-builtinâ-fno-commonâ
> -Wredundant-declsâ-iwithprefixâincludeâ-Werrorâ-Wno-pointer-arithâ-pipeâ
> -I/usr/src/packages/BUILD/xen-unstable.hg-4.1.22571/xen/includeââ
> -I/usr/src/packages/BUILD/xen-unstable.hg-4.1.22571/xen/include/asm-x86/mach-g
> eneric â
> -I/usr/src/packages/BUILD/xen-unstable.hg-4.1.22571/xen/include/asm-x86/mach-d
> efault â-msoft-floatâ-fno-stack-protectorâ-fno-exceptionsâ-gâ-D__XEN__â
> -DVERBOSEâ-DCRASH_DEBUGâ-fno-omit-frame-pointerâ-DCONFIG_FRAME_POINTERâ
> -DMAX_PHYS_CPUS=32â-MMDâ-MFâ.xen.dâ-O1â-fno-omit-frame-pointerâ
> -fno-optimize-sibling-callsâ-m32â-march=i686â-gâ-fno-strict-aliasingâ
> -std=gnu99â-Wallâ-Wstrict-prototypesâ-Wno-unused-valueâ
> -Wdeclaration-after-statementââ-nostdincâ-fno-builtinâ-fno-commonâ
> -Wredundant-declsâ-iwithprefixâincludeâ-Werrorâ-Wno-pointer-arithâ-pipeâ
> -I/usr/src/packages/BUILD/xen-unstable.hg-4.1.22571/xen/includeââ
> -I/usr/src/packages/BUILD/xen-unstable.hg-4.1.22571/xen/include/asm-x86/mach-g
> eneric â
> -I/usr/src/packages/BUILD/xen-unstable.hg-4.1.22571/xen/include/asm-x86/mach-d
> efault â-msoft-floatâ-fno-stack-protectorâ-fno-exceptionsâ-gâ-D__XEN__â
> -DVERBOSEâ-DCRASH_DEBUGâ-fno-omit-frame-pointerâ-DCONFIG_FRAME_POINTERâ
> -DMAX_PHYS_CPUS=32â-MMDâ-MFâ.asm-offsets.s.dâ-Sâ-oâasm-offsets.sâ
> x86_32/asm-offsets.c
> cc1:âwarningsâbeingâtreatedâasâerrors
> Inâfileâincludedâfromâ/usr/src/packages/BUILD/xen-unstable.hg-4.1.22571/xen/in
> clude/asm/spinlock.h:6,
> âââââââââââââââââfromâ/usr/src/packages/BUILD/xen-unstable.hg-4.1.22571/xen/in
> clude/xen/spinlock.h:6,
> âââââââââââââââââfromâ/usr/src/packages/BUILD/xen-unstable.hg-4.1.22571/xen/in
> clude/xen/sched.h:7,
> âââââââââââââââââfromâx86_32/asm-offsets.c:9:
> /usr/src/packages/BUILD/xen-unstable.hg-4.1.22571/xen/include/asm/atomic.h:âIn
> âfunctionâ'atomic_write64':
> /usr/src/packages/BUILD/xen-unstable.hg-4.1.22571/xen/include/asm/atomic.h:39:
> âerror:âoperationâonâ'old'âmayâbeâundefined
> make[2]:â***â[asm-offsets.s]âErrorâ1
> make[2]:âLeavingâdirectoryâ`/usr/src/packages/BUILD/xen-unstable.hg-4.1.22571/
> xen/arch/x86'
>
> 36 static inline void atomic_write64(volatile uint64_t *addr, uint64_t val)
> 37 {
> 38 uint64_t old = *addr, new, *__addr = (uint64_t *)addr;
> 39 while ( (old = __cmpxchg8b(__addr, old, val)) != old )
> 40 old = new;
> 41 }
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel