Re: [edk2-devel] [PATCH 09/13] OvmfPkg: implement QEMU loader library for X86 with legacy fallback

["Laszlo Ersek" <lersek@redhat.com>]

On 03/03/20 11:08, Ard Biesheuvel wrote:
> On Tue, 3 Mar 2020 at 10:45, Laszlo Ersek <lersek@redhat.com> wrote:

>> (13) I'm worried that we are installing custom protocols on a handle
>> that was first created by LoadImage(), before we pass it to
>> UnloadImage(). I don't know if, per spec, LoadImage() / UnloadImage()
>> are allowed to associate such information with the specific image handle
>> that is *beyond* the protocol interfaces visible on the handle.
>>
> 
> I'm not sure I follow. Why would it not be allowed to install
> additional protocols on that handle? Note that it is rather common for
> drivers to install arbitrary protocols on the handle that they receive
> via the PE/COFF entry point.

Yes, that's correct; however what doesn't happen is that protocols
installed on the image handle *survive* unloading the image with
gBS->UnloadImage().

Put differently, if the image handle was created by LoadImage() -- by
virtue of LoadImage() installing the first protocol interface --, then I
*think* there might be a silent expectation that UnloadImage() will also
uninstall the last protocol interface, thereby releasing the image
handle itself.

>> Can we modify the logic somehow so that we don't have to silently call
>> QemuLoadLegacyImage() inside QemuStartKernelImage()? If not, we should
>> at least document that this is arguably a grey area per UEFI spec.
>>
> 
> That would require QemuStartImage() to take a EFI_HANDLE* rather than
> a EFI_HANDLE,

Yes, I agree.

> which is what I was trying to avoid here.

I perceive this as a lifecycle risk / grey area in the spec.

If we can make it disappear by having QemuStartImage() take an "IN OUT
EFI_HANDLE*", IMO that's a significant improvement, and hopefully not
much additional complexity. I think the underlying use case is intricate
enough for us to let it affect the abstract QemuStartKernelImage()
interface.

Thanks!
Laszlo