[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [Patch 1/3 v2] x86/irq: local_irq_restore() should not blindly popf
>>> On 22.10.13 at 10:56, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote: > On 22/10/13 09:35, Jan Beulich wrote: >> Further I have a hard time seeing how the "orw" used above >> can even have built successfully: If a register gets picked >> (which ought to be the common case), opcode suffix and >> register name ought to collide. And "orw" is a bad choice here >> anyway, in that this is a 2-byte write following an 8-byte one. > > GCC correctly picks a 2-byte register given the orw. Looking at the > disassembly, it usually chooses %r12w Try compiling this void test(unsigned long x) { asm volatile("orw %0, (%0)" :: "ri" (x)); } with a 32-bit gcc (or with -m32). In fact I'm surprised the assembler doesn't generate a warning (or even error) in the 64-bit case - this very much smells like a bug (and I looked at that code the other day and got the impression that the 64-bit one would be _less_ forgiving here). In any event - if you want to stay with "orw", you ought to use "%w<number>" for the operand. > Why is symmetry of writes important here? We are possibly setting bit 9 > alone. Store-to-load-forwarding works only when the store size is larger than the load one. So I shouldn't have drawn your attention to the preceding "andq" but to the following "pushfq" (though I wouldn't be surprised if mixed size writes to overlapping memory locations would also suffer from penalties). Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |