review.tizen.org Git - sdk/emulator/qemu.git/log

projects / sdk / emulator / qemu.git / log

Gerd Hoffmann [Wed, 16 Sep 2009 20:25:27 +0000 (22:25 +0200)]

allow qdev busses allocations be inplace

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

commit | commitdiff | tree

Glauber Costa [Thu, 17 Sep 2009 18:10:06 +0000 (20:10 +0200)]

temporary fix for on_vcpu

Recent changes made on_vcpu hit the abort() path, even with the IO thread
disabled. This is because cpu_single_env is no longer set when we call this
function. Although the correct fix is a little bit more complicated that that,
the recent thread in which I proposed qemu_queue_work (which fixes that, btw),
is likely to go on a quite different direction.

So for the benefit of those using guest debugging, I'm proposing this simple
fix in the interim.

Signed-off-by: Glauber Costa <glommer@redhat.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

commit | commitdiff | tree

Jan Kiszka [Thu, 17 Sep 2009 18:05:58 +0000 (20:05 +0200)]

kvm: Fix guest single-stepping

Hopefully the last regression of 4c0960c0: KVM_SET_GUEST_DEBUG requires
properly synchronized guest registers (on x86: eflags) on entry.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

commit | commitdiff | tree

Jan Kiszka [Thu, 17 Sep 2009 16:14:13 +0000 (18:14 +0200)]

gdbstub: x86: Switch 64/32 bit registers dynamically

Commit 56aebc891674cd2d07b3f64183415697be200084 changed gdbstub in way
that debugging 32 or 16-bit guest code is no longer possible with qemu
for x86_64 guest CPUs. Since that commit, qemu only provides registers
sets for 64-bit, forcing current and foreseeable gdb to also switch its
architecture to 64-bit. And this breaks if the inferior is 32 or 16 bit.

No question, this is a gdb issue. But, as it was confirmed in several
discusssions with gdb people, it is a non-trivial thing to fix. So until
qemu finds a gdb version attach with a rework x86 support, we have to
work around it by switching the register layout as the guest switches
its execution mode between 16/32 and 64 bit.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

commit | commitdiff | tree

Jan Kiszka [Tue, 15 Sep 2009 11:36:04 +0000 (13:36 +0200)]

Enable host-clock-based RTC

Switch RTC emulations to the new host_clock instead of vm_clock by
default. This has the advantage that the emulated RTC will follow
automatically the host time while it might be tuned via NTP. vm_clock
can still be selected by passing '-rtc clock=vm' on the command line.

Note that some RTC emulations (at least M48T59) already use the host
time unconditionally while others (namely MC146818) do not. This patch
introduces the required infrastructure for selecting the base clock but
only converts MC146818 for now.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

commit | commitdiff | tree

Jan Kiszka [Tue, 15 Sep 2009 11:36:04 +0000 (13:36 +0200)]

Refactor RTC command line switches

Deprecate -localtime, -setdate and -rtc-td-hack in favor of a new
unified command line switch:

-rtc [base=utc|localtime|date][,driftfix=none|slew]

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

commit | commitdiff | tree

Jan Kiszka [Tue, 15 Sep 2009 11:36:04 +0000 (13:36 +0200)]

Introduce QEMU_CLOCK_HOST

Despite its name QEMU_CLOCK_REALTIME is (normally) not using
CLOCK_REALTIME / the host system time as base. In order to allow also
non-trivial RTC emulations (MC146818) to follow the host time instead of
the virtual guest time, introduce the new clock type QEMU_CLOCK_HOST. It
is unconditionally based on CLOCK_REALTIME, thus will follow system time
changes of the host.

The only limitation of its current implementation is that pending
host_clock timers may not fire early if the host time is pushed forward
beyond their expiry. So far no urgent need to overcome this limitation
was identified, so it's left as simple as it is (expiry on next alarm
timer tick).

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

commit | commitdiff | tree

Jan Kiszka [Tue, 15 Sep 2009 11:36:04 +0000 (13:36 +0200)]

