search for: popfs

...s, 2011) [downloadable] deadspace Dead Space (EA, 2008) deadspace2 Dead Space 2 (drm broken on wine) (EA, 2011) dragonage_ue Dragon Age: Origins - Ultimate Edition (Bioware / EA, 2010) mise Monkey Island: Special Edition (LucasArts, 2009) popfs Prince of Persia The Forgotten Sands (Ubisoft, 2010) splitsecond Split Second (Disney, 2010) splitsecond_demo Split Second Demo (Disney, 2010) [downloadable] spore Spore (EA, 2008) For bug tracker, mailing lists, and wiki, see http://win...

Hello all, I am trying to implement intrinsics __readeflags and __writeeflags reading and writing EFLAGS register on x86. These intrinsics expand to two instructions popf and push to register for __readeflags and pushf and pop to register for __writeeflags. These instructions are not connected explicitly so I can't use patterns in .td file to match intrinsics. I tried to implement custom

Pavel Machek wrote: > Hi! > > >> 6) Interrupts must always be enabled when running code in userspace. >> > > I'd say this breaks userspace. > I agree. My claim is that this is not an issue in a virtual machine. What possible reason can you have to disable interrupts in userspace? Well, several. For one, the X server wants to disable

Pavel Machek wrote: > Hi! > > >> 6) Interrupts must always be enabled when running code in userspace. >> > > I'd say this breaks userspace. > I agree. My claim is that this is not an issue in a virtual machine. What possible reason can you have to disable interrupts in userspace? Well, several. For one, the X server wants to disable

I don't know enough about LLVM CodeGen to answer your questions. I'm just curious. What is the intended level of support for these intrinsics? Are they for reading ALU flags like CF, OF, etc, or for seldom changed control flags like TF and AC? Even DF is typically scratch, and could be used for an -Oz memmove lowering for example. I don't think LLVM will ever really support

Agreed, never emit pushf/popf. Sorry I never committed the patch, the cmov issue got hairy and I never got to debugging it :-) I can get back to it if there's interest! On Wed, Jul 29, 2015 at 4:12 PM, Reid Kleckner <rnk at google.com> wrote: > I remember this bug. :) IMO, LLVM should never emit pushf / popf. I'm not > sure this patch to fix it ever got committed: >

I am new to the LLVM backends, I am wondering how instruction selection is done in LLVM backends, I looked at the .td files in Target/X86, they all seem to be small and do not deal with common X86 instructions, i.e. mov, push, pop, etc. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Fri, Aug 07, 2020 at 10:38:23AM +0200, Juergen Gross wrote: > -# else > - const unsigned char cpu_iret[1]; > -# endif > }; > > static const struct patch_xxl patch_data_xxl = { > @@ -42,7 +38,6 @@ static const struct patch_xxl patch_data_xxl = { > .irq_save_fl = { 0x9c, 0x58 }, // pushf; pop %[re]ax > .mmu_read_cr2 = { 0x0f, 0x20, 0xd0 }, // mov %cr2,

On Fri, Aug 07, 2020 at 10:38:23AM +0200, Juergen Gross wrote: > -# else > - const unsigned char cpu_iret[1]; > -# endif > }; > > static const struct patch_xxl patch_data_xxl = { > @@ -42,7 +38,6 @@ static const struct patch_xxl patch_data_xxl = { > .irq_save_fl = { 0x9c, 0x58 }, // pushf; pop %[re]ax > .mmu_read_cr2 = { 0x0f, 0x20, 0xd0 }, // mov %cr2,

Hi all, Does anyone have thoughts on extending v->arch.hvm_vcpu.single_step to support pre-MTF systems, in a way that would mimic the MTF? So far I''m emulating PUSHF/POPF to hide the hypervisor''s trap flag, and eventually I''ll multiplex it down to the guest, but I''m having issues. Right now, I''m enabling X86_EFLAGS_TF in vmx_intr_assist, just like

I remember this bug. :) IMO, LLVM should never emit pushf / popf. I'm not sure this patch to fix it ever got committed: http://reviews.llvm.org/D6629 On Wed, Jul 29, 2015 at 3:11 PM, Michael Hordijk <hoffbrinkle at hotmail.com> wrote: > > Using Clang/LLVM 3.6.0 we are observing a case where the optimizations are > clobbering EFLAGS on x86_64. This is inconvenient when the

On 7/29/15 18:35, JF Bastien wrote: > Agreed, never emit pushf/popf. Sorry I never committed the patch, the > cmov issue got hairy and I never got to debugging it :-) > I can get back to it if there's interest! You've definitely got some interest here. I've been looking at your patch on http://reviews.llvm.org/D6629 and I think I'm up to speed on where it's stuck.

On 06/05/18 10:05, Nick Desaulniers wrote: > + > +/* > + * void native_restore_fl(unsigned long flags) > + * %rdi: flags > + */ > +ENTRY(native_restore_fl) > + push %_ASM_DI > + popf > + ret > +ENDPROC(native_restore_fl) > +EXPORT_SYMBOL(native_restore_fl) > To work on i386, this would have to be %_ASM_AX in that case. Something like this added to

On 06/05/18 10:05, Nick Desaulniers wrote: > + > +/* > + * void native_restore_fl(unsigned long flags) > + * %rdi: flags > + */ > +ENTRY(native_restore_fl) > + push %_ASM_DI > + popf > + ret > +ENDPROC(native_restore_fl) > +EXPORT_SYMBOL(native_restore_fl) > To work on i386, this would have to be %_ASM_AX in that case. Something like this added to

I found a clever way to make the extra IOPL switching invisible to non-paravirt compiles - since kernel_rpl is statically defined to be zero there, and only non-zero rpl kernel have a problem restoring IOPL, as popf does not restore IOPL flags unless run at CPL-0. Subject: IOPL handling for paravirt guests Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r 8110943fd7ad

Steven Hi, I'm unable to compile testcpuid.c with the __x86_64__ architecture (Athlon 64 processor). The messages are: /tmp/ccONleRV.s: Assembly messages: /tmp/ccONleRV.s: Error: suffix or operands invalid for 'pushf' " 'pop' " 'push' " 'popf' Is it safe to ignore this module? When I attempt to start asterisk, libspandsp.so.0 fails to load

Is there any stable version of spandsp that works on a 64 bit Linux on an AMD64 machine. When compiling version 0.0.1k I get the following error: gcc -DHAVE_CONFIG_H -I. -I. -I. -I -g -O2 -c testcpuid.c -MT testcpuid.lo -MD -MP -MF .deps/testcpuid.TPlo -fPIC -DPIC -o .libs/testcpuid.lo /tmp/ccXxGHg6.s: Assembler messages: /tmp/ccXxGHg6.s:8: Error: suffix or operands invalid for `pushf'

I found a clever way to make the extra IOPL switching invisible to non-paravirt compiles - since kernel_rpl is statically defined to be zero there, and only non-zero rpl kernel have a problem restoring IOPL, as popf does not restore IOPL flags unless run at CPL-0. Subject: IOPL handling for paravirt guests Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r 8110943fd7ad

Hi, I have some confusion on local_irq_save() and local_irq_restore(). From the definitions, you can see that local_irq_save() calls local_irq_disable(). But why there is no local_irq_enable() in local_irq_restore? #define local_irq_save(x) ({ local_save_flags(x); local_irq_disable(); }) #define local_irq_restore(x) ({ BUILD_BUG_ON(sizeof(x) != sizeof(long)); asm volatile (

Hi all, I'm a Theora noob and just taking a look at the theora-mmx package in hopes of making Thoggen run faster for DVD ripping. I've checked out the latest svn of the theora-mmx branch and trying to compile it on Ubuntu Dapper AMD64. I run autogen.sh, then make, and soon get the following errors: make[2]: Entering directory `/home/dlenski/theora-mmx/lib' if /bin/sh ../libtool