From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.zytor.com (terminus.zytor.com [65.50.211.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 8DEEE21E87985 for ; Mon, 11 Sep 2017 06:56:38 -0700 (PDT) Received: from [IPv6:2804:7f4:c480:d1ee::2] ([IPv6:2804:7f4:c480:d1ee:0:0:0:2]) (authenticated bits=0) by mail.zytor.com (8.15.2/8.15.2) with ESMTPSA id v8BDt6tG008207 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 11 Sep 2017 06:55:08 -0700 To: Laszlo Ersek , "Shi, Steven" , edk2-devel-01 Cc: "Ni, Ruiyu" , "Dong, Eric" , "Zeng, Star" , Ard Biesheuvel References: <20170910001304.8628-1-lersek@redhat.com> <06C8AB66E78EE34A949939824ABE2B313B57E700@shsmsx102.ccr.corp.intel.com> <5d0d40da-5d93-2be7-f8ef-73e981b48f49@redhat.com> <06C8AB66E78EE34A949939824ABE2B313B57EAA3@shsmsx102.ccr.corp.intel.com> <603a48bb-2e8c-7931-a580-2fbf5662d1aa@redhat.com> From: Paulo Alcantara Message-ID: Date: Mon, 11 Sep 2017 10:55:05 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <603a48bb-2e8c-7931-a580-2fbf5662d1aa@redhat.com> Subject: Re: [PATCH 0/5] MdeModulePkg: UDF fixes and cleanups X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 13:56:38 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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