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@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 wanted people to state explicitly that this workaround in OVMF is
preferred to the libvirt patches. Now I can go forward and code it.
Would relative HD() paths still work?
Yes, they would. HALT will simply be considered "end of list".
Thank you!
Laszlo