Re: [Xen-devel] [Patch 1/3 v2] x86/irq: local_irq_restore() should not blindly popf

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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