On 11/09/2017 03:58, Laszlo Ersek wrote:
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?
OK. Thanks for clarifying that to me. I'll do it when I have a chance
and tell you.
Paulo
Thanks
Laszlo
Thanks!
Paulo
[1] - https://www.lscdweb.com/registered/udf_verifier.html
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
