Re: [Xen-devel] [edk2] [PATCH RFC 0/7] OvmfPkg: make OVMF fully working with Xen

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Sat, Nov 16, 2013 at 06:11:20PM -0800, Jordan Justen wrote:
> On Sat, Nov 16, 2013 at 5:31 PM, Wei Liu <liuw@xxxxxxxxx> wrote:
> > On Sat, Nov 16, 2013 at 3:31 AM, Jordan Justen <jljusten@xxxxxxxxx> wrote:
> >> When I try to boot this on qemu or kvm, it asserts because the video
> >> framebuffer address is NULL.
> >
> > That's expected because of the hack. ;-)
> 
> I see. But, I don't want to spend to much time considering it if is
> not going to work with QEMU & KVM. :)
> 
> I think a simpler approach would be to retain the enumeration and
> figure out a memory range that works with Xen.
> 
> >> On Fri, Nov 15, 2013 at 7:58 AM, Wei Liu <wei.liu2@xxxxxxxxxx> wrote:
> >>> Wei Liu (7):
> >>>   HACK: Use DeutPkg/PciRootBridgeNoEnumeration and
> >>>     PciBusNoEnumerationDxe
> >>
> >> These modules would need to move to PcAtChipsetPkg in the non-hack version.
> >>
> >> Actually, it would be even better if the generic version of these
> >> modules could be tweaked with a PCD to not do enumeration.
> 
> My first choice would be to add a PCD to MdeModulePkg/MdeModulePkg.dec
> that prevents enumeration in
> MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf, and continue to use this
> main driver. But, I don't know how easy those changes would be to
> make. It probably would also mean changing
> PcAtChipsetPkg/PciHostBridgeDxe/PciHostBridgeDxe.inf by looking at the
> same PCD. If some OVMF environments require enumeration, and some
> don't then this would allow us to choose what will happen at runtime.
> 

Second thought on this.

The main advantage to have a runtime Pcd over build time static
configuration is that we can use single binary for all OVMF use cases.
However currently Xen hvmloader statically embeds firmware blobs in
itself so it doesn't really matter if OVMF is configurable at runtime.
So this option will not benifit much unless we overhaul toolstack (libxl
and hvmloader) to support loading additional firmware blobs.

And per Andrew Fish: 

"The 
https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdeModulePkg/Bus/Pci/PciBusDxe/
driver assumes you are following the PI Spec model and a full PCI
enumeration is requires and a set of chipset/platform specific protocols
are provided to make the PCI enumerate code generic."

So I'm not quite sure whether to stop enumeration in MdeModulePkg is the
right choice.

> The only other option would be to move those modules to PcAtChipset.
> But, first we'd have to prove that QEMU & KVM are okay with using
> those drivers.
> 

I presume QEMU / KVM will still need enumeration, so they are not likely
to make use of those modules.

Corrections welcomed.

Wei.

> -Jordan
> 
> ------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/edk2-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel