summary refs log tree commit diff stats
path: root/results/classifier/118/permissions/907063
diff options
context:
space:
mode:
Diffstat (limited to 'results/classifier/118/permissions/907063')
-rw-r--r--results/classifier/118/permissions/90706389
1 files changed, 89 insertions, 0 deletions
diff --git a/results/classifier/118/permissions/907063 b/results/classifier/118/permissions/907063
new file mode 100644
index 000000000..35233a8c2
--- /dev/null
+++ b/results/classifier/118/permissions/907063
@@ -0,0 +1,89 @@
+permissions: 0.818
+peripherals: 0.730
+semantic: 0.687
+user-level: 0.666
+graphic: 0.623
+assembly: 0.608
+hypervisor: 0.607
+arm: 0.568
+debug: 0.567
+device: 0.565
+register: 0.548
+risc-v: 0.527
+virtual: 0.520
+ppc: 0.500
+VMM: 0.492
+mistranslation: 0.490
+network: 0.489
+PID: 0.470
+performance: 0.459
+vnc: 0.438
+architecture: 0.416
+boot: 0.402
+x86: 0.401
+KVM: 0.401
+kernel: 0.397
+i386: 0.379
+socket: 0.378
+TCG: 0.340
+files: 0.338
+
+Error reading VMDK4 with footer instead of header
+
+VMDK4 files can have a footer in the last block, which is the same datastructure as the header but must be used instead if present. In this case, the gd_offset in the usual header at the beginning of the file is the special flag -1 (VMDK 1.1 spec, page 17, "GD_AT_END
+"). qemu-img doesn't know about this flag so it goes on to try to read extents with a bogus l1_table from the wrong location in the file.
+
+I have regression-tested this with various OVAs exported from VSphere/ESXi 3 and 4. Current master and all previous QEMU versions were unable to import any compressed VMDKs with a footer. It now works on all the ones I have. 
+
+bb45ded93115ad4303471c9a492579dc36716547 changed the order of gd_offset and rgd_offset in the VMDK4Header struct. Page 8 of the VMDK 1.1 spec from VMWare shows the structure as rgd_ then gd_, while QEMU now has gd_ *before* rgd_offset. I was only able to get VMDK conversion to work by switching the order back to that specified by VMWare and previously used by QEMU. I don't know what VMDK this commit is referring to, so I can't test to see if I've broken it. :(
+
+I will submit this patch to the mailing list if I get a chance, but I'm also uploading it here so I don't lose it.
+
+
+
+On Tue, Dec 20, 2011 at 8:53 PM, bbgordonn <email address hidden> wrote:
+> Public bug reported:
+>
+> VMDK4 files can have a footer in the last block, which is the same datastructure as the header but must be used instead if present. In this case, the gd_offset in the usual header at the beginning of the file is the special flag -1 (VMDK 1.1 spec, page 17, "GD_AT_END
+> "). qemu-img doesn't know about this flag so it goes on to try to read extents with a bogus l1_table from the wrong location in the file.
+>
+> I have regression-tested this with various OVAs exported from
+> VSphere/ESXi 3 and 4. Current master and all previous QEMU versions were
+> unable to import any compressed VMDKs with a footer. It now works on all
+> the ones I have.
+>
+> bb45ded93115ad4303471c9a492579dc36716547 changed the order of gd_offset
+> and rgd_offset in the VMDK4Header struct. Page 8 of the VMDK 1.1 spec
+> from VMWare shows the structure as rgd_ then gd_, while QEMU now has gd_
+> *before* rgd_offset. I was only able to get VMDK conversion to work by
+> switching the order back to that specified by VMWare and previously used
+> by QEMU. I don't know what VMDK this commit is referring to, so I can't
+> test to see if I've broken it. :(
+>
+> I will submit this patch to the mailing list if I get a chance, but I'm
+> also uploading it here so I don't lose it.
+>
+> ** Affects: qemu
+>     Importance: Undecided
+>         Status: New
+>
+> --
+> You received this bug notification because you are a member of qemu-
+> devel-ml, which is subscribed to QEMU.
+> https://bugs.launchpad.net/bugs/907063
+
+Thanks for reporting this.  I have CCed Fam who worked on VMDK this summer.
+
+Please submit patches to the mailing list according to the guidelines here:
+
+http://wiki.qemu.org/Contribute/SubmitAPatch
+
+Stefan
+
+
+Looks like something similar has been commited here:
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=65bd155c7356d448ffee7
+So is this problem fixed nowadays?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+