xen-devel
[Xen-devel] Re: [RFC, PATCH 3/24] i386 Vmi interface definition
To: |
Zachary Amsden <zach@xxxxxxxxxx> |
Subject: |
[Xen-devel] Re: [RFC, PATCH 3/24] i386 Vmi interface definition |
From: |
Chris Wright <chrisw@xxxxxxxxxxxx> |
Date: |
Mon, 13 Mar 2006 16:39:57 -0800 |
Cc: |
Andrew Morton <akpm@xxxxxxxx>, Joshua LeVasseur <jtl@xxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Pratap Subrahmanyam <pratap@xxxxxxxxxx>, Wim Coekaerts <wim.coekaerts@xxxxxxxxxx>, Jack Lo <jlo@xxxxxxxxxx>, Dan Hecht <dhecht@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxxxx>, Christopher Li <chrisl@xxxxxxxxxx>, Chris Wright <chrisw@xxxxxxxxxxxx>, Virtualization Mailing List <virtualization@xxxxxxxxxxxxxx>, Linus Torvalds <torvalds@xxxxxxxx>, Anne Holler <anne@xxxxxxxxxx>, Jyothy Reddy <jreddy@xxxxxxxxxx>, Kip Macy <kmacy@xxxxxxxxxxx>, Ky Srinivasan <ksrinivasan@xxxxxxxxxx>, Leendert van Doorn <leendert@xxxxxxxxxxxxxx>, Dan Arai <arai@xxxxxxxxxx> |
Delivery-date: |
Tue, 14 Mar 2006 10:05:42 +0000 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
In-reply-to: |
<200603131801.k2DI1EAe005650@xxxxxxxxxxxxxxxxxxx> |
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
List-post: |
<mailto:xen-devel@lists.xensource.com> |
List-subscribe: |
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
List-unsubscribe: |
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
References: |
<200603131801.k2DI1EAe005650@xxxxxxxxxxxxxxxxxxx> |
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
User-agent: |
Mutt/1.4.2.1i |
* Zachary Amsden (zach@xxxxxxxxxx) 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|