[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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:


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 1c130000/disk 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.

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.

 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?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]