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