Re: [edk2] Xen OVMF early discussions

Subject: Re: [edk2] Xen OVMF early discussions

From: Bei Guan <gbtju85@gmail.com>

To: Andrei Warkentin <andreiw@motorola.com>

Date: 2011-05-04 17:54:08



2011/5/3 Andrei Warkentin <andreiw@motorola.com>
Hi Bei,

How are you doing with debugging the PCI issues with OVMF on XEN?
I have got the same debug message of OVMF on Xen as yours. But, I have not found the reason that OVMF stopped after finding all the PCI devices. I will continue to work on it. However, what do you think the possible causes?


On Fri, Apr 29, 2011 at 3:22 AM, Andrei Warkentin <andreiw@motorola.com> wrote:
>
> I just realized something... I probably shouldn't be leaving the
> shared_info page mapped at some location within hvmloader. That's
> bound to cause problems later in EFI :(.

The latest patch at
fixes this.
I have try the code, but maybe the parameter "hvmbios" in VM config doesn't work.Using the command "xenstore-ls | grep hvmloader/bios", I find the path "hvmloader/bios" in xenstore doesn'texist. So the following code in hvmloader.c doesn't work.

bios = xenstore_read("hvmloader/bios");
if ( !bios )
bios = "rombios";

Maybe my Xen source code isn't the latest one and the path "hvmloader/bios" has been add to xenstore in later version.

Thanks,
Bei Guan


>
> I'll also add an hvmbios type "initrd", which will let you load
> firmware from an image locally specified in your XM config. This whole
> recompiling hvmloader on every EFI change is going to drive you
> crazy...

This is unfortunately not (easily) doable. I totally forgot non-PV
domains don't get the start_info structure. Looks like you're going to
have
to rebuild hvmloader every time. But the good news is that you can
always automate that, and you can always specify the path to your
hvmloader using the "kernel = " parameter in your XM config.

A