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-13 17:20:54



2011/5/13 Andrei Warkentin <andreiw@motorola.com>
Hey,

On Thu, May 12, 2011 at 9:55 AM, Bei Guan <gbtju85@gmail.com> wrote:
> Hi Andrei,
>
> 2011/5/12 Andrei Warkentin <andreiw@motorola.com>
>>
>> On Wed, May 11, 2011 at 1:30 PM, Jordan Justen <jljusten@gmail.com> wrote:
>> > On Wed, May 11, 2011 at 00:15, Andrei Warkentin <andreiw@motorola.com>
>> > wrote:
>> >> Looks like it was trying to read the EDID
>> >> (http://en.wikipedia.org/wiki/Extended_display_identification_data)
>> >> while initializing the video.
>> >
>> > The latest OVMF is using OvmfPkg/QemuVideoDxe and it doesn't read EDID.
>> >
>>
>> I quickly tested with latest OVMF (+patch) and it still hangs. Though
>> not in the video driver. In fact, it would appear that the video
>> didn't get detected :(.
>
> From our boot trace message, OVMF on Xen uses the
> OptionRomPkg/CirrusLogic5430Dxe driver, notOvmfPkg/QemuVideoDxe as OVMF on
> QEMU. Doesn't the CirrusLogic5430Dxe driver support OVMF on Xen? And maybe
> we need to change something of this driver.

As Jordan mentioned, this is a recent update. Do "svn update" to get
the latest. You should probably instrument the
QemuVideoDxe driver and see what it is (and isn't) doing.

I have updated it to revision 11547 in order to apply your patch "ovmf-edk2.patch" several days ago. However, it uses theQemuVideoDxe driver when OVMF runs on QEMU, while it uses theCirrusLogic5430Dxe driver when loaded by Xen hvmloader.
Andrei, what't your Xen-qemu version? Do you uses the upstream (0.14.50). Because the upstream Xen-qemu can not work when OVMF is loaded by hvmloader, so now I use the old version Xen-qemu (0.10.2). Is it the reason that OVMF on Xen uses theCirrusLogic5430Dxe driver?


Thanks,
Bei Guan

>
>>
>> gdb) bt
>> #0 0x01ecc8da in CoreCheckEvent (UserEvent=0xfc5f10) at
>> /home/fjnh84/src/edk2/MdeModulePkg/Core/Dxe/Event/Event.c:543
>> #1 0x01ecc96b in CoreWaitForEvent (NumberOfEvents=1,
>> UserEvents=0x1ec0ea0, UserIndex=0x1ec0e9c)
>> at /home/fjnh84/src/edk2/MdeModulePkg/Core/Dxe/Event/Event.c:621
>> #2 0x01dc7317 in PlatformBdsPolicyBehavior
>> (DriverOptionList=0x1ec0ef8, BootOptionList=0x1ec0ef0,
>> ProcessCapsules=0x1daf7db <BdsProcessCapsules>,
>> BaseMemoryTest=0x1daf3e8 <BdsMemoryTest>)
>> at
>> /home/fjnh84/src/edk2/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c:1190
>> #3 0x01dae9b1 in BdsEntry (This=0x1dd2bb0)
>> at
>> /home/fjnh84/src/edk2/IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c:357
>> #4 0x01ec1e68 in DxeMain (HobStart=0x1cb9010) at
>> /home/fjnh84/src/edk2/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c:458
>> #5 0x01ec1254 in _ModuleEntryPoint (HobStart=0xd20000)
>> at
>> /home/fjnh84/src/edk2/MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.c:54
>> #6 0xc2c2c2c2 in ?? ()
>> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
>>
>> The backtrace basically shows it sitting waiting for user input...
>>
>> I'm getting tired of manually doing add-symbol-files, so I started
>> working on a gdb script to do it automatically. Progress is a bit
>> slower than I wanted it to be because of the awkwardness of the GDB
>> Python bindings (esp in older versions of gdb)
>>
>> https://github.com/andreiw/andreiw-wip/raw/master/uefi/gdb_uefi.py
>>
>> It's just simpler to link in the
>> ArmPkg/Library/DebugPeCoffExtraActionLib instead of the Null one, and
>> grep for add-symbol-file strings. With the caveat that there is a bug
>> in that Library that doesn't account for the case where there is no
>> debugging data (there is one driver like that... unsure what it is...
>> maybe the binary-only Shell or Fat32? I didn't dig deep enough).
>
> Do you mean the following driver in the boot trace message. I get all the
> other driver names except this one all the time. I hopeit will not affect
> our project.
> Loading driver 961578FE-B6B7-44C3-AF35-6BC705CD2B1F
> InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 3EB07DA8
> Loading driver at 0x0003E4E4000 EntryPoint=0x0003E4E4427
>
>

I had a different base, but I'm guessing yes. No, shouldn't...

>>
>> Hmmm.
>> In fact the stuff in ArmPkg/Library/DebugPeCoffExtraActionLib is
>> generic enough that it should be moved out of ArmPkg... Thoughts?
>>
>>
>> https://github.com/andreiw/andreiw-wip/raw/master/uefi/0001-ArmPkg-DebugPeCoffExtraActionLib.patch
>>
>> Bei: This should make your life easier - apply patch and change DSC to
>> use ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.inf
>> instead of DebugAgentLibNull.inf. Now you can dump the output of xm
>> create domname -c into a file, grep out the add-symbol-file lines
>> into a separate file, then make gdb read it by running "source
>> filename" at gdb prompt.
>
> I think it should replace BasePeCoffExtraActionLibNull.inf, not
> DebugAgentLibNull.inf. And when I replace it, I can do the add-symbol-file
> as you say. It's really very convenient and it save me much time. Thanks a
> lot. :)

Sorry, typo, pasted the wrong thing.

A