From 98af2ac93fa6bd83e19f7cff1cc9513fa7c4d58d Mon Sep 17 00:00:00 2001 From: "Michael S. Tsirkin" Date: Mon, 4 Nov 2013 12:42:46 +0200 Subject: pc: disable acpi info for isapc and old pc machine MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Disable acpi build for isapc and no_kvmclock machine types (used by xen), since acpi build currently expects pci. Reported-by: Andreas Färber Signed-off-by: Michael S. Tsirkin Reviewed-by: Paolo Bonzini --- hw/i386/pc_piix.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c index 24a98cbee7..4fdb7b62c5 100644 --- a/hw/i386/pc_piix.c +++ b/hw/i386/pc_piix.c @@ -309,6 +309,7 @@ static void pc_init_pci_1_2(QEMUMachineInitArgs *args) static void pc_init_pci_no_kvmclock(QEMUMachineInitArgs *args) { has_pci_info = false; + has_acpi_build = false; disable_kvm_pv_eoi(); enable_compat_apic_id_mode(); pc_init1(args, 1, 0); @@ -317,6 +318,7 @@ static void pc_init_pci_no_kvmclock(QEMUMachineInitArgs *args) static void pc_init_isa(QEMUMachineInitArgs *args) { has_pci_info = false; + has_acpi_build = false; if (!args->cpu_model) { args->cpu_model = "486"; } -- cgit v1.2.3 From 818f86b88394b7b2b59d313e51043fe15a8004db Mon Sep 17 00:00:00 2001 From: "Michael S. Tsirkin" Date: Mon, 4 Nov 2013 08:06:08 +0200 Subject: exec: limit system memory size MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The page table logic in exec.c assumes that memory addresses are at most TARGET_PHYS_ADDR_SPACE_BITS. But pci addresses are full 64 bit so if we try to render them ignoring the extra bits, we get strange effects with sections overlapping each other. To fix, simply limit the system memory size to 1 << TARGET_PHYS_ADDR_SPACE_BITS, pci addresses will be rendered within that. Cc: qemu-stable@nongnu.org Reported-by: Andreas Färber Reviewed-by: Paolo Bonzini Signed-off-by: Michael S. Tsirkin --- exec.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/exec.c b/exec.c index b453713bdb..79610ce37a 100644 --- a/exec.c +++ b/exec.c @@ -1741,7 +1741,12 @@ void address_space_destroy_dispatch(AddressSpace *as) static void memory_map_init(void) { system_memory = g_malloc(sizeof(*system_memory)); - memory_region_init(system_memory, NULL, "system", INT64_MAX); + + assert(TARGET_PHYS_ADDR_SPACE_BITS <= 64); + + memory_region_init(system_memory, NULL, "system", + TARGET_PHYS_ADDR_SPACE_BITS == 64 ? + UINT64_MAX : (0x1ULL << TARGET_PHYS_ADDR_SPACE_BITS)); address_space_init(&address_space_memory, system_memory, "memory"); system_io = g_malloc(sizeof(*system_io)); -- cgit v1.2.3 From df39076850958b842ac9e414dc3ab2895f1877bf Mon Sep 17 00:00:00 2001 From: Paolo Bonzini Date: Mon, 4 Nov 2013 14:30:47 +0100 Subject: vl: allow "cont" from panicked state After reporting the GUEST_PANICKED monitor event, QEMU stops the VM. The reason for this is that events are edge-triggered, and can be lost if management dies at the wrong time. Stopping a panicked VM lets management know of a panic even if it has crashed; management can learn about the panic when it restarts and queries running QEMU processes. The downside is of course that the VM will be paused while management is not running, but that is acceptable if it only happens with explicit "-device pvpanic". Upon learning of a panic, management (if configured to do so) can pick a variety of behaviors: leave the VM paused, reset it, destroy it. In addition to all of these behaviors, it is possible to dump the VM core from the host. However, right now, the panicked state is irreversible, and can only be exited by resetting the machine. This means that any policy decision is entirely in the hands of the host. In particular there is no way to use the "reboot on panic" option together with pvpanic. This patch makes the panicked state reversible (and removes various workarounds that were there because of the state being irreversible). With this change, management has a wider set of possible policies: it can just log the crash and leave policy to the guest, it can leave the VM paused. In particular, the "log the crash and continue" is implemented simply by sending a "cont" as soon as management learns about the panic. Management could also implement the "irreversible paused state" itself. And again, all such actions can be coupled with dumping the VM core. Unfortunately we cannot change the behavior of 1.6.0. Thus, even if it uses "-device pvpanic", management should check for "cont" failures. If "cont" fails, management can then log that the VM remained paused and urge the administrator to update QEMU. Reviewed-by: Laszlo Ersek Reviewed-by: Luiz Capitulino Acked-by: Michael S. Tsirkin Signed-off-by: Paolo Bonzini Signed-off-by: Michael S. Tsirkin --- gdbstub.c | 3 --- vl.c | 6 ++---- 2 files changed, 2 insertions(+), 7 deletions(-) diff --git a/gdbstub.c b/gdbstub.c index 0e5a3f5bf9..e8ab0b2992 100644 --- a/gdbstub.c +++ b/gdbstub.c @@ -368,9 +368,6 @@ static inline void gdb_continue(GDBState *s) #ifdef CONFIG_USER_ONLY s->running_state = 1; #else - if (runstate_check(RUN_STATE_GUEST_PANICKED)) { - runstate_set(RUN_STATE_DEBUG); - } if (!runstate_needs_reset()) { vm_start(); } diff --git a/vl.c b/vl.c index efbff6512a..4ad15b808c 100644 --- a/vl.c +++ b/vl.c @@ -638,9 +638,8 @@ static const RunStateTransition runstate_transitions_def[] = { { RUN_STATE_WATCHDOG, RUN_STATE_RUNNING }, { RUN_STATE_WATCHDOG, RUN_STATE_FINISH_MIGRATE }, - { RUN_STATE_GUEST_PANICKED, RUN_STATE_PAUSED }, + { RUN_STATE_GUEST_PANICKED, RUN_STATE_RUNNING }, { RUN_STATE_GUEST_PANICKED, RUN_STATE_FINISH_MIGRATE }, - { RUN_STATE_GUEST_PANICKED, RUN_STATE_DEBUG }, { RUN_STATE_MAX, RUN_STATE_MAX }, }; @@ -686,8 +685,7 @@ int runstate_is_running(void) bool runstate_needs_reset(void) { return runstate_check(RUN_STATE_INTERNAL_ERROR) || - runstate_check(RUN_STATE_SHUTDOWN) || - runstate_check(RUN_STATE_GUEST_PANICKED); + runstate_check(RUN_STATE_SHUTDOWN); } StatusInfo *qmp_query_status(Error **errp) -- cgit v1.2.3