Re: [Xen-devel] [patch] make evtchn_upcall_pending arch-specific type

[Jimi Xenidis <jimix@xxxxxxxxxxxxxx>]

On Mar 31, 2006, at 7:46 AM, Keir Fraser wrote:

> On 30 Mar 2006, at 20:13, Hollis Blanchard wrote:
>
> > evtchn_upcall_pending is another variable that bitops are used on,  
> > so PowerPC
> > wants it to be a long. Unfortunately, it's also part of the guest/ 
> > hypervisor
> > interface, so we can't change it for architectures with existing  
> > guests.
> > Compile-tested on x86(-32). Please apply.
> Before going down this route, what about just casting the field to  
> long, since it is actually aligned on a suitable boundary, as it  
> happens?
We tried that, but to get the right bit we would have to use 56 not 0.
So this brings me to a possible solution:
Since both evtchn_upcall_pending and mask are paired and aligned and  
padded to long we could group them together, like:
        unsigned long evtchn_upcall_bits;
Then:
        #define EVTCHN_UPCALL_PENDING 0
        #define EVTCHN_UPCALL_MASK 8

use the macros to define the bit arg of the bitop_*().
I chose these values because they would be completely compatible with  
any assembler that exist for the itty bitty byte arches. :)  As for  
PPC the values don't matter to us, at this early stage.
We could also get into magical union/structs with more abstracted  
interfaces, but the above is rather simple.

> And what will your solution be for fields in grant_entry structure?
yeah, grant_entry.flags will be a pain because it is 16 bit and you  
also use cmpxchg() on it.
I suppose we could abstract those bit changes, but yeah, this one is  
gonna hurt :(
> That's another one where the fields to be atomically updated are at  
> least 8-byte aligned, and where using longer types will bloat a  
> structure that we'd prefer to pack nicely.
The I'd rather bloat (for PPC only) then come up with some nasty read/ 
calculate-the-actual-bit-and-modify/write.
> If this is the best way for ppc then I think atomic_bit_t would be  
> a nicer typedef.
I think a context specific typedef would be better, in most cases.
Also,
  - I'd like to see more use of DECLARE_BITMAP() for stuff like  
pirq_mask
  - more use of BITS_PER_LONG instead of (sizeof(long)*8) that  
occurs in many places like evtchn_pending[]
-JX

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel