From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bedivere.hansenpartnership.com (bedivere.hansenpartnership.com [96.44.175.130]) by mx.groups.io with SMTP id smtpd.web12.686.1628637876773872659 for ; Tue, 10 Aug 2021 16:24:36 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@hansenpartnership.com header.s=20151216 header.b=lF1dGyP5; spf=pass (domain: hansenpartnership.com, ip: 96.44.175.130, mailfrom: james.bottomley@hansenpartnership.com) Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id 1834D1280658; Tue, 10 Aug 2021 16:24:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1628637876; bh=/Qj62ORhkTCQPk2LpT75p74qz/6BPObMWbdhLX7xAWI=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=lF1dGyP58aYLcIRi/StulePN70kTOI9z9fy+QhVFVVGB4DOL90o2B9Yr8ge9dKTuA THS2oXPa+wRfP4Nsf8Ty0crGrgeSaCXfkhs5NRfd1QBM+u4YhrA0ijt43wKMfr1oXC 3bINLHf2DpqbKA4mI2W+37oSr+R1goAS7aVs0LAQ= Received: from bedivere.hansenpartnership.com ([127.0.0.1]) by localhost (bedivere.hansenpartnership.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEOc_JDcuNfD; Tue, 10 Aug 2021 16:24:36 -0700 (PDT) Received: from jarvis.int.hansenpartnership.com (unknown [IPv6:2601:600:8280:66d1::527]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id 9DC0B1280653; Tue, 10 Aug 2021 16:24:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1628637875; bh=/Qj62ORhkTCQPk2LpT75p74qz/6BPObMWbdhLX7xAWI=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=VmvS+b+Cxgli1F91Qo0bU5HfYq2N9QZhBINsM9Z1F3qCgd5luVLw8mqkEDjQoyd5i Qip6GunHcfOzreHf4L1Xkj15HrBrzv5A5l2/nWcjtykm5KD6dT+rUNC6yi+lwpnTAL Qn5MMwP0fVFMqsWUlME8cBKBcsATwsMLxrF6PzCU= Message-ID: <8286f815812caccbffaa3696f5e884a62ec0a046.camel@HansenPartnership.com> Subject: Re: [edk2-devel] [PATCH 1/1] OvmfPkg PlatformBootManagerLib: Move TryRunningQemuKernel() From: "James Bottomley" To: devel@edk2.groups.io, chris.willing@linux.com Cc: ardb+tianocore@kernel.org, jiewen.yao@intel.com, Gerd Hoffmann Date: Tue, 10 Aug 2021 16:24:34 -0700 In-Reply-To: <7dc3b9d2-5ebb-c261-46b4-658dcbbfd0f4@linux.com> References: <20210728020232.127332-1-chris.willing@linux.com> <1695D2E15A92C8E7.3876@groups.io> <62f9ffa0-786f-09dd-9546-c4c118fa2a17@linux.com> <1b544f28-b5b9-c08c-bab7-8c1f41778dce@linux.com> <5c85a3f963d1ab7d20e177db9a07a73e82a0eed0.camel@HansenPartnership.com> <7dc3b9d2-5ebb-c261-46b4-658dcbbfd0f4@linux.com> User-Agent: Evolution 3.34.4 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Wed, 2021-08-11 at 09:04 +1000, Christoph Willing wrote: > On 11/8/21 12:26 am, James Bottomley wrote: > [...] > > In the working kernel dmesg Gerd requested, what does it mount as > > root? sda? In which case what does the kernel say about where it > > got sda from? > > > Yes it mounts /dev/sda2 as root. > > The boot logs are are now attached at > https://bugzilla.tianocore.org/show_bug.cgi?id=3504 as well a diff > between good and bad boots (patched & unpatched code). There's > nothing obvious (to me) as to why the unpatched code can't find the > virtual disk. > > My simple minded guess is that PlatformBdsConnectSequence() performs > some preparatory work that enables the kernel to have access to the > vm (therefore to the virtual disk) by the time TryRunningQemuKernel() > is called. At the moment however, TryRunningQemuKernel() is called > before PlatformBdsConnectSequence() so that preparatory work hasn't > been done and the disk can't be found. I suspect the problem is that it no longer creates default devices if you don't specify them. If I look at my working version of a command line boot, it's this: qemu-kvm \ -drive if=pflash,format=raw,unit=0,file=/home/jejb/git/edk2/Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd,readonly \ -debugcon file:debug.log -global isa-debugcon.iobase=0x402 \ -kernel bzImage \ -initrd initrd.img \ -append "console=ttyS0 rd.driver.pre=virtio_scsi,9p,9pnet_virtio root=/dev/sda1" \ -m 2048 \ -serial stdio \ -drive if=none,id=sd00,file=debian.img,format=qcow2 \ -fsdev local,security_model=passthrough,id=modules,path=/tmp/lib/modules \ -fsdev local,security_model=passthrough,id=home,path=/home/jejb \ -device virtio-scsi-pci,id=scsi \ -device virtio-9p-pci,fsdev=modules,id=sd01,mount_tag=modules \ -device virtio-9p-pci,fsdev=home,id=sd02,mount_tag=home \ -device scsi-hd,bus=scsi.0,drive=sd00 \ -device e1000,netdev=net0 \ -netdev user,id=net0,hostfwd=tcp::5555-:22 \ -display vnc=:5 \ # -chardev socket,id=chrtpm,path=`pwd`/tpmdev/swtpm-sock \ # -tpmdev emulator,id=tpm0,chardev=chrtpm \ # -device tpm-tis,tpmdev=tpm0 \ You can ignore all the TPM stuff and my 9p pass throughs for home directory and /tmp modules directory (to make it easy to boot any kernel I build). The relevant lines for you are: -drive if=none,id=sd00,file=debian.img,format=qcow2 \ -device virtio-scsi-pci,id=scsi \ -device scsi-hd,bus=scsi.0,drive=sd00 \ Which is how I connect /dev/sda to the qcow2 debian image I use to boot. You have the drive line but no device lines giving the driver ... if you add device lines can you then get it to boot? James