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

[Jordan Justen <jljusten@xxxxxxxxx>]

On Mon, Nov 18, 2013 at 2:26 AM, Wei Liu <wei.liu2@xxxxxxxxxx> wrote:
> On Sat, Nov 16, 2013 at 06:11:20PM -0800, Jordan Justen wrote:
>> 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.

This is a good argument. I definitely wanted to keep a single OVMF
build working for Xen & QEMU if possible, but it seems like there is
little value if it is not easy to load a different version in Xen.

It seems that Xen supporting flash emulation will raise a few
uncomfortable questions. (Well, that is not exclusive to Xen. :)

> 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.

Obviously the PCD should default to enumeration, but I think there is
still value in not duplicating the module assuming there is a lot of
code overlap. It would be nice to continue to use the same module that
most platform use.

-Jordan

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