On Thu, Sep 05, 2013 at 02:36:15PM +0200, Laszlo Ersek wrote:
> On 09/05/13 10:46, Michael Chang wrote:
> > On Thu, Sep 05, 2013 at 03:20:05AM +0200, Laszlo Ersek wrote:
> >> On 08/28/13 20:12, Laszlo Ersek wrote:
> >>> The prefix matching logic in Match()
> >>> [OvmfPkg/Library/PlatformBdsLib/QemuBootOrder.c] expects UEFI boot options
> >>> to specify full (absolute) device paths. However, partial (relative)
> >>> device paths starting with a HD() node are valid for booting. By not
> >>> recognizing them, QemuBootOrder.c misses (and deletes) valid boot options
> >>> that would otherwise match the user's preference.
> >>>
> >>> Just like BdsLibBootViaBootOption() expands such paths with the
> >>> BdsExpandPartitionPartialDevicePathToFull() function for booting, do the
> >>> same in QemuBootOrder.c for prefix matching.
> >>
> >> Ping.
> >>
> >> (I tested it with RHEL-6/Fedora-19/Win2k8r2sp1 installers.)
> > 
> > Hi Laszlo,
> > 
> > I tested it and I'd say it works, but ...
> > 
> > It seems to remove all enumerated devices from BootOrder which I'd
> > like to keep some of them. The resulting boot manager entries I have
> > is the one specified in qemu boot order .. 
> > 
> >   opensuse
> > 
> > Instead of
> > 
> >   opensuse
> >   EFI DVD/CDROM
> >   EFI FLOPPY
> >   EFI FLOPPY1
> >   EFI NETWORK
> >   EFI Internal Shell
> > 
> > Those entries seem derived from BdsLibEnumerateAllBootOption(). I'm
> > not sure whether this is intended behavoir or something I was missing.
> > I really need the EFI Shell frequently and believe that many people
> > do, but don't know how to specify it as qemu boot order .. :(
> 
> This is not directly caused by this patch, it just exposes to you how
> QemuBootOrder works in general. I assume you either used not to specify
> bootindices at all (in which case QemuBootOrder doesn't touch the
> BootOrder variable), or you had no matches at all between the
> "bootorder" fw_cfg file and the enumerated / configured BootXXXX
> options. In this latter case QemuBootOrder doesn't touch BootOrder either.

Sorry I should clearify this as you had asked me in another thread.

Yes, it's exactly the latter case, in the log there's only one
bootindex.

 -device virtio-blk-pci,scsi=off,bus=pci,0,addr=0x4,...,bootindex=1

And no device, which's either enumerated or configured, matches
against the fw_cfg bootorder before your fixing patch arrived.

> 
> Now, this patch may have changed that for you -- you could now have a
> match between the "bootorder" fw_cfg file, and the now-expanded HD(...)
> devpath that the OpenSUSE installer generated with efibootmgr.

Yes, I understood that (from your elaborative explanation in another
thread, thx) And that's why I think the patch works. Probably I should
raise the question in another thread regarding QemuBootOrder
discussion but not directly reply this thread ..

FWIW, as long as my testing result went postive, I'd like to ack this
patch with

  Tested-by: Michael Chang <mch...@suse.com>

> 
> So, yes, in this case QemuBootOrder kills off everything unmatched from
> the BootOrder variable. I had given some thought to this earlier, and it
> is a specification question. For now, "entry completely absent from the
> bootorder fw_cfg file" means "I don't want to boot from there --
> otherwise I'd put it on the list".

I agree with you, but the EFI Shell is a special case here, as it
cannot be specified, it's not "I don't want to boot from there" but
"I do want to boot from there but unable to put in on the list".

> 
> Unfortunately, stuff that is memory mapped from the flash device (like
> the EFI shell) is simply unexpressible via qemu bootindices -- and even
> if they were expressible, they still might not be representable as
> OpenFirmware device paths.
> 
> I'm uncertain how to clean this up, from the design/spec side -- I guess
> I could add code to tack the EFI shell boot option to the end of
> BootOrder, *if* QemuBootOrder rewrites that variable. But it sounds
> quite ad-hoc, plus will everyone agree that it should be the last one?

Is it viable to check the DevicePathType and mercy those not
expressible via qemu bootindices (like BDS_EFI_MESSAGE_MISC_BOOT) ?
As no way to tell user want those entries or not, use a more
conservative policy rather than aggresive ..

My 0.2 cents.

Thanks,
Michael


> 
> Thanks
> Laszlo

------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Reply via email to