(dropping Attilio he has left Citrix).
On Wed, 2013-02-20 at 23:50 +0100, Laszlo Ersek wrote:
On 02/20/13 18:18, Ian Campbell wrote:
On Wed, 2013-02-20 at 17:55 +0100, Laszlo Ersek wrote:
However in OVMF the RESERVED_MEMBASE range is not parsed from this Xen-exported table, it is added manually in InitializeXen() [OvmfPkg/PlatformPei/Xen.c]:
// // Reserve away HVMLOADER reserved memory [0xFC000000,0xFD000000). // This needs to match HVMLOADER RESERVED_MEMBASE/RESERVED_MEMSIZE. // AddReservedMemoryBaseSizeHob (0xFC000000, 0x1000000);
ICK, it would be far preferable for OVMF to do what SeaBIOS does and actually "communicate" with hvmloader IMHO.
The table with "XenHVMSeaBIOS" signature is not created for OVMF I think; comparing the "bios_config" structure of function pointers between "seabios.c" and "ovmf.c" in tools/firmware/hvmloader/, the ovmf_config.bios_info_setup field is NULL.
Yes. I think this should be changed then to provide a proper way for hvmloader to communicate to OVMF. It would seem sensible to follow a similar mechanism to SeaBIOS, or if possible just reuse the exact same thing (perhaps with a different signature).
However there seem to be at least two "info" tables. Referring back, "seabios_info" at BIOS_INFO_PHYSICAL_ADDRESS (0x1000) is for SeaBIOS only, but "hvm_info" just below the end of conventional memory (at HVM_INFO_PADDR, 0x9F800) looks guest firmware independent.
hvm_info is used by the toolstack to pass parameters to hvmloader itself when it starts, it is not intended to pass options from hvmloader to the bios. It is not a stable ABI struct (since hvmloader and the toolstack are a matched pair it doesn't have to be) and we hope to eventually get rid of it. Possibly hvmloader should scrub it before calling the BIOS to discourage its use.
I guess the quoted range would be available from "hvm_info.reserved_mem_pgstart"? OvmfPkg/PlatformPei/Xen.c has a comment in XenConnect() saying
/* TBD: Locate hvm_info and reserve it away. */ mXenInfo.HvmInfo = NULL;
Oh dear.
Is the generic approach "see if you can find all what you need in hvm_info, ask for the rest in a dedicated table"? (Out of pure curiosity.)
As I hope is clear from the above, Nope ;-)
Ian.