From: Chris Wright <chrisw@sous-sol.org>
To: Zachary Amsden <zach@vmware.com>
Cc: Linus Torvalds <torvalds@osdl.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Virtualization Mailing List <virtualization@lists.osdl.org>,
Xen-devel <xen-devel@lists.xensource.com>,
Andrew Morton <akpm@osdl.org>, Dan Hecht <dhecht@vmware.com>,
Dan Arai <arai@vmware.com>, Anne Holler <anne@vmware.com>,
Pratap Subrahmanyam <pratap@vmware.com>,
Christopher Li <chrisl@vmware.com>,
Joshua LeVasseur <jtl@ira.uka.de>,
Chris Wright <chrisw@sous-sol.org>,
Rik Van Riel <riel@redhat.com>, Jyothy Reddy <jreddy@vmware.com>,
Jack Lo <jlo@vmware.com>, Kip Macy <kmacy@fsmware.com>,
Jan Beulich <jbeulich@novell.com>,
Ky Srinivasan <ksrinivasan@novell.com>,
Wim Coekaerts <wim.coekaerts@oracle.com>,
Leendert van Doorn <leendert@watson.ibm.com>
Subject: Re: [RFC, PATCH 3/24] i386 Vmi interface definition
Date: Mon, 13 Mar 2006 16:39:57 -0800 [thread overview]
Message-ID: <20060314003956.GE12807@sorel.sous-sol.org> (raw)
In-Reply-To: <200603131801.k2DI1EAe005650@zach-dev.vmware.com>
* 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
next prev parent reply other threads:[~2006-03-14 0:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-13 18:01 Zachary Amsden
2006-03-14 0:39 ` Chris Wright [this message]
2006-03-14 3:16 ` Zachary Amsden
2006-03-14 15:25 ` Christoph Hellwig
2006-03-14 16:11 ` Zachary Amsden
2006-03-22 20:06 ` Andi Kleen
2006-03-13 18:41 Zachary Amsden
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060314003956.GE12807@sorel.sous-sol.org \
--to=chrisw@sous-sol.org \
--cc=akpm@osdl.org \
--cc=anne@vmware.com \
--cc=arai@vmware.com \
--cc=chrisl@vmware.com \
--cc=dhecht@vmware.com \
--cc=jbeulich@novell.com \
--cc=jlo@vmware.com \
--cc=jreddy@vmware.com \
--cc=jtl@ira.uka.de \
--cc=kmacy@fsmware.com \
--cc=ksrinivasan@novell.com \
--cc=leendert@watson.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pratap@vmware.com \
--cc=riel@redhat.com \
--cc=torvalds@osdl.org \
--cc=virtualization@lists.osdl.org \
--cc=wim.coekaerts@oracle.com \
--cc=xen-devel@lists.xensource.com \
--cc=zach@vmware.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®