Re: Passing Xen memory map and resource map to OVMF

[Ian Campbell <Ian.Campbell@citrix.com>]

On Tue, 2013-11-12 at 18:33 +0000, Wei Liu wrote:
> Hi all
> 
> Currently OVMF determines memory size by consulting CMOS, then it makes
> up memory map of its own.
> 
> Consulting memory size by reading CMOS limits the RAM size to 1TB as
> there's only 3 bytes from 0x5b-0x5d in CMOS, where the upper memory size
> is stored.
> 
> And from Xen's point of view, OVMF should use the memory mapped passed
> by hypervisor (from hvmloader) instead of making up its own.
> 
> To solve the above two problems all in one go, I plan to pass necessary
> information (io resource, mmio resource) to OVMF from Xen.  I will
> construct the table / structure in hvmloader then hook up platform pei
> code when OVMF is running on Xen.

FWIW when hvmloader launches SeaBIOS it passes this stuff in a struct at
a known location:

struct xen_seabios_info {
    char signature[14]; /* XenHVMSeaBIOS\0 */
    u8 length;     /* Length of this struct */
    u8 checksum;   /* Set such that the sum over bytes 0..length == 0 */
    /*
     * Physical address of an array of tables_nr elements.
     *
     * Each element is a 32 bit value contianing the physical address
     * of a BIOS table.
     */
    u32 tables;
    u32 tables_nr;
    /*
     * Physical address of the e820 table, contains e820_nr entries.
     */
    u32 e820;
    u32 e820_nr;
} PACKED;

The e820 is not self identifiable so it gets its own field. The "tables"
are the ACPI RSDP, the mptables, the smbios tables and the PIR tables.
SeaBIOS iterates over these and identifies them by their unique
signature, ignoring any which it doesn't understand for forwards
compatibility.

I don't know which if any of those tables are suitable to be passed into
OVMF, I guess some of them are legacy BIOS things...

But the general shape of the scheme is probably worth following...

Ian.