[libvirt] [PATCH 0/4] allow OVMF users to disable qemu's "-boot strict=on"

[Laszlo Ersek]

On 01/28/14 13:25, Paolo Bonzini wrote:
> Il 28/01/2014 13:16, Laszlo Ersek ha scritto:
>> On 01/28/14 12:54, Paolo Bonzini wrote:
>>> Il 22/01/2014 13:40, Laszlo Ersek ha scritto:
>>>> (b)
>>>>
>>>>   VenHw(C1E791A2-64CF-4B68-BDF1-1C31DABBDC84,0000131C00000000)/
>>>>   HD(1,GPT,2F972E52-F7E0-4504-9FE7-F60E66352266,0x800,0x32000)/
>>>>   \Image
>>>>
>>>> This is the file called "Image", in the root directory of the
>>>> filesystem
>>>> on the GPT hard disk partition identified by the HD() node, which
>>>> can be
>>>> reached behind the Vendor Hardware device that corresponds to the GUID
>>>> and the rest of the binary garbage visible in the VenHw node.
>>>>
>>>> In detail this happens to be a virtio-mmio block device whose register
>>>> range is mapped at 0x1C130000.
>>>
>>> This would probably be something like
>>>
>>> /virtio-mmio at 1c130000/disk at 0,0
>>>
>>> As a stopgap solution, you could keep the UEFI shell in the boot order
>>> if it is present in the UEFI boot order, even if the fw_cfg boot order
>>> includes HALT.
>>
>> Indeed, this is precisely what I've called "recognizing and ignoring
>> HALT", and "the least wrong solution", elsewhere in this discussion.
> 
> I'm not sure if this would be *ignoring* HALT.  For example the CD-ROMs
> would not be included in the list.

Right, in that sense it wouldn't mean "ignoring". HALT would be ignored
in the sense that the UEFI shell would still be tacked on.

IOW a user passing -boot strict=on on the qemu command line could not
*prevent* keeping the UEFI shell at the end of the list.

> Given your note that "you can rely on the GUUID in the FvFile() node
> being well-known", HALT could look for entries including
> FvFile(7C04A583-9E3E-4F1C-AD65-E05268D0B4D1), copy them if present, and
> then conclude the boot order.  Or in an alternative interpretation, HALT
> could copy all the MemoryMapped entries, and then conclude the boot
> order.  You're more competent than me in choosing the best interpretation.

This is precisely what I meant. The "survival policy" does just this.
(The set of entries to keep alive that it filters for is a bit
different, but the idea is the same.)

>>>  Would relative HD() paths still work?
>>
>> Yes, they would. HALT will simply be considered "end of list".
> 
> ... and earlier entries would be matched to the relative HD() path,
> because that relative path is "expanded" to the full path before your
> translation code runs.  Right?

Correct.

(Technically, I call the expansion routine as part of the translation
myself, but what matters is that matching is performed on the expanded
UEFI device paths.)

Thanks,
Laszlo