From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 6019421E87979 for ; Sun, 10 Sep 2017 23:55:38 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 458B0C0924CA; Mon, 11 Sep 2017 06:58:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 458B0C0924CA Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=lersek@redhat.com Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-112.phx2.redhat.com [10.3.116.112]) by smtp.corp.redhat.com (Postfix) with ESMTP id 92D795C54A; Mon, 11 Sep 2017 06:58:31 +0000 (UTC) To: Paulo Alcantara , "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> From: Laszlo Ersek Message-ID: <603a48bb-2e8c-7931-a580-2fbf5662d1aa@redhat.com> Date: Mon, 11 Sep 2017 08:58:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Mon, 11 Sep 2017 06:58:33 +0000 (UTC) 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 06:55:38 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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