WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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


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