Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

Signed-off-by: NNaphtali Sprei <nsprei@redhat.com>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

..since /proc usually isn't mounted on FreeBSD.
Signed-off-by: NJuergen Lock <nox@jelal.kn-bremen.de>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

Move target specific functions and RAM handling to arch_init.c.

Add a flag to QEMUOptions structure to indicate for which
architectures the option is allowed, check the flag
in run time and remove conditional code in option handling.

Now that no target dependencies remain, compile vl.c only once
for all targets.
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

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

These will be moved later.
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

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

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

Based on patch by Zachary Amsden.
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

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

Make win2k install hack unconditional as it is still restricted to
x86 only in vl.c.

Replace TARGET_PAGE_SIZE and 4096 with PAGE_SIZE.
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

This reverts commit 3290c4aa.

Conflicts:

	vl.c

This reverts commit d49f626e.

This reverts commit d7234f4d.

Conflicts:

	hw/xen_machine_pv.c

This should have never been committed.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This reverts commit 3b6304f7.

This was mistakenly committed.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

mkdir() only takes path argument on mingw32:

  CC    i386-softmmu/vl.o
/src/qemu/vl.c: In function 'qmp_add_default':
/src/qemu/vl.c:3763: error: too many arguments to function 'mkdir'
/src/qemu/vl.c:3769: error: too many arguments to function 'mkdir'
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

Basically, -qmp unix:%{home}/.qemu/qmp/%{uuid}.sock,server,nowait

%{uuid} will be -uuid if it's specified, otherwise, if libuuid is available,
we generate a uuid.  If it's not available, we don't create one.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Instead, we introduce a default_qmp flag.  We don't use it yet, but will in the
next patch.

This has a user-visible impact as specifying just -qmp will now also show a
monitor on the 'vc'.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

All of these users have global state so we really don't see a benefit from
exit_notifier.  However, using exit_notifier means that there's one less
justification for having global state in the first place.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Like atexit() but with state
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NJuan Quintela <quintela@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

It was always only used for reads
Signed-off-by: NJuan Quintela <quintela@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NJuan Quintela <quintela@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Just tell main_loop_wait whether to be blocking or nonblocking, so that
there is no need to call qemu_cpus_have_work from the timer subsystem.
Instead, tcg_cpu_exec can say "we want the main loop not to block because
we have stuff to do".
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Tweaking the rounding in qemu_next_deadline ensures that there's
no change whatsoever.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

A simple patch to place together all handling of -icount.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

By adding the possibility to turn on/off a clock, yet another
incestuous relationship between timers and CPUs can be disentangled.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Make the timer subsystem register its own callback instead.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Instead of testing specially next_cpu in host_alarm_handler, just do
that in qemu_notify_event.  The idea is, if we are not running (or
not yet running) target CPU code, prepare things so that the execution
loop is exited asap; just make that clear.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

qemu_notify_event in the non-iothread case is only stopping the current
CPU.  However, if the CPU is idle and the main loop is in the select
call then a call to qemu_event_increment is needed too (as done in
host_alarm_handler).  Since in general one doesn't know whether the CPU
is executing or not, it is a safe bet to always do qemu_event_increment.

Another way to see it: after this patch qemu_event_increment is the
"common part" of qemu_notify_event for both the CONFIG_IOTHREAD and
!CONFIG_IOTHREAD cases, which makes sense.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

The timer_alarm_pending variable is related to the alarm timer but not
placed in the struct.  Also, in qemu_mod_timer the wrong flag was being
tested: the timer is rearmed in the alarm timer "bottom half", so the
right flag to test there is the "pending" flag.

Finally, I hoisted the NULL checks from alarm_has_dynticks to
host_alarm_handler.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

The ALARM_FLAG_DYNTICKS can be testing simply by checking if there is
a rearm function.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

The TIME_ONESHOT and TIME_PERIODIC flags are mutually exclusive.
The code after the patch matches the flags used in win32_start_timer.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>