128 lines
5.0 KiB
C
128 lines
5.0 KiB
C
#ifndef _ASM_LGUEST_USER
|
|
#define _ASM_LGUEST_USER
|
|
/* Everything the "lguest" userspace program needs to know. */
|
|
/* They can register up to 32 arrays of lguest_dma. */
|
|
#define LGUEST_MAX_DMA 32
|
|
/* At most we can dma 16 lguest_dma in one op. */
|
|
#define LGUEST_MAX_DMA_SECTIONS 16
|
|
|
|
/* How many devices? Assume each one wants up to two dma arrays per device. */
|
|
#define LGUEST_MAX_DEVICES (LGUEST_MAX_DMA/2)
|
|
|
|
/*D:200
|
|
* Lguest I/O
|
|
*
|
|
* The lguest I/O mechanism is the only way Guests can talk to devices. There
|
|
* are two hypercalls involved: SEND_DMA for output and BIND_DMA for input. In
|
|
* each case, "struct lguest_dma" describes the buffer: this contains 16
|
|
* addr/len pairs, and if there are fewer buffer elements the len array is
|
|
* terminated with a 0.
|
|
*
|
|
* I/O is organized by keys: BIND_DMA attaches buffers to a particular key, and
|
|
* SEND_DMA transfers to buffers bound to particular key. By convention, keys
|
|
* correspond to a physical address within the device's page. This means that
|
|
* devices will never accidentally end up with the same keys, and allows the
|
|
* Host use The Futex Trick (as we'll see later in our journey).
|
|
*
|
|
* SEND_DMA simply indicates a key to send to, and the physical address of the
|
|
* "struct lguest_dma" to send. The Host will write the number of bytes
|
|
* transferred into the "struct lguest_dma"'s used_len member.
|
|
*
|
|
* BIND_DMA indicates a key to bind to, a pointer to an array of "struct
|
|
* lguest_dma"s ready for receiving, the size of that array, and an interrupt
|
|
* to trigger when data is received. The Host will only allow transfers into
|
|
* buffers with a used_len of zero: it then sets used_len to the number of
|
|
* bytes transferred and triggers the interrupt for the Guest to process the
|
|
* new input. */
|
|
struct lguest_dma
|
|
{
|
|
/* 0 if free to be used, filled by the Host. */
|
|
u32 used_len;
|
|
unsigned long addr[LGUEST_MAX_DMA_SECTIONS];
|
|
u16 len[LGUEST_MAX_DMA_SECTIONS];
|
|
};
|
|
/*:*/
|
|
|
|
/*D:460 This is the layout of a block device memory page. The Launcher sets up
|
|
* the num_sectors initially to tell the Guest the size of the disk. The Guest
|
|
* puts the type, sector and length of the request in the first three fields,
|
|
* then DMAs to the Host. The Host processes the request, sets up the result,
|
|
* then DMAs back to the Guest. */
|
|
struct lguest_block_page
|
|
{
|
|
/* 0 is a read, 1 is a write. */
|
|
int type;
|
|
u32 sector; /* Offset in device = sector * 512. */
|
|
u32 bytes; /* Length expected to be read/written in bytes */
|
|
/* 0 = pending, 1 = done, 2 = done, error */
|
|
int result;
|
|
u32 num_sectors; /* Disk length = num_sectors * 512 */
|
|
};
|
|
|
|
/*D:520 The network device is basically a memory page where all the Guests on
|
|
* the network publish their MAC (ethernet) addresses: it's an array of "struct
|
|
* lguest_net": */
|
|
struct lguest_net
|
|
{
|
|
/* Simply the mac address (with multicast bit meaning promisc). */
|
|
unsigned char mac[6];
|
|
};
|
|
/*:*/
|
|
|
|
/* Where the Host expects the Guest to SEND_DMA console output to. */
|
|
#define LGUEST_CONSOLE_DMA_KEY 0
|
|
|
|
/*D:010
|
|
* Drivers
|
|
*
|
|
* The Guest needs devices to do anything useful. Since we don't let it touch
|
|
* real devices (think of the damage it could do!) we provide virtual devices.
|
|
* We could emulate a PCI bus with various devices on it, but that is a fairly
|
|
* complex burden for the Host and suboptimal for the Guest, so we have our own
|
|
* "lguest" bus and simple drivers.
|
|
*
|
|
* Devices are described by an array of LGUEST_MAX_DEVICES of these structs,
|
|
* placed by the Launcher just above the top of physical memory:
|
|
*/
|
|
struct lguest_device_desc {
|
|
/* The device type: console, network, disk etc. */
|
|
u16 type;
|
|
#define LGUEST_DEVICE_T_CONSOLE 1
|
|
#define LGUEST_DEVICE_T_NET 2
|
|
#define LGUEST_DEVICE_T_BLOCK 3
|
|
|
|
/* The specific features of this device: these depends on device type
|
|
* except for LGUEST_DEVICE_F_RANDOMNESS. */
|
|
u16 features;
|
|
#define LGUEST_NET_F_NOCSUM 0x4000 /* Don't bother checksumming */
|
|
#define LGUEST_DEVICE_F_RANDOMNESS 0x8000 /* IRQ is fairly random */
|
|
|
|
/* This is how the Guest reports status of the device: the Host can set
|
|
* LGUEST_DEVICE_S_REMOVED to indicate removal, but the rest are only
|
|
* ever manipulated by the Guest, and only ever set. */
|
|
u16 status;
|
|
/* 256 and above are device specific. */
|
|
#define LGUEST_DEVICE_S_ACKNOWLEDGE 1 /* We have seen device. */
|
|
#define LGUEST_DEVICE_S_DRIVER 2 /* We have found a driver */
|
|
#define LGUEST_DEVICE_S_DRIVER_OK 4 /* Driver says OK! */
|
|
#define LGUEST_DEVICE_S_REMOVED 8 /* Device has gone away. */
|
|
#define LGUEST_DEVICE_S_REMOVED_ACK 16 /* Driver has been told. */
|
|
#define LGUEST_DEVICE_S_FAILED 128 /* Something actually failed */
|
|
|
|
/* Each device exists somewhere in Guest physical memory, over some
|
|
* number of pages. */
|
|
u16 num_pages;
|
|
u32 pfn;
|
|
};
|
|
/*:*/
|
|
|
|
/* Write command first word is a request. */
|
|
enum lguest_req
|
|
{
|
|
LHREQ_INITIALIZE, /* + pfnlimit, pgdir, start, pageoffset */
|
|
LHREQ_GETDMA, /* + addr (returns &lguest_dma, irq in ->used_len) */
|
|
LHREQ_IRQ, /* + irq */
|
|
LHREQ_BREAK, /* + on/off flag (on blocks until someone does off) */
|
|
};
|
|
#endif /* _ASM_LGUEST_USER */
|