aboutsummaryrefslogtreecommitdiffstats
path: root/tools/libxc/xc_bitops.h
Commit message (Collapse)AuthorAgeFilesLines
* tools/libxc: remove volatile keyword for bitmap operationsOlaf Hering2012-01-311-5/+5
| | | | | | | | | | | | All bitmaps maintained by xc_bitops.h are used in single threaded applications. So nothing will change the bitmaps content, adding volatile adds just unneeded memory reloads. xenpaging uses bitmaps alot and using non-volatile versions will slightly improve performance. Signed-off-by: Olaf Hering <olaf@aepfle.de> Committed-by: Keir Fraser <keir@xen.org>
* libxc: add bitmap_clear functionOlaf Hering2011-11-201-0/+6
| | | | | Signed-off-by: Olaf Hering <olaf@aepfle.de> Committed-by: Ian Jackson <ian.jackson.citrix.com>
* tools: merge several bitop functions into xc_bitops.hOlaf Hering2011-06-101-0/+57
Bitmaps are used in save/restore, xenpaging and blktap2. Merge the code into a private xc_bitops.h file. All users are single threaded, so locking is not an issue. The array of bits is handled as volatile because the x86 save/restore code passes the bitmap to the hypervisor which in turn modifies the bitmap. blktap2 uses a private bitmap. There was a possible overflow in the bitmap_size() function, the remainder was not considered. ia64 save/restore uses a bitmap to send the number of vcpus to the host. x86 save/restore uses a bitmap to track dirty pages. This bitmap is shared with the hypervisor. An unused function count_bits() was removed and a new bitmap_size() function is now used. xenpaging uses 3 private bitmaps to track the gfns which are in paged-out state. It had a copy of some Linux bitops.h, which is now obsolete. Also the BITS_PER_LONG macro was hardcoded to 64 which made it impossible to run 32bit tools on a 64bit host. Wether this works at all has to be tested, yet. Signed-off-by: Olaf Hering <olaf@aepfle.de> Committed-by: Ian Jackson <ian.jackson.citrix.com>