• This patch allows the use a host_device as the destination for "qemu-img
    convert".
    
    I added a ->bdrv_create function host_device.  It merely verifies that
    the device exists and is large enough.
    
    A check is needed in the qemu-img convert loop to ensure that we write
    out all 0 sectors to the host_device.  Otherwise they end up with stale
    garbage where all zero sectors were expected.
    
    I also made the check against bdrv_is_allocated enabled for everything
    _except_ host devices, since there is no point in making the block
    backend write a bunch of zeros just so that we can memcmp them
    immediately afterwards.  Host devices can't benefit from this because
    there is no way to differentiate between a sector being unallocated
    because it was never written, or because it was written with all zeros
    and then made a trip through qemu-img convert.
    
    Finally, there is an unrelated fix for a typo in the error message
    printed if the destination device does not support ->bdrv_create.
    
    Signed-off-by: Nolan Leake <nolan <at> sigbus.net>
    Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
    
    
    git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6978 c046a42c-6fe2-441c-8c8c-71466251a162
    aliguori authored
     
    Browse Code »
  • qcow2's get_cluster_offset() scans forward in the l2 table to find other
    clusters that have the same allocation status as the first cluster.
    This is used by (among others) qcow_is_allocated().
    
    Unfortunately, it was not checking to be sure that it didn't fall off
    the end of the l2 table.  This patch adds that check.
    
    The symptom that motivated me to look into this was that
    bdrv_is_allocated() was returning false when there was in fact data
    there.  This is one of many ways this bug could lead to data corruption.
    
    I checked the other place that scans for consecutive unallocated blocks
    (alloc_cluster_offset()) and it appears to be OK:
        nb_clusters = MIN(nb_clusters, s->l2_size - l2_index);
    appears to prevent the same problem from occurring.
    
    Signed-off-by: Nolan Leake <nolan <at> sigbus.net>
    Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
    
    
    git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6977 c046a42c-6fe2-441c-8c8c-71466251a162
    aliguori authored
     
    Browse Code »
  • With the help of some Limoncino I noted several aspects of the QEMU coding
    style, particularly where it differs from the Linux coding style as many
    contributors work on both projects.
    
    Signed-off-by: Avi Kivity <avi@redhat.com>
    Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
    
    
    git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6976 c046a42c-6fe2-441c-8c8c-71466251a162
    aliguori authored
     
    Browse Code »
  • I believe this is behind the following:
    https://bugs.edge.launchpad.net/ubuntu/jaunty/+source/linux/+bug/331128
    
    virtio_pci in 2.6.25 didn't do feature negotiation correctly: it acked every
    bit.  Fortunately, we can detect this.
    
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
    Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
    
    
    git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6975 c046a42c-6fe2-441c-8c8c-71466251a162
    aliguori authored
     
    Browse Code »