Il 31/05/2014 03:20, Kevin O'Connor ha scritto:
I don't see much benefit in this change, in fact the new code is more complex than the old one... But anyway, if you prefer to go this way I have just a couple observations on the patch:
1) acquiring the lock can be done simply by a "1: lock btsl; jc 1b"; no need to use the cmpxchg.
2) There's no need to acquire the lock repeatedly in the BSP, I think writing the loop in assembly is acceptable:
asm volatile( "movl %%esp, %1\n" // Release lock, other processors use the stack now "mov $0, %0\n" "1: cmp %3, %2\n" "rep; nop\n" "jne 1b\n" // Reacquire lock; last processor is still using the stack! "1b: lock btsl $0, %0\n" "rep; nop\n" "jc 1b\n" : "+m" (SMPLock), "=m" (SMPStack) : "r" (cmos_smp_count), "m" (CountCPUs) : "cc", "memory");
Paolo
On Sat, May 31, 2014 at 12:12:13PM +0200, Paolo Bonzini wrote:
Thanks for reviewing!
The reason I implemented this is to reduce the amount of 16bit code. The fw/smp.c file is currently being compiled in 16bit mode just to pick up the ~30 lines of assembler. I'd prefer to jump into 32bit mode to avoid that.
As to converting the handler to C code - I agree with you on code complexity, however I do think the existing assembler was already sufficiently complex. Also, being able to use dprintf() is quite nice.
Thanks - that is an improvement.
I'll rework the patch and take a look at that.
-Kevin