X-Git-Url: http://pilppa.org/gitweb/gitweb.cgi?a=blobdiff_plain;f=include%2Flinux%2Flguest_launcher.h;h=e7217dc58f398fb7e6d11897faf2e7ac3d0dbfae;hb=0e88460da6ab7bb6a7ef83675412ed5b6315d741;hp=6416705794466bea3c1a4e2091ca03e79d980bfa;hpb=440fdb53b4ae58602711b5b8c3a139ace2404dbb;p=linux-2.6-omap-h63xx.git diff --git a/include/linux/lguest_launcher.h b/include/linux/lguest_launcher.h index 64167057944..e7217dc58f3 100644 --- a/include/linux/lguest_launcher.h +++ b/include/linux/lguest_launcher.h @@ -1,76 +1,7 @@ -#ifndef _ASM_LGUEST_USER -#define _ASM_LGUEST_USER +#ifndef _LINUX_LGUEST_LAUNCHER +#define _LINUX_LGUEST_LAUNCHER /* 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 +#include /*D:010 * Drivers @@ -79,49 +10,53 @@ struct lguest_net * 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. + * simple lguest bus and we use "virtio" drivers. These drivers need a set of + * routines from us which will actually do the virtual I/O, but they handle all + * the net/block/console stuff themselves. This means that if we want to add + * a new device, we simply need to write a new virtio driver and create support + * for it in the Launcher: this code won't need to change. + * + * Virtio devices are also used by kvm, so we can simply reuse their optimized + * device drivers. And one day when everyone uses virtio, my plan will be + * complete. Bwahahahah! * - * Devices are described by an array of LGUEST_MAX_DEVICES of these structs, - * placed by the Launcher just above the top of physical memory: + * Devices are described by a simplified ID, a status byte, and some "config" + * bytes which describe this device's configuration. This is 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 */ + /* The device type: console, network, disk etc. Type 0 terminates. */ + __u8 type; + /* The number of virtqueues (first in config array) */ + __u8 num_vq; + /* The number of bytes of feature bits. Multiply by 2: one for host + * features and one for Guest acknowledgements. */ + __u8 feature_len; + /* The number of bytes of the config array after virtqueues. */ + __u8 config_len; + /* A status byte, written by the Guest. */ + __u8 status; + __u8 config[0]; +}; - /* Each device exists somewhere in Guest physical memory, over some - * number of pages. */ - u16 num_pages; - u32 pfn; +/*D:135 This is how we expect the device configuration field for a virtqueue + * to be laid out in config space. */ +struct lguest_vqconfig { + /* The number of entries in the virtio_ring */ + __u16 num; + /* The interrupt we get when something happens. */ + __u16 irq; + /* The page number of the virtio ring for this device. */ + __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_INITIALIZE, /* + base, pfnlimit, pgdir, start */ + LHREQ_GETDMA, /* No longer used */ LHREQ_IRQ, /* + irq */ LHREQ_BREAK, /* + on/off flag (on blocks until someone does off) */ }; -#endif /* _ASM_LGUEST_USER */ +#endif /* _LINUX_LGUEST_LAUNCHER */