Re: [edk2-devel] [PATCH 1/1] OvmfPkg PlatformBootManagerLib: Move TryRunningQemuKernel()

["Christoph Willing" <chris.willing@linux.com>]

On 12/8/21 11:36 pm, Gerd Hoffmann wrote:
>   Hi,
> 
>> While that all worked fine, probably with better performance (as Gerd
>> mentioned) it was still unsatisfying that I couldn't make the plain ide
>> work. It turns out that the ide interface can work without changes to
>> the initrd but invocation requires separate -drive and -device options,
>> somewhat like James' scsi version, namely:
>>
>> -device ahci,id=ahci \
>> -device ide-hd,drive=ide0,bus=ahci.0 \
>> -drive
>> if=none,id=ide0,file=disk.img,format=raw,cache=none,index=0,media=disk \
> 
> That is again something different, namely sata ...
> 
>> instead of my original shortcut version:
>>
>> -drive file=disk.img,format=raw,cache=none,index=0,media=disk \
> 
> ... while this is the older pata (with "-machine pc").
> 
> To add even more confusion: When using the more modern q35 chipset
> ("-machine q35") qemu will also use the more modern sata when you
> use the shortcut version to attach your disk.
> 
> So, in general it is a good idea to explicitly add the storage
> controller and devices you want as suggested by James.  Results
> in less surprises ;)
> 
Thanks Gerd,

That is the missing piece of the puzzle. I added "-machine q35" and
reverted to the shortcut -drive option and boot was successful with
UEFI. Although I will use the longer form in future, it was still
annoying that the shortcut version failed. The pata/sata explanation is
quite satisfying and I can finally let this issue go :)

chris

>> I'll probably stick with the better performing scsi version from now on
>> although it's still interesting that the shortcut version works without
>> UEFI but fails with UEFI.
> 
> I've seen guest driver failures due to missing firmware initialization
> before.  Specifically firmware not setting the busmaster bit in pci
> config space leading to guest driver's dma transfers failing (which of
> course is a guest driver bug).
> 
> I can imagine ovmf taking shortcuts for direct kernel boot could have
> that kind of effect too, and of course it could vary depending on the
> kind of storage controller used.
> 
> take care,
>   Gerd
> 
> 
> 
> 
>