On 09/10/17 17:51, Paulo Alcantara wrote: > > > On 10/09/2017 11:27, Shi, Steven wrote: >> OK. Does the UDF image you created correctly show up as CD-ROM content >> in Linux, e.g Fedora? > > The Fedora image I have (Fedora-Workstation-Live-x86_64-26-1.5.iso) does > not contain a valid UDF file system, so you cannot use it for testing. > > To make sure it really doesn't, I used a "Philips UDF Conformance Tool" > that you can grab in [1], and the tool didn't find any valid UDF file > system in it. > > I've been using an unmodified Windows 10 Enterprise image that does > contain a valid UDF bridge disk image (ISO9660+ElTorito+UDF) to perform > my tests. > > Additionally, I use an USB stick that I format it with 'sudo mkudffs -b > 512 --media-type=hd /dev/sdX' and copy some files to it for testing > > BTW, when testing with OVMF AARCH64, I was using my USB stick that > showed up correctly as 'fsX' in UEFI shell, but with the Windows 10 > Enterprise ISO image, it didn't. I looked at the logs to see what was > going on and I found out that the emulated CD-ROM drive is reporting a > block size of 512 instead of 2048 -- which seems wrong to me. With > 'qemu-system-x86_64 -cdrom', it reports a block size of 2048. > > The Partition driver is still able to find a valid ElTorito partition > because, regardless the device block size, it always use a logical block > size of 2048 starting at 32K. In UDF, when searching for AVDPs (Anchor > Volume Descriptor Pointers), we search for them at fixed locations: 256, > N - 256, N and 512 -- but, with a block size of 512, the locations > change to 1024, N - 1024, N and 2048 -- thus breaking the volume > recognition sequence. > > For testing the Windows image with a block size of 512, I used the > comformance tool with './udf_test -verbose 60 -blocksize 512 > ~/img/win_ent10.iso' and it failed to find a valid UDF file system. But > with a block size of 2048, it worked. > > Is there any reason for reporting a block size of 512 when using > '-cdrom' option in qemu-system-aarch64? Is that a bug? Or am I missing > something here?
"-cdrom" is a legacy QEMU option, a shorthand that expands to a -drive option, and at least one -device option (it could expand to multiple -device options). And, this expansion can be different on different machine types. On i440fx machine types, -cdrom can mean an IDE CD, on q35, an AHCI CD, an aarch64/virt, a virtio-scsi-pci controller and a scsi-cd. For this reason, it is always best to use complete -drive and -device specifications (which is equivalent to saying it is best to always use libvirt). Now, the above does not imlpy that no bug can exist in this space. Can you run the "info qtree" monitor command, in both cases, and compare the output with regard to the CD-ROM? Thanks Laszlo > Thanks! > Paulo > > [1] - https://www.lscdweb.com/registered/udf_verifier.html _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
