It has been discovered that i386 boxes with more than 4G of RAM would
randomly crash. It was traced to the interface of blktap using
gnttab_set_map_op.
It would pass in the 64 bit pte entry, but the gnttab_set_map_op would
only take a 32 bit (on i386) unsigned long as a parameter. So we lose
the top 32bits.
Luckily! The kernel/HV ABI used a uint64_t as the variable to pass the
address. So this does *NOT* break the current kernel/HV ABI.
But after the HV grabs the 64 bit address from the guest, it too calls a
function that uses a unsigned long (32bits on i386) to pass that address
with. So the HV side also chops off the top 64 bits of the variable.
This patch updates both the linux-2.6-sparse tree and the xen HV to use
uint64_t instead of unsigned long for those particular functions. This
patch has been tested on RHEL5 Beta on a box with 12G i386.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
randomly crash. It was traced to the interface of blktap using
gnttab_set_map_op.
It would pass in the 64 bit pte entry, but the gnttab_set_map_op would
only take a 32 bit (on i386) unsigned long as a parameter. So we lose
the top 32bits.
Luckily! The kernel/HV ABI used a uint64_t as the variable to pass the
address. So this does *NOT* break the current kernel/HV ABI.
But after the HV grabs the 64 bit address from the guest, it too calls a
function that uses a unsigned long (32bits on i386) to pass that address
with. So the HV side also chops off the top 64 bits of the variable.
This patch updates both the linux-2.6-sparse tree and the xen HV to use
uint64_t instead of unsigned long for those particular functions. This
patch has been tested on RHEL5 Beta on a box with 12G i386.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>