lkml.org 
[lkml]   [2006]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC, PATCH 3/24] i386 Vmi interface definition
    * Zachary Amsden (zach@vmware.com) wrote:
    > Master definition of VMI interface, including calls, constants, and
    > interface version.

    > +/* VROM call table definitions */
    > +#define VROM_CALL_LEN 32
    > +
    > +typedef struct VROMCallEntry {
    > + char f[VROM_CALL_LEN];
    > +} VROMCallEntry;

    And the call entry is meant to be handled in whatever mechanism hypervisor
    prefers for its entry points (ABI constraints notwithstanding) as in,
    arbitrary software interrupt, or call gate, etc? I guess for transparent
    it has to, since those would be local calls. Quite similar to the
    hypercall entry point that Xen places on the hypercall_page, so easily
    compatible.

    > +typedef struct VROMHeader {
    > + VMI_UINT16 romSignature; // option ROM signature
    > + VMI_INT8 romLength; // ROM length in 512 byte chunks
    > + unsigned char romEntry[4]; // 16-bit code entry point
    > + VMI_UINT8 romPad0; // 4-byte align pad
    > + VMI_UINT32 vRomSignature; // VROM identification signature
    > + VMI_UINT8 APIVersionMinor; // Minor version of API
    > + VMI_UINT8 APIVersionMajor; // Major version of API
    > + VMI_UINT8 reserved0; // Reserved for expansion
    > + VMI_UINT8 reserved1; // Reserved for expansion
    > + VMI_UINT32 reserved2; // Reserved for expansion
    > + VMI_UINT32 reserved3; // Reserved for private use
    > + VMI_UINT16 pciHeaderOffset; // Offset to PCI OPROM header
    > + VMI_UINT16 pnpHeaderOffset; // Offset to PnP OPROM header
    > + VMI_UINT32 romPad3; // PnP reserverd / VMI reserved
    > + VROMCallEntry romCallReserved[3]; // Reserved call slots
    > +} VROMHeader;

    The document is slightly more descriptive. The above reserved slots
    are shown as:

    char reserved[32];
    char elfHeader[64];

    But that's only 3 (0-2). I think I'm missing some small bit of magic.

    > +typedef struct VROMCallTable {
    > + VROMCallEntry vromCall[128]; // @ 0x80: ROM calls 4-127
    > +} VROMCallTable;

    That comment eludes me. Are 0-3 special somehow (IOW, I thought it was
    just 0-2 as per above), and is it suggesting int 0x80?

    > +// Historical 3.X revisions
    > +//#define MIN_VMI_API_REV_MINOR 1 /* GetFlags_CLI is used */
    > +//#define MIN_VMI_API_REV_MINOR 2 /* STI_SYSEXIT is used */
    > +//#define MIN_VMI_API_REV_MINOR 3 /* IN/OUT are used */
    > +//#define MIN_VMI_API_REV_MINOR 4 /* Deferred calls used */
    > +//#define MIN_VMI_API_REV_MINOR 5 /* SetIOPLMask is used */
    > +
    > +// 4.X revisions
    > +//#define MIN_VMI_API_REV_MINOR 0 /* IN/OUT binary compat */

    Probably not the best format for keeping changelog entries. Although
    it's worth keeping the info somehwere in documentation perhaps.

    thanks,
    -chris
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-03-14 01:38    [W:0.032 / U:93.272 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site