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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list