[PATCH] migration: initialize RAM to zero

Using qemu_memalign only leaves the RAM zero by chance, because libc
will usually use mmap to satisfy our huge requests.  But memory will
not be zero when using MALLOC_PERTURB_ with a nonzero value.  In the
case of incoming migration, this breaks a recently-introduced
invariant (commit f1c7279, migration: do not sent zero pages in
bulk stage, 2013-03-26).

To fix this, use mmap ourselves to get a well-aligned, always zero
block for the RAM.  Mmap-ed memory is easy to "trim" at the sides.

This also removes the need to do something special on valgrind
(see commit c2a8238a, Support running QEMU on Valgrind, 2011-10-31).
[PATCH] ehci_free_packet: Discard finished packets when the queue is halted

With pipelining it is possible to encounter a finished packet when cleaning
the queue due to a halt. This happens when a non stall error happens while
talking to a real device. In this case the queue on the usb-host side will
continue processing packets, and we can have completed packets waiting in
the queue after an error condition packet causing a halt.

There are 2 reasons to discard the completed packets at this point, rather
then trying to writing them back to the guest:

1) The guest expect to be able to cancel and/or change packets after the
packet with the error without doing an unlink, so writing them back may
confuse the guest.

2) Since the queue does not advance when halted, the writing back of these
packets will fail anyways since p->qtdaddr != q->qtdaddr, so the
ehci_verify_qtd call in ehci_writeback_async_complete_packet will fail.

Note that 2) means that then only functional change this patch introduces
is the printing of a warning when this scenario happens.

Note that discarding these packets means that the guest driver and the device
will get out of sync! This is unfortunate, but should not be a problem since
with a non stall error (iow an io-error) the 2 are out of sync already anyways.
Still this patch adds a warning to signal this happening.

Note that sofar this has only been seen with a DVB-T receiver, which gives
of a MPEG-2 stream, which allows for recovering from lost packets, see:
https://bugzilla.redhat.com/show_bug.cgi?id=890320