From: Paulo Alcantara <pcacjr@zytor.com>
To: Laszlo Ersek <lersek@redhat.com>,
"Shi, Steven" <steven.shi@intel.com>,
edk2-devel-01 <edk2-devel@lists.01.org>
Cc: "Ni, Ruiyu" <ruiyu.ni@intel.com>,
"Dong, Eric" <eric.dong@intel.com>,
"Zeng, Star" <star.zeng@intel.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [PATCH 0/5] MdeModulePkg: UDF fixes and cleanups
Date: Mon, 11 Sep 2017 10:55:05 -0300 [thread overview]
Message-ID: <aa4f8367-50e9-b015-237d-81881ceef48c@zytor.com> (raw)
In-Reply-To: <603a48bb-2e8c-7931-a580-2fbf5662d1aa@redhat.com>
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
next prev parent reply other threads:[~2017-09-11 13:56 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-10 0:12 [PATCH 0/5] MdeModulePkg: UDF fixes and cleanups Laszlo Ersek
2017-09-10 0:13 ` [PATCH 1/5] MdeModulePkg/UdfDxe: ASSERT() valid ReadFileInfo Flags for INLINE_DATA req Laszlo Ersek
2017-09-10 0:13 ` [PATCH 2/5] MdeModulePkg/UdfDxe: don't return unset Status if INLINE_DATA req succeeds Laszlo Ersek
2017-09-12 9:06 ` Zeng, Star
2017-09-10 0:13 ` [PATCH 3/5] MdeModulePkg/UdfDxe: replace zero-init of local variables with ZeroMem() Laszlo Ersek
2017-09-12 8:55 ` Zeng, Star
2017-09-12 9:38 ` Ni, Ruiyu
2017-09-12 9:57 ` Laszlo Ersek
2017-09-12 10:02 ` Zeng, Star
2017-09-12 9:55 ` Laszlo Ersek
2017-09-10 0:13 ` [PATCH 4/5] MdeModulePkg/PartitionDxe: don't divide 64-bit values with C operators Laszlo Ersek
2017-09-12 5:41 ` Bi, Dandan
2017-09-12 7:58 ` Laszlo Ersek
2017-09-12 8:28 ` Ni, Ruiyu
2017-09-12 8:46 ` Zeng, Star
2017-09-10 0:13 ` [PATCH 5/5] MdeModulePkg/PartitionDxe: remove always false comparison Laszlo Ersek
2017-09-12 8:50 ` Zeng, Star
2017-09-10 4:24 ` [PATCH 0/5] MdeModulePkg: UDF fixes and cleanups Shi, Steven
2017-09-10 8:38 ` Laszlo Ersek
2017-09-10 13:52 ` Laszlo Ersek
2017-09-10 14:27 ` Shi, Steven
2017-09-10 15:51 ` Paulo Alcantara
2017-09-11 6:58 ` Laszlo Ersek
2017-09-11 13:55 ` Paulo Alcantara [this message]
2017-09-11 13:07 ` Shi, Steven
2017-09-11 13:26 ` Ni, Ruiyu
2017-09-11 13:26 ` Laszlo Ersek
2017-09-11 13:52 ` Paulo Alcantara
2017-09-11 14:00 ` Shi, Steven
2017-09-10 15:05 ` Paulo Alcantara
2017-09-11 11:58 ` Ard Biesheuvel
2017-09-12 10:14 ` Laszlo Ersek
2017-09-12 15:38 ` Ard Biesheuvel
2017-09-12 21:29 ` Laszlo Ersek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aa4f8367-50e9-b015-237d-81881ceef48c@zytor.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox