This adds notifiers for phys memory changes: a set of callbacks that
vhost can register and update kernel accordingly.  Down the road, kvm
code can be switched to use these as well, instead of calling kvm code
directly from exec.c as is done now.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

In the very least, a change like this requires discussion on the list.

The naming convention is goofy and it causes a massive merge problem.  Something
like this _must_ be presented on the list first so people can provide input
and cope with it.

This reverts commit 99a0949b.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Some not so obvious bits, slirp and Xen were left alone for the time
being.
Signed-off-by: Nmalc <av1474@comtv.ru>

Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

kqemu introduces a number of restrictions on the i386 target.  The worst is that
it prevents large memory from working in the default build.

Furthermore, kqemu is fundamentally flawed in a number of ways.  It relies on
the TSC as a time source which will not be reliable on a multiple processor
system in userspace.  Since most modern processors are multicore, this severely
limits the utility of kqemu.

kvm is a viable alternative for people looking to accelerate qemu and has the
benefit of being supported by the upstream Linux kernel.  If someone can
implement work arounds to remove the restrictions introduced by kqemu, I'm
happy to avoid and/or revert this patch.

N.B. kqemu will still function in the 0.11 series but this patch removes it from
the 0.12 series.

Paul, please Ack or Nack this patch.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

The parameter is always zero except when registering the three internal
io regions (ROM, unassigned, notdirty).  Remove the parameter to reduce
the API's power, thus facilitating future change.
Signed-off-by: NAvi Kivity <avi@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

The only target dependency for most hardware is sizeof(target_phys_addr_t).
Build these files into a convenience library, and use that instead of
building for every target.

Remove and poison various target specific macros to avoid bogus target
dependencies creeping back in.

Big/Little endian is not handled because devices should not know or care
about this to start with.
Signed-off-by: NPaul Brook <paul@codesourcery.com>