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/
Home Products Support Community News


Re: [Xen-devel] RFC: 32 bits as smallest atomic size.

>>>>> "KF" == Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> writes:

 KF> On 25 Mar 2005, at 23:49, Jimi Xenidis wrote:

 >> A few issues:
 >> 1) this assumes that the quantity is wholy contained in our atomic
 >> unit, by using packed there is no way to guarantee that.

 KF> We always naturally align fields, even in packed structs. The compiler 
 KF> doesn't do it for us, but we check it manually.

hmm, is it padding you are trying to avoid?
Perhaps not using packed and adding the gcc option '-Wpadded' which
will automagically catch the offenders for you might be more

Depending on manually checking can result in performance and
correctness issues that are difficult to track.

 >> 2) it would have to be a runtime decision on all PPC atomic
 >> operations that could fail with no real failure path available.

 KF> It may have to be a run-time decision unless we can come up with some 
 KF> clever trick. I don't understand what you mean about there being no 
 KF> failure path.

These are atomic operation, usually used in contexts where printing or
any other feedback is unavailable.

 KF> This may make sense since we do update those two fields as a pair. We 
 KF> have a big update to the grant table code about to be checked in. We 
 KF> shoudl hold off doing this kind of fix until after the update has been 
 KF> committed.

Agreed, its not like I'm even at the point of running this code :)
However, some attention to endianness would also be appreciated,
example common/grant_table.c:870 (and friends)
        /* Merge two 16-bit values into a 32-bit combined update. */
        /* NB. Endianness! */
        prev_scombo = scombo = ((u32)sdom << 16) | (u32)sflags;

 KF> We always naturally align fields. We may do *subword* accesses 
 KF> sometimes, but they are always naturally aligned and will never 
 KF> straddle a cacheline. I think that subword accesses should get fixed up 
 KF> in your ppc macros.

Could we not simply avoid *subword* accesses in common code as a rule?
It costs x86 nothing to do this and results in portable code.

SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
Xen-devel mailing list