+++ This bug was initially created as a clone of Bug #216555 +++

Description of problem:
If I create a virtual disk (either a file, or block device backed) in the dom0
host with a size of 5 TB, and export this to a guest DomU, the domu will only
see it as being 1 TB in size. It looks as if the Xen virtual disk driver is
wrapping around at the 2 TB mark.

Version-Release number of selected component (if applicable):
xen-3.0.3-0.1.rc3
kernel-xen-2.6.18-1.2849.fc6

How reproducible:
Always (on 32-bit)

Steps to Reproduce:
1. Create an block device 7 TB in size
2. Export this to the DomU in the guest config file
3. Look at /proc/partitions inside the guest kernel
4. Look at /proc/partitions in the dom0 host kernel
  
Actual results:
The #blocks column for the disk is different in DomU & Dom0

Expected results:
The #blocks seen in DomU matches #blocks seen in Dom0

Additional info:
The same problem occurs for file backed virtual disks on 32-bit host/guest.

There is no problem on 64-bit kernels - I have exported disks as large as 15 PB
 to the guest.

This is all testing with paravirt guests. Not verified if fully virt guests have
any issues yet.


Post from Ian upstream suggests 32-bit wraparound in blkfront driver

http://lists.xensource.com/archives/html/xen-devel/2006-11/msg01023.html

-- Additional comment from berrange on 2006-11-21 07:39 EST --
Patch committed in xen-unstable.hg

http://xenbits.xensource.com/xen-unstable.hg?cs=0c0ef61de06b

-- Additional comment from berrange on 2006-11-21 17:44 EST --
I have tested the patch listed in comment #2 and confirmed it fixes operation of
file: and phy: backed disks > 2 TB in size. It does not, however, fix tap:aio:
backed disks.

-- Additional comment from berrange on 2006-11-21 17:45 EST --
Created an attachment (id=141844)
Patch for blktap based disks

This additional patch fixes blktap based disks which are > 2TB