Also removes a long-unused #define and an extraneous semicolon.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

We used to notify the Host every time we updated a device's status.  However,
it only really needs to know when we're resetting the device, or failed to
initialize it, or when we've finished our feature negotiation.

In particular, we used to wait for VIRTIO_CONFIG_S_DRIVER_OK in the
status byte before starting the device service threads.  But this
corresponds to the successful finish of device initialization, which
might (like virtio_blk's partition scanning) use the device.  So we
had a hack, if they used the device before we expected we started the
threads anyway.

Now we hook into the finalize_features hook in the Guest: at that
point we tell the Launcher that it can rely on the features we have
acked.  On the Launcher side, we look at the status at that point, and
start servicing the device.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Do not exit on some non-fatal errors:

- writev() fails in net_output(). The result is a lost packet or packets.
- writev() fails in console_output(). The result is partially lost console
output.
- readv() fails in net_input(). The result is a lost packet or packets.

Rather than bringing the guest down, this patch ignores e.g. an allocation
failure on the host side. Example:

lguest: page allocation failure. order:4, mode:0x4d0
Pid: 4045, comm: lguest Tainted: G        W   2.6.36 #1
Call Trace:
 [<c138d614>] ? printk+0x18/0x1c
 [<c106a4e2>] __alloc_pages_nodemask+0x4d2/0x570
 [<c1087954>] cache_alloc_refill+0x2a4/0x4d0
 [<c1305149>] ? __netif_receive_skb+0x189/0x270
 [<c1087c5a>] __kmalloc+0xda/0xf0
 [<c12fffa5>] __alloc_skb+0x55/0x100
 [<c1305519>] ? net_rx_action+0x79/0x100
 [<c12fafed>] sock_alloc_send_pskb+0x18d/0x280
 [<c11fda25>] ? _copy_from_user+0x35/0x130
 [<c13010b6>] ? memcpy_fromiovecend+0x56/0x80
 [<c12a74dc>] tun_chr_aio_write+0x1cc/0x500
 [<c108a125>] do_sync_readv_writev+0x95/0xd0
 [<c11fda25>] ? _copy_from_user+0x35/0x130
 [<c1089fa8>] ? rw_copy_check_uvector+0x58/0x100
 [<c108a7bc>] do_readv_writev+0x9c/0x1d0
 [<c12a7310>] ? tun_chr_aio_write+0x0/0x500
 [<c108a93a>] vfs_writev+0x4a/0x60
 [<c108aa21>] sys_writev+0x41/0x80
 [<c138f061>] syscall_call+0x7/0xb
Mem-Info:
DMA per-cpu:
CPU    0: hi:    0, btch:   1 usd:   0
Normal per-cpu:
CPU    0: hi:  186, btch:  31 usd:   0
HighMem per-cpu:
CPU    0: hi:  186, btch:  31 usd:   0
active_anon:134651 inactive_anon:50543 isolated_anon:0
 active_file:96881 inactive_file:132007 isolated_file:0
 unevictable:0 dirty:3 writeback:0 unstable:0
 free:91374 slab_reclaimable:6300 slab_unreclaimable:2802
 mapped:2281 shmem:9 pagetables:330 bounce:0
DMA free:3524kB min:64kB low:80kB high:96kB active_anon:0kB inactive_anon:8kB active_file:8760kB inactive_file:2760kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15868kB mlocked:0kB dirty:0kB writeback:0kB mapped:16kB shmem:0kB slab_reclaimable:88kB slab_unreclaimable:148kB kernel_stack:40kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 865 2016 2016
Normal free:150100kB min:3728kB low:4660kB high:5592kB active_anon:6224kB inactive_anon:15772kB active_file:324084kB inactive_file:325944kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:885944kB mlocked:0kB dirty:12kB writeback:0kB mapped:1520kB shmem:0kB slab_reclaimable:25112kB slab_unreclaimable:11060kB kernel_stack:1888kB pagetables:1320kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 9207 9207
HighMem free:211872kB min:512kB low:1752kB high:2992kB active_anon:532380kB inactive_anon:186392kB active_file:54680kB inactive_file:199324kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:1178504kB mlocked:0kB dirty:0kB writeback:0kB mapped:7588kB shmem:36kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
DMA: 3*4kB 65*8kB 35*16kB 18*32kB 11*64kB 9*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 3524kB
Normal: 35981*4kB 344*8kB 158*16kB 28*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 150100kB
HighMem: 5732*4kB 5462*8kB 2826*16kB 1598*32kB 84*64kB 10*128kB 7*256kB 1*512kB 1*1024kB 1*2048kB 9*4096kB = 211872kB
231237 total pagecache pages
2340 pages in swap cache
Swap cache stats: add 160060, delete 157720, find 189017/194106
Free swap  = 4179840kB
Total swap = 4194300kB
524271 pages RAM
296946 pages HighMem
5668 pages reserved
867664 pages shared
82155 pages non-shared
Signed-off-by: NSakari Ailus <sakari.ailus@iki.fi>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

No virtio device does this any more, so no need to clutter lguest with it.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

ed16648e "Move kvm, uml, and lguest
subdirectories" broke the lguest example launcher.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

The ucast transport is similar to the mcast transport (and, in fact,
shares most of its code), only it uses UDP unicast to move packets.

Obviously this is only useful for point-to-point connections between
virtual ethernet devices.
Signed-off-by: NNolan Leake <nolan@cumulusnetworks.com>
Signed-off-by: NRichard Weinberger <richard@nod.at>
Cc: David Miller <davem@davemloft.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

- Documentation/kvm/ to Documentation/virtual/kvm
- Documentation/uml/ to Documentation/virtual/uml
- Documentation/lguest/ to Documentation/virtual/lguest
throughout the kernel source tree.
Signed-off-by: NRob Landley <rob@landley.net>
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>

Remove uml from the top level 00-INDEX file.
Signed-off-by: NRob Landley <rlandley@parallels.com>
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>

  cd Documentation
  mkdir virtual
  git mv kvm uml lguest virtual
Signed-off-by: NRob Landley <rlandley@parallels.com>
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>