public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
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


  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