win32: Drop dead dyntick timer code

nearest_delta_us is calculated but not used. Drop it.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

commit | commitdiff | tree

Jan Kiszka [Tue, 15 Sep 2009 11:36:04 +0000 (13:36 +0200)]

Rename QEMU_TIMER_* to QEMU_CLOCK_*

These constants select clocks, not timers. And init_timers initializes
clocks.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

commit | commitdiff | tree

Luiz Capitulino [Thu, 24 Sep 2009 14:16:01 +0000 (11:16 -0300)]

Fix exit on 'pci_add' Monitor command

If the user issues one of the following commands to the Monitor:

pci_add pci_addr=auto nic model=None
pci_add pci_addr=auto nic model=?

QEMU will exit, because the function used to perform sanity
checks (qemu_check_nic_model_list()) exits on error.

This function is used by the startup code, where it makes
sense to exit on error, but in the Monitor it doesn't.

Changing qemu_check_nic_model_list() to not exit on error
is not possible though, as it's used by the board init
code (the PC one), where all board specific code must have
void return.

The way I've chosen to fix this was to introduce a new function
called pci_nic_supported(), which checks if the NIC is supported
and returns true or false accordingly.

The new function is used only by the Monitor, it performs the
necessary check and returns an error in case the NIC is not
supported, thus qemu_check_nic_model_list()'s exit is never trigged.

The following should be observed:

1. Only the specified NIC is checked, the default one is assumed
to be supported

2. The NIC query command (model=?) won't work with pci_add, the
right way to do this with the Monitor is to add a new command

Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

commit | commitdiff | tree

Glauber Costa [Thu, 17 Sep 2009 20:53:39 +0000 (16:53 -0400)]

Correctly free nd structure

When we "free" a NICInfo structure, we can leak pointers, since we don't do
much more than setting used = 0.

We free() the model parameter, but we don't set it to NULL. This means that
a new user of this structure will see garbage in there. It was not noticed
before because reusing a NICInfo is not that common, but it can be, for
users of device pci hotplug.

A user hit it, described at https://bugzilla.redhat.com/show_bug.cgi?id=524022

This patch memset's the whole structure, guaranteeing that anyone reusing it
will see a fresh NICinfo. Also, we free some other strings that are currently
leaking.

This codebase is quite old, so this patch should feed all stable trees.

Signed-off-by: Glauber Costa <glommer@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

commit | commitdiff | tree

Glauber Costa [Mon, 28 Sep 2009 18:27:44 +0000 (15:27 -0300)]

do proper cpu_self check

Currently, our check for qemu_cpu_self only checks if there is a cpu
currently in execution (represented by cpu_single_env being set). While
this might be okay for tcg, it is certainly not okay for kvm, since multiple
cpus might be executing.

Instead, I propose we use pthread primitives to test if the caller thread is
the same as env->thread.

For tcg, it will have the same semantics as before, since all CPUStates will
point to the same thread, and we'll only have one in execution at a time.

Signed-off-by: Glauber Costa <glommer@mothafucka.localdomain>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

commit | commitdiff | tree

Juan Quintela [Tue, 29 Sep 2009 23:10:56 +0000 (01:10 +0200)]

bdf: Remove last users of FALSE/TRUE

This brings bfd_boolean to the wonderful world of <stdbool.h>, it is needed
because it defines bdf_boolean as an enum with values true and false,
and some architectures use TRUE, FALSE and give problems when you try to use
<stdbool.h>

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

commit | commitdiff | tree

Juan Quintela [Tue, 29 Sep 2009 23:10:55 +0000 (01:10 +0200)]

Add -Wold-style-* flags

This time, I add them in configure only if target compiler supports it

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

commit | commitdiff | tree

Juan Quintela [Tue, 29 Sep 2009 23:10:54 +0000 (01:10 +0200)]

slirp: It needs to use QEMU_CFLAGS not CFLAGS

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

commit | commitdiff | tree