[PATCH] kvm: libkvm: add kvm_has_sync_mmu
From: Anthony Liguori [EMAIL PROTECTED]
This patch adds a kvm_has_sync_mmu routine to libkvm. This allows
userspace to query the existence of mmu notifiers which is important for
ballooning since madvise() is not safe from userspace without it.
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
Signed-off-by: Marcelo Tosatti [EMAIL PROTECTED]
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
diff --git a/libkvm/libkvm.c b/libkvm/libkvm.c
index ad7f5a5..fb0aa43 100644
--- a/libkvm/libkvm.c
+++ b/libkvm/libkvm.c
@@ -1053,6 +1053,15 @@ int kvm_pit_in_kernel(kvm_context_t kvm)
return kvm-pit_in_kernel;
}
+int kvm_has_sync_mmu(kvm_context_t kvm)
+{
+int r = 0;
+#ifdef KVM_CAP_SYNC_MMU
+r = ioctl(kvm-fd, KVM_CHECK_EXTENSION, KVM_CAP_SYNC_MMU);
+#endif
+return r;
+}
+
int kvm_init_coalesced_mmio(kvm_context_t kvm)
{
int r = 0;
diff --git a/libkvm/libkvm.h b/libkvm/libkvm.h
index 9f06fcc..346eedf 100644
--- a/libkvm/libkvm.h
+++ b/libkvm/libkvm.h
@@ -528,6 +528,8 @@ int kvm_dirty_pages_log_reset(kvm_context_t kvm);
*/
int kvm_irqchip_in_kernel(kvm_context_t kvm);
+int kvm_has_sync_mmu(kvm_context_t kvm);
+
#ifdef KVM_CAP_IRQCHIP
/*!
* \brief Dump in kernel IRQCHIP contents
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] kvm: libkvm: fix indentation
From: Amit Shah [EMAIL PROTECTED]
Fix indentation style in libkvm.c to match the rest of the file.
Signed-off-by: Amit Shah [EMAIL PROTECTED]
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
diff --git a/libkvm/libkvm.c b/libkvm/libkvm.c
index 5edfad7..ad7f5a5 100644
--- a/libkvm/libkvm.c
+++ b/libkvm/libkvm.c
@@ -1045,7 +1045,7 @@ int kvm_set_signal_mask(kvm_context_t kvm, int vcpu,
const sigset_t *sigset)
int kvm_irqchip_in_kernel(kvm_context_t kvm)
{
-return kvm-irqchip_in_kernel;
+ return kvm-irqchip_in_kernel;
}
int kvm_pit_in_kernel(kvm_context_t kvm)
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] kvm: qemu: enable virtio for kvm/ia64
From: Xiantao Zhang [EMAIL PROTECTED]
Enable virtio-blk for kvm/ia64.
Signed-off-by: Xiantao Zhang [EMAIL PROTECTED]
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
diff --git a/qemu/hw/ipf.c b/qemu/hw/ipf.c
index b11e328..60ff634 100644
--- a/qemu/hw/ipf.c
+++ b/qemu/hw/ipf.c
@@ -652,6 +652,17 @@ static void ipf_init1(ram_addr_t ram_size, int
vga_ram_size,
}
}
}
+/* Add virtio block devices */
+if (pci_enabled) {
+ int index;
+ int unit_id = 0;
+
+ while ((index = drive_get_index(IF_VIRTIO, 0, unit_id)) != -1) {
+ virtio_blk_init(pci_bus, 0x1AF4, 0x1001,
+ drives_table[index].bdrv);
+ unit_id++;
+ }
+}
}
static void ipf_init_pci(ram_addr_t ram_size, int vga_ram_size,
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] KVM: fix userspace ABI breakage
From: Adrian Bunk [EMAIL PROTECTED]
The following part of commit 9ef621d3be56e1188300476a8102ff54f7b6793f
(KVM: Support mixed endian machines) changed on the size of a struct
that is exported to userspace:
include/linux/kvm.h:
@@ -318,14 +318,14 @@ struct kvm_trace_rec {
__u32 vcpu_id;
union {
struct {
- __u32 cycle_lo, cycle_hi;
+ __u64 cycle_u64;
__u32 extra_u32[KVM_TRC_EXTRA_MAX];
} cycle;
struct {
__u32 extra_u32[KVM_TRC_EXTRA_MAX];
} nocycle;
} u;
-};
+} __attribute__((packed));
Packing a struct was the correct idea, but it packed the wrong struct.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index d9ef7d3..ef4bc6f 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -324,12 +324,12 @@ struct kvm_trace_rec {
struct {
__u64 timestamp;
__u32 extra_u32[KVM_TRC_EXTRA_MAX];
- } timestamp;
+ } __attribute__((packed)) timestamp;
struct {
__u32 extra_u32[KVM_TRC_EXTRA_MAX];
} notimestamp;
} u;
-} __attribute__((packed));
+};
#define TRACE_REC_EVENT_ID(val) \
(0x0fff (val))
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] kvm: testsuite: avoid -m64 -m32 in gcc options
From: Avi Kivity [EMAIL PROTECTED] appears to confuse some versions of gcc. Signed-off-by: Avi Kivity [EMAIL PROTECTED] diff --git a/user/config-i386.mak b/user/config-i386.mak index 0908517..09175d5 100644 --- a/user/config-i386.mak +++ b/user/config-i386.mak @@ -2,7 +2,6 @@ TEST_DIR=test/x86 cstart.o = $(TEST_DIR)/cstart.o bits = 32 ldarch = elf32-i386 -CFLAGS += -m32 CFLAGS += -D__i386__ CFLAGS += -I $(KERNELDIR)/include diff --git a/user/config-x86-common.mak b/user/config-x86-common.mak index cfbc522..b0337c9 100644 --- a/user/config-x86-common.mak +++ b/user/config-x86-common.mak @@ -12,6 +12,7 @@ cflatobjs += \ $(libcflat): LDFLAGS += -nostdlib $(libcflat): CFLAGS += -ffreestanding -I test/lib +CFLAGS += -m$(bits) FLATLIBS = test/lib/libcflat.a $(libgcc) %.flat: %.o $(FLATLIBS) @@ -53,7 +54,7 @@ $(TEST_DIR)/tsc.flat: $(cstart.o) $(TEST_DIR)/tsc.o $(TEST_DIR)/realmode.flat: $(TEST_DIR)/realmode.o $(CC) -m32 -nostdlib -o $@ -Wl,-T,$(TEST_DIR)/realmode.lds $^ -$(TEST_DIR)/realmode.o: CFLAGS += -m32 +$(TEST_DIR)/realmode.o: bits = 32 arch_clean: $(RM) $(TEST_DIR)/bootstrap $(TEST_DIR)/*.o $(TEST_DIR)/*.flat \ diff --git a/user/config-x86_64.mak b/user/config-x86_64.mak index 9f37e6f..237f3c7 100644 --- a/user/config-x86_64.mak +++ b/user/config-x86_64.mak @@ -2,7 +2,6 @@ TEST_DIR=test/x86 cstart.o = $(TEST_DIR)/cstart64.o bits = 64 ldarch = elf64-x86-64 -CFLAGS += -m64 CFLAGS += -D__x86_64__ CFLAGS += -I $(KERNELDIR)/include -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]KVM: kvm/ia64: select ANON_INODES PREEMPT_NOTIFIERS, once
Zhang, Xiantao wrote: From 2c14c54eed790553fddbcb3970f0967a4aa79dca Mon Sep 17 00:00:00 2001 From: Xiantao Zhang [EMAIL PROTECTED] Date: Sat, 23 Aug 2008 10:21:06 +0800 Subject: [PATCH] KVM: kvm/ia64: select ANON_INODES PREEMPT_NOTIFIERS, once virtualization configured. Once virtulization configured, make PREEMPT_NOTIFIERS, ANON_INODES selected by default. What is the motivation for this? Don't things work as is? Signed-off-by: Xiantao Zhang [EMAIL PROTECTED] --- arch/ia64/kvm/Kconfig |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/ia64/kvm/Kconfig b/arch/ia64/kvm/Kconfig index 7914e48..07f6b69 100644 --- a/arch/ia64/kvm/Kconfig +++ b/arch/ia64/kvm/Kconfig @@ -7,6 +7,8 @@ config HAVE_KVM menuconfig VIRTUALIZATION bool Virtualization depends on HAVE_KVM || IA64 + select PREEMPT_NOTIFIERS + select ANON_INODES default y Suppose VIRTUALIZATION is selected but KVM is not. Why select ANON_INODES and PREEMPT_NOTIFIERS? ---help--- Say Y here to get to see options for using your Linux host to run other @@ -20,8 +22,6 @@ if VIRTUALIZATION config KVM tristate Kernel-based Virtual Machine (KVM) support depends on HAVE_KVM EXPERIMENTAL - select PREEMPT_NOTIFIERS - select ANON_INODES ---help--- Support hosting fully virtualized guest machines using hardware virtualization extensions. You will need a fairly recent -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix emergency_restart (sysrq-b) with kvm loaded on Intel hosts
* Avi Kivity [EMAIL PROTECTED] wrote: Enabling Intel VT has the curious side effect whereby the INIT signal is blocked. Rather than comment on the wisdom of this side effect, this patch adds an emergency restart reboot notifier, and modifies the kvm reboot notifier to disable VT on emergency reboot. looks good to me - i was bitten by that problem on a testbox. Acked-by: Ingo Molnar [EMAIL PROTECTED] Seems best to merge this via the KVM tree, right? Ingo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]KVM: kvm/ia64: select ANON_INODES PREEMPT_NOTIFIERS, once
Xiantao == Zhang, Xiantao [EMAIL PROTECTED] writes: Xiantao From 2c14c54eed790553fddbcb3970f0967a4aa79dca Mon Sep 17 Xiantao 00:00:00 2001 From: Xiantao Zhang [EMAIL PROTECTED] Xiantao Date: Sat, 23 Aug 2008 10:21:06 +0800 Subject: [PATCH] KVM: Xiantao kvm/ia64: select ANON_INODES PREEMPT_NOTIFIERS, once Xiantao virtualization configured. Hi Xiantao, I think this patch should be sent to Tony and [EMAIL PROTECTED] as well. Cheers, Jes -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix emergency_restart (sysrq-b) with kvm loaded on Intel hosts
Ingo Molnar wrote: * Avi Kivity [EMAIL PROTECTED] wrote: Enabling Intel VT has the curious side effect whereby the INIT signal is blocked. Rather than comment on the wisdom of this side effect, this patch adds an emergency restart reboot notifier, and modifies the kvm reboot notifier to disable VT on emergency reboot. looks good to me - i was bitten by that problem on a testbox. I'm a little worried about making emergency restart more complex. Another thing that worries me is that emergency_restart() doesn't reset the box -- it sends INIT. We could do better by using the ACPI FADT reset register (hopefully that's connected to RESET). The ACPI spec says: 4.7.3.6 Reset Register The optional ACPI reset mechanism specifies a standard mechanism that provides a complete system reset. When implemented, this mechanism must reset the entire system. This includes processors, core logic, all buses, and all peripherals. From an OSPM perspective, asserting the reset mechanism is the logical equivalent to power cycling the machine. Upon gaining control after a reset, OSPM will perform actions in like manner to a cold boot. The reset mechanism is implemented via an 8-bit register described by RESET_REG in the FADT (always accessed via the natural alignment and size described in RESET_REG). To reset the machine, software will write a value (indicated in RESET_VALUE in FADT) to the reset register. The RESET_REG field in the FADT indicates the location of the reset register. The reset register may exist only in I/O space, Memory space, or in PCI Configuration space on a function in bus 0. Therefore, the Address_Space_ID value in RESET_REG must be set to I/O space, Memory space, or PCI Configuration space (with a bus number of 0). As the register is only 8 bits, Register_Bit_Width must be 8 and Register_Bit_Offset must be 0. The system must reset immediately following the write to this register. OSPM assumes that the processor will not execute beyond the write instruction. OSPM should execute spin loops on the CPUs in the system following a write to this register. Which seems to be what we want? Maybe we should just try acpi_reboot() before the other stuff. Acked-by: Ingo Molnar [EMAIL PROTECTED] Seems best to merge this via the KVM tree, right? I'm happy to do that, if everyone feels the patch is fine. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH]KVM: kvm/ia64: select ANON_INODES PREEMPT_NOTIFIERS, once
Avi Kivity wrote: Zhang, Xiantao wrote: From 2c14c54eed790553fddbcb3970f0967a4aa79dca Mon Sep 17 00:00:00 2001 From: Xiantao Zhang [EMAIL PROTECTED] Date: Sat, 23 Aug 2008 10:21:06 +0800 Subject: [PATCH] KVM: kvm/ia64: select ANON_INODES PREEMPT_NOTIFIERS, once virtualization configured. Once virtulization configured, make PREEMPT_NOTIFIERS, ANON_INODES selected by default. What is the motivation for this? Don't things work as is You know, kvm depends on these two configrations. If user doesn't configure KVM when building host kernel, then PREEMPT_NOTIFIERS and ANON_INODES shouldn't be selected . In this case, once user wants to exercise KVM later, he has to replace the host kernel again. To some high-end servers, it maybe infeasible to replace kernel and get a restart. So I want to get them selected once users doesn't disable virtulization explictly. Thanks Xiantao -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix emergency_restart (sysrq-b) with kvm loaded on Intel hosts
* Avi Kivity [EMAIL PROTECTED] wrote: Ingo Molnar wrote: * Avi Kivity [EMAIL PROTECTED] wrote: Enabling Intel VT has the curious side effect whereby the INIT signal is blocked. Rather than comment on the wisdom of this side effect, this patch adds an emergency restart reboot notifier, and modifies the kvm reboot notifier to disable VT on emergency reboot. looks good to me - i was bitten by that problem on a testbox. I'm a little worried about making emergency restart more complex. Another thing that worries me is that emergency_restart() doesn't reset the box -- it sends INIT. We could do better by using the ACPI FADT reset register (hopefully that's connected to RESET). reboot was always a bit fragile - i think we should only do that if we find a box where the FADT reset works better than the first-wave approaches we try. Which seems to be what we want? Maybe we should just try acpi_reboot() before the other stuff. perhaps in a separate commit, for v2.6.28 at the earliest. Ingo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] x86: default to reboot via ACPI
Triple-fault and keyboard reset may assert INIT instead of RESET; however
INIT is blocked when Intel VT is enabled. This leads to a partially reset
machine when invoking emergency_restart via sysrq-b: the processor is still
working but other parts of the system are dead.
Default to rebooting via ACPI, which correctly asserts RESET and reboots the
machine.
This is safe since we will fall back to keyboard reset and triple fault if
acpi is not enabled or if the reset is not successful.
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
---
arch/x86/kernel/reboot.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index 724adfc..f4c93f1 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -29,7 +29,11 @@ EXPORT_SYMBOL(pm_power_off);
static const struct desc_ptr no_idt = {};
static int reboot_mode;
-enum reboot_type reboot_type = BOOT_KBD;
+/*
+ * Keyboard reset and triple fault may result in INIT, not RESET, which
+ * doesn't work when we're in vmx root mode. Try ACPI first.
+ */
+enum reboot_type reboot_type = BOOT_ACPI;
int reboot_force;
#if defined(CONFIG_X86_32) defined(CONFIG_SMP)
--
1.6.0
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]KVM: kvm/ia64: select ANON_INODES PREEMPT_NOTIFIERS, once
Zhang, Xiantao wrote: Avi Kivity wrote: Zhang, Xiantao wrote: From 2c14c54eed790553fddbcb3970f0967a4aa79dca Mon Sep 17 00:00:00 2001 From: Xiantao Zhang [EMAIL PROTECTED] Date: Sat, 23 Aug 2008 10:21:06 +0800 Subject: [PATCH] KVM: kvm/ia64: select ANON_INODES PREEMPT_NOTIFIERS, once virtualization configured. Once virtulization configured, make PREEMPT_NOTIFIERS, ANON_INODES selected by default. What is the motivation for this? Don't things work as is You know, kvm depends on these two configrations. If user doesn't configure KVM when building host kernel, then PREEMPT_NOTIFIERS and ANON_INODES shouldn't be selected . In this case, once user wants to exercise KVM later, he has to replace the host kernel again. To some high-end servers, it maybe infeasible to replace kernel and get a restart. So I want to get them selected once users doesn't disable virtulization explictly. But it also means the user will have these features enabled needlessly. Right now when KVM is the only option under the virtualization menu, this may be okay, but if other features are added, this is not acceptable. Really, if users want KVM, they should enable it in their kernel configuration. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM/userspace: Fix indentation
Amit Shah wrote: Fix indentation style in libkvm.c to match the rest of the file Applied, thanks. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 0/2] madvise(MADV_DONTFORK) guest mem if !mmu_notifiers
Marcelo Tosatti wrote: fork'ing inside qemu can create stale shadow entries without mmu notifiers. Applied both. Thanks. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix emergency_restart (sysrq-b) with kvm loaded on Intel hosts
* Avi Kivity [EMAIL PROTECTED] wrote: reboot was always a bit fragile - i think we should only do that if we find a box where the FADT reset works better than the first-wave approaches we try. It worked on my host. Since it will fall back to keyboard reset and triple fault, it seems fairly safe. ... except if it hangs in ACPI/SMM code for whatever reason. Ingo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] x86: default to reboot via ACPI
* Avi Kivity [EMAIL PROTECTED] wrote: Triple-fault and keyboard reset may assert INIT instead of RESET; however INIT is blocked when Intel VT is enabled. This leads to a partially reset machine when invoking emergency_restart via sysrq-b: the processor is still working but other parts of the system are dead. Default to rebooting via ACPI, which correctly asserts RESET and reboots the machine. This is safe since we will fall back to keyboard reset and triple fault if acpi is not enabled or if the reset is not successful. Signed-off-by: Avi Kivity [EMAIL PROTECTED] applied to tip/x86/reboot - thanks Avi! Ingo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix emergency_restart (sysrq-b) with kvm loaded on Intel hosts
Ingo Molnar wrote: * Avi Kivity [EMAIL PROTECTED] wrote: reboot was always a bit fragile - i think we should only do that if we find a box where the FADT reset works better than the first-wave approaches we try. It worked on my host. Since it will fall back to keyboard reset and triple fault, it seems fairly safe. ... except if it hangs in ACPI/SMM code for whatever reason. acpi reboot doesn't call into the aml interpreter. It just bangs on a port that it reads from a static table. See acpi_reboot(). It's true that SMM could be set up to intercept that port, but in that case, it is even more likely that it intercepts the keyboard controller port (to translate usb keyboards etc). -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] KVM:Qemu: Enable virtio for kvm/ia64.
From 31f8488afa4336362464ed5b9f0c84a9a0fd0c94 Mon Sep 17 00:00:00 2001
From: Xiantao Zhang [EMAIL PROTECTED]
Date: Mon, 25 Aug 2008 18:57:39 +0800
Subject: [PATCH] KVM:Qemu: Enable virtio for kvm/ia64.
Enable virtio-blk for kvm/ia64.
Signed-off-by: Xiantao Zhang [EMAIL PROTECTED]
---
qemu/hw/ipf.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/qemu/hw/ipf.c b/qemu/hw/ipf.c
index 134076a..05f3d68 100644
--- a/qemu/hw/ipf.c
+++ b/qemu/hw/ipf.c
@@ -652,6 +652,17 @@ static void ipf_init1(ram_addr_t ram_size, int
vga_ram_size,
}
}
}
+/* Add virtio block devices */
+if (pci_enabled) {
+ int index;
+ int unit_id = 0;
+
+ while ((index = drive_get_index(IF_VIRTIO, 0, unit_id)) != -1) {
+ virtio_blk_init(pci_bus, 0x1AF4, 0x1001,
+ drives_table[index].bdrv);
+ unit_id++;
+ }
+}
}
static void ipf_init_pci(ram_addr_t ram_size, int vga_ram_size,
--
1.5.1
0001-KVM-Qemu-Enable-virtio-for-kvm-ia64.patch
Description: 0001-KVM-Qemu-Enable-virtio-for-kvm-ia64.patch
[PATCH] Fix COMPAT_csum_offset #endif in virtio_net.c
Fix COMPAT_csum_offset #else/#endif block in virtio_net.c. The #endif
was being output 1 line too early.
Signed-off-by: Mark Pulford [EMAIL PROTECTED]
diff --git a/hack-module.awk b/hack-module.awk
index a3275fa..7cb9381 100644
--- a/hack-module.awk
+++ b/hack-module.awk
@@ -134,6 +134,9 @@
print \t\thdr-csum_start = skb-h.raw - skb-data;;
print \t\thdr-csum_offset = skb-csum;;
print #else
+}
+
+/hdr-csum_offset = skb-csum_offset/ {
need_endif = 1;
}
--
1.5.4.1
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix COMPAT_csum_offset #endif in virtio_net.c
Hi, On Mon, Aug 25, 2008 at 10:12:35PM +0930, Mark Pulford wrote: Fix COMPAT_csum_offset #else/#endif block in virtio_net.c. The #endif was being output 1 line too early. This patch was required to build a working virtio_net driver under 2.6.18. Regards, Mark -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix emergency_restart (sysrq-b) with kvm loaded on Intel hosts
Ingo Molnar [EMAIL PROTECTED] writes: * Avi Kivity [EMAIL PROTECTED] wrote: Enabling Intel VT has the curious side effect whereby the INIT signal is blocked. Rather than comment on the wisdom of this side effect, this patch adds an emergency restart reboot notifier, and modifies the kvm reboot notifier to disable VT on emergency reboot. Please no notifiers in emergency_restart. First emergency_restart is not supposed to work reliably it is a best effort tickle the hardware thing. Second and more importantly whenever someone adds a notifier instead of a proper hook to one a code path like this it seems like avoiding building a proper interface so and I believe keeps us from getting all of the logic and the heuristics right. Why not just add a disable intel_vt if it is enabled call? Eric -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix emergency_restart (sysrq-b) with kvm loaded on Intel hosts
Ingo Molnar [EMAIL PROTECTED] writes: * Avi Kivity [EMAIL PROTECTED] wrote: Enabling Intel VT has the curious side effect whereby the INIT signal is blocked. Rather than comment on the wisdom of this side effect, this patch adds an emergency restart reboot notifier, and modifies the kvm reboot notifier to disable VT on emergency reboot. Please no notifiers in emergency_restart. First emergency_restart is not supposed to work reliably it is a best effort tickle the hardware thing. Second and more importantly whenever someone adds a notifier instead of a proper hook to one a code path like this it seems like avoiding building a proper interface so and I believe keeps us from getting all of the logic and the heuristics right. Why not just add a disable intel_vt if it is enabled call? Eric -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix emergency_restart (sysrq-b) with kvm loaded on Intel hosts
Eric W. Biederman wrote: Ingo Molnar [EMAIL PROTECTED] writes: * Avi Kivity [EMAIL PROTECTED] wrote: Enabling Intel VT has the curious side effect whereby the INIT signal is blocked. Rather than comment on the wisdom of this side effect, this patch adds an emergency restart reboot notifier, and modifies the kvm reboot notifier to disable VT on emergency reboot. Please no notifiers in emergency_restart. First emergency_restart is not supposed to work reliably it is a best effort tickle the hardware thing. Second and more importantly whenever someone adds a notifier instead of a proper hook to one a code path like this it seems like avoiding building a proper interface so and I believe keeps us from getting all of the logic and the heuristics right. Why not just add a disable intel_vt if it is enabled call? We need to do it across all cpus. However, a reliable (and simpler) fix has emerged: reset via ACPI. That causes a true reset which VT does not block. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]KVM: kvm/ia64: select ANON_INODES PREEMPT_NOTIFIERS, once
Zhang, Xiantao wrote: But if users don't configure it @ building kernel, they can't exercise kvm unless re-configure and re-build the host kernel. Generally, we should allow users to build kvm in the form of modules, and insert to host kernels without other dependcies. BTW, we often meet such fails and have to do rebuild. :( If users don't configure networking, they can't compile any drivers. Sorry, that's how the kernel works. btw, on x86 we manage to run even without preempt notifiers, but a lot of pain is involved. In practice, I don't expect a problem. Most users get their kernels from a distribution. You should talk to ia64 distribution vendors to make sure they enable kvm in their ia64 2.6.26+ kernels. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM:Qemu: Enable virtio for kvm/ia64.
Zhang, Xiantao wrote: From 31f8488afa4336362464ed5b9f0c84a9a0fd0c94 Mon Sep 17 00:00:00 2001 From: Xiantao Zhang [EMAIL PROTECTED] Date: Mon, 25 Aug 2008 18:57:39 +0800 Subject: [PATCH] KVM:Qemu: Enable virtio for kvm/ia64. Enable virtio-blk for kvm/ia64. Signed-off-by: Xiantao Zhang [EMAIL PROTECTED] Applied, thanks. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
mandrake-10 not able to boot on kvm-71-73
hi, mandrake-10 are not able to boot on kvm 71-73 while it's working on kvm-70. we noew try to install a minimal mandrake-10 from it's install cd and after the first boot it has the same error: lilo can't find keytable (or something like that). booting from a rescue cd we still able to rerun lilo and it seems to working, but not able to boot. after we downgrade to kvm-70 the system boot without any problem. -- Levente Si vis pacem para bellum! -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] KVM fixes for 2.6.27-rc4
Linus, the repo and branch
git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git kvm-updates-2.6.27
await your pulling pleasure. There's a fix for the kvmtrace ABI, a race
plugged in smp guests on i386 hosts, and a fix for the placement of
exception handlers used during host reboot.
Shortlog, diffstat, and diff follow.
Adrian Bunk (1):
KVM: fix userspace ABI breakage
Avi Kivity (1):
KVM: MMU: Fix torn shadow pte
Eduardo Habkost (1):
KVM: Use .fixup instead of .text.fixup on __kvm_handle_fault_on_reboot
arch/x86/kvm/paging_tmpl.h |2 +-
include/asm-x86/kvm_host.h |2 +-
include/linux/kvm.h|4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
index f72ac1f..4a814bf 100644
--- a/arch/x86/kvm/paging_tmpl.h
+++ b/arch/x86/kvm/paging_tmpl.h
@@ -345,7 +345,7 @@ static u64 *FNAME(fetch)(struct kvm_vcpu *vcpu, gva_t addr,
shadow_addr = __pa(shadow_page-spt);
shadow_pte = shadow_addr | PT_PRESENT_MASK | PT_ACCESSED_MASK
| PT_WRITABLE_MASK | PT_USER_MASK;
- *shadow_ent = shadow_pte;
+ set_shadow_pte(shadow_ent, shadow_pte);
}
mmu_set_spte(vcpu, shadow_ent, access, walker-pte_access access,
diff --git a/include/asm-x86/kvm_host.h b/include/asm-x86/kvm_host.h
index 0f3c531..c2e34c2 100644
--- a/include/asm-x86/kvm_host.h
+++ b/include/asm-x86/kvm_host.h
@@ -722,7 +722,7 @@ asmlinkage void kvm_handle_fault_on_reboot(void);
#define __kvm_handle_fault_on_reboot(insn) \
666: insn \n\t \
- .pushsection .text.fixup, \ax\ \n \
+ .pushsection .fixup, \ax\ \n \
667: \n\t \
KVM_EX_PUSH $666b \n\t \
jmp kvm_handle_fault_on_reboot \n\t \
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index 69511f7..70a3065 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -320,12 +320,12 @@ struct kvm_trace_rec {
struct {
__u64 cycle_u64;
__u32 extra_u32[KVM_TRC_EXTRA_MAX];
- } cycle;
+ } __attribute__((packed)) cycle;
struct {
__u32 extra_u32[KVM_TRC_EXTRA_MAX];
} nocycle;
} u;
-} __attribute__((packed));
+};
#define KVMIO 0xAE
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2062623 ] virtio blockdev -smp 2 unstable
Bugs item #2062623, was opened at 2008-08-20 17:59 Message generated for change (Comment added) made by onedot You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2062623group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: intel Group: None Status: Closed Resolution: Out of Date Priority: 5 Private: No Submitted By: Marvin Vek (onedot) Assigned to: Nobody/Anonymous (nobody) Summary: virtio blockdev -smp 2 unstable Initial Comment: After days and days of constant testing, it turns out the virtio block device in combination with -smp 2 is very very unstable: it seems it loses the disk. At a freeze, things like # dmesg still work, but accessing the disk is the end. Running the tests without if=virtio does not freeze at all. Doing the test with the if=virtio but -smp 1, is as stable as without if=virtio. A freeze did not give any messages at all. If you can tell me what i should enable in the kernel to make something possible pop up at a freeze, or what file to check, let me know. ### TEST SETUP # Start: kvm -drive file=~/guest.iso,index=0,media=disk,if=virtio,boot=on -m 2048 -smp 2 .. # Having the guest recompile the whole system, till it freezes: # emerge -e system emerge -e world. ### HOST # Distro: Gentoo Linux # CPU: Intel Core 2 Duo (Mobile) Penryn T9300, cpuinfo added as attachment # Kernel: 2.6.25-gentoo-r7 # Kernel config: Added as attachment # Bitness: x86_64 multilib # KVM: 72-r1 (with ncurses and sdl support), kvm.ko and kvm-intel.ko built into the kernel. ### GUEST # Distro: Gentoo Linux # Kernel: 2.6.25-gentoo-r7 # Kernel config: added asattachment # Bitness: x86_64 no-multilib, pure 64bit -- Comment By: Marvin Vek (onedot) Date: 2008-08-25 17:37 Message: Logged In: YES user_id=2187666 Originator: YES Having the new KVM-73 installed, deselected the kernel modules (kvm.ko, kvm-intel.ko and kvm-amd.ko), and using KVM-73's modules instead on the same kernel as above, resulted in a perfectly stable environment with the same tests and virtio block device. My guess is that the in-kernel modules are outdated, or something got fixed from 72 to 73, so i marked this bug as Out Of Date and Closed. Thanks a lot! -- Comment By: Marvin Vek (onedot) Date: 2008-08-20 18:02 Message: Logged In: YES user_id=2187666 Originator: YES File Added: .config -- Comment By: Marvin Vek (onedot) Date: 2008-08-20 18:00 Message: Logged In: YES user_id=2187666 Originator: YES File Added: cpuinfo -- Comment By: Marvin Vek (onedot) Date: 2008-08-20 17:59 Message: Logged In: YES user_id=2187666 Originator: YES File Added: .config -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2062623group_id=180599 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kexec/kdump of a kvm guest?
On Thu, Jul 24, 2008 at 9:12 PM, Vivek Goyal [EMAIL PROTECTED] wrote: On Thu, Jul 24, 2008 at 03:03:33PM -0400, Mike Snitzer wrote: On Thu, Jul 24, 2008 at 9:15 AM, Vivek Goyal [EMAIL PROTECTED] wrote: On Thu, Jul 24, 2008 at 07:49:59AM -0400, Mike Snitzer wrote: On Thu, Jul 24, 2008 at 4:39 AM, Alexander Graf [EMAIL PROTECTED] wrote: As you're stating that the host kernel breaks with kvm modules loaded, maybe someone there could give a hint. OK, I can try using a newer kernel on the host too (e.g. 2.6.25.x) to see how kexec/kdump of the host fairs when kvm modules are loaded. On the guest side of things, as I mentioned in my original post, kexec/kdump wouldn't work within a 2.6.22.19 guest with the host running 2.6.25.4 (with kvm-70). Hi Mike, I have never tried kexec/kdump inside a kvm guest. So I don't know if historically they have been working or not. Avi indicated he seems to remember that at least kexec worked last he tried (didn't provide when/what he tried though). Having said that, Why do we need kdump to work inside the guest? In this case qemu should be knowing about the memory of guest kernel and should be able to capture a kernel crash dump? I am not sure if qemu already does that. If not, then probably we should think about it? To me, kdump is a good solution for baremetal but not for virtualized environment where we already have another piece of software running which can do the job for us. We will end up wasting memory in every instance of guest (memory reserved for kdump kernel in every guest). I haven't looked into what mechanics qemu provides for collecting the entire guest memory image; I'll dig deeper at some point. It seems the libvirt mid-layer (virsh dump - dump the core of a domain to a file for analysis) doesn't support saving a kvm guest core: # virsh dump guest10 guest10.dump libvir: error : this function is not supported by the hypervisor: virDomainCoreDump error: Failed to core dump domain guest10 to guest10.dump Seems that libvirt functionality isn't available yet with kvm (I'm using libvirt 0.4.2, I'll give libvirt 0.4.4 a try). cc'ing the libvirt-list to get their insight. That aside, having the crash dump collection be multi-phased really isn't workable (that is if it requires a crashed guest to be manually saved after the fact). The host system _could_ be rebooted; whereby losing the guest's core image. So automating qemu and/or libvirtd to trigger a dump would seem worthwhile (maybe its already done?). That's a good point. Ideally, one would like dump to be captured automatically if kernel crashes and then reboot back to production kernel. I am not sure what can we do to let qemu know after crash so that it can automatically save dump. What happens in the case of xen guests. Is dump automatically captured or one has to force the dump capture externally. So while I agree with you its ideal to not have to waste memory in each guest for the purposes of kdump; if users want to model a guest image as closely as possible to what will be deployed on bare metal it really would be ideal to support a 1:1 functional equivalent with kvm. Agreed. Making kdump work inside kvm guest does not harm. I work with people who refuse to use kvm because of the lack of kexec/kdump support. Interesting. I can do further research but welcome others' insight: do others have advice on how best to collect a crashed kvm guest's core? It will be interesting to look at your results with 2.6.25.x kernels with kvm module inserted. Currently I can't think what can possibly be wrong. If the host's 2.6.25.4 kernel has both the kvm and kvm-intel modules loaded kexec/kdump does _not_ work (simply hangs the system). If I only have the kvm module loaded kexec/kdump works as expected (likewise if no kvm modules are loaded at all). So it would appear that kvm-intel and kexec are definitely mutually exclusive at the moment (at least on both 2.6.22.x and 2.6.25.x). Ok. So first task is to fix host kexec/kdump with kvm-intel module inserted. Can you do little debugging to find out where system hangs. I generally try few things for kexec related issue debugging. 1. Specify earlyprintk= parameter for second kernel and see if control is reaching to second kernel. 2. Otherwise specify --console-serial parameter on kexec -l commandline and it should display a message I am in purgatory on serial console. This will just mean that control has reached at least till purgatory. 3. If that also does not work, then most likely first kernel itself got stuck somewhere and we need to put some printks in first kernel to find out what's wrong. Vivek, I've been unable to put time to chasing this (and I'm not seeing when I'll be able to get back to it yet). I hope that others will be willing to take a look before me. The kvm-intel and kexec incompatibility issue is not
Re: mandrake-10 not able to boot on kvm-71-73
Farkas Levente wrote: hi, mandrake-10 are not able to boot on kvm 71-73 while it's working on kvm-70. we noew try to install a minimal mandrake-10 from it's install cd and after the first boot it has the same error: lilo can't find keytable (or something like that). booting from a rescue cd we still able to rerun lilo and it seems to working, but not able to boot. after we downgrade to kvm-70 the system boot without any problem. Can you mix and match to see whether it is a userspace problem or kernel problem? e.g. kvm-71 userspace with kvm-70 modules, kvm-70 userspace with kvm-71 modules. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kexec/kdump of a kvm guest?
On Mon, Aug 25, 2008 at 11:56:11AM -0400, Mike Snitzer wrote: On Thu, Jul 24, 2008 at 9:12 PM, Vivek Goyal [EMAIL PROTECTED] wrote: On Thu, Jul 24, 2008 at 03:03:33PM -0400, Mike Snitzer wrote: On Thu, Jul 24, 2008 at 9:15 AM, Vivek Goyal [EMAIL PROTECTED] wrote: On Thu, Jul 24, 2008 at 07:49:59AM -0400, Mike Snitzer wrote: On Thu, Jul 24, 2008 at 4:39 AM, Alexander Graf [EMAIL PROTECTED] wrote: As you're stating that the host kernel breaks with kvm modules loaded, maybe someone there could give a hint. OK, I can try using a newer kernel on the host too (e.g. 2.6.25.x) to see how kexec/kdump of the host fairs when kvm modules are loaded. On the guest side of things, as I mentioned in my original post, kexec/kdump wouldn't work within a 2.6.22.19 guest with the host running 2.6.25.4 (with kvm-70). Hi Mike, I have never tried kexec/kdump inside a kvm guest. So I don't know if historically they have been working or not. Avi indicated he seems to remember that at least kexec worked last he tried (didn't provide when/what he tried though). Having said that, Why do we need kdump to work inside the guest? In this case qemu should be knowing about the memory of guest kernel and should be able to capture a kernel crash dump? I am not sure if qemu already does that. If not, then probably we should think about it? To me, kdump is a good solution for baremetal but not for virtualized environment where we already have another piece of software running which can do the job for us. We will end up wasting memory in every instance of guest (memory reserved for kdump kernel in every guest). I haven't looked into what mechanics qemu provides for collecting the entire guest memory image; I'll dig deeper at some point. It seems the libvirt mid-layer (virsh dump - dump the core of a domain to a file for analysis) doesn't support saving a kvm guest core: # virsh dump guest10 guest10.dump libvir: error : this function is not supported by the hypervisor: virDomainCoreDump error: Failed to core dump domain guest10 to guest10.dump Seems that libvirt functionality isn't available yet with kvm (I'm using libvirt 0.4.2, I'll give libvirt 0.4.4 a try). cc'ing the libvirt-list to get their insight. That aside, having the crash dump collection be multi-phased really isn't workable (that is if it requires a crashed guest to be manually saved after the fact). The host system _could_ be rebooted; whereby losing the guest's core image. So automating qemu and/or libvirtd to trigger a dump would seem worthwhile (maybe its already done?). That's a good point. Ideally, one would like dump to be captured automatically if kernel crashes and then reboot back to production kernel. I am not sure what can we do to let qemu know after crash so that it can automatically save dump. What happens in the case of xen guests. Is dump automatically captured or one has to force the dump capture externally. So while I agree with you its ideal to not have to waste memory in each guest for the purposes of kdump; if users want to model a guest image as closely as possible to what will be deployed on bare metal it really would be ideal to support a 1:1 functional equivalent with kvm. Agreed. Making kdump work inside kvm guest does not harm. I work with people who refuse to use kvm because of the lack of kexec/kdump support. Interesting. I can do further research but welcome others' insight: do others have advice on how best to collect a crashed kvm guest's core? It will be interesting to look at your results with 2.6.25.x kernels with kvm module inserted. Currently I can't think what can possibly be wrong. If the host's 2.6.25.4 kernel has both the kvm and kvm-intel modules loaded kexec/kdump does _not_ work (simply hangs the system). If I only have the kvm module loaded kexec/kdump works as expected (likewise if no kvm modules are loaded at all). So it would appear that kvm-intel and kexec are definitely mutually exclusive at the moment (at least on both 2.6.22.x and 2.6.25.x). Ok. So first task is to fix host kexec/kdump with kvm-intel module inserted. Can you do little debugging to find out where system hangs. I generally try few things for kexec related issue debugging. 1. Specify earlyprintk= parameter for second kernel and see if control is reaching to second kernel. 2. Otherwise specify --console-serial parameter on kexec -l commandline and it should display a message I am in purgatory on serial console. This will just mean that control has reached at least till purgatory. 3. If that also does not work, then most likely first kernel itself got stuck somewhere and we need to put some printks in first kernel to find out what's wrong. Vivek, I've been unable to put time to chasing this (and
Re: mandrake-10 not able to boot on kvm-71-73
Farkas Levente wrote: Avi Kivity wrote: Farkas Levente wrote: hi, mandrake-10 are not able to boot on kvm 71-73 while it's working on kvm-70. we noew try to install a minimal mandrake-10 from it's install cd and after the first boot it has the same error: lilo can't find keytable (or something like that). booting from a rescue cd we still able to rerun lilo and it seems to working, but not able to boot. after we downgrade to kvm-70 the system boot without any problem. Can you mix and match to see whether it is a userspace problem or kernel problem? e.g. kvm-71 userspace with kvm-70 modules, kvm-70 userspace with kvm-71 modules. yes. kvm-73 with kmod-kvm-70: not working kvm-70 with kmod-kvm-73: working So it's userspace breakage. Can you check with kvm-71 userspace to be certain that the breakage occured in kvm-71? is it totally safe to use higher kernel module then usersapce? i can i leave it here as it now?: kmod-kvm-2.6.18-92.1.10.el5-73-1 kmod-kvm-73-1 kvm-70-1 Yes. Of course mixed versions are not tested by many people, but they are supported. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2026870 ] xorg-cirrus 1.2.1 fails in x86_64 kvm guests.
Bugs item #2026870, was opened at 2008-07-24 16:56 Message generated for change (Settings changed) made by shawarma You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2026870group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Sren Hansen (shawarma) Assigned to: Nobody/Anonymous (nobody) Summary: xorg-cirrus 1.2.1 fails in x86_64 kvm guests. Initial Comment: When trying to boot an Ubuntu Intrepid amd64 (x86_64) live CD, the guest hangs when starting X. I've narrowed it down to the new version of X. It works when booting with -no-kvm. I'm afraid that's all the info I have right now. -- Comment By: Sren Hansen (shawarma) Date: 2008-08-25 18:54 Message: Logged In: YES user_id=567099 Originator: YES Sorry about the delay. Yes, this is fixed with kvm-72. Thanks very much! -- Comment By: Marcelo Tosatti (mtosatti) Date: 2008-08-05 17:58 Message: Logged In: YES user_id=2022487 Originator: NO shawarma, Seems to be fixed in KVM-72: https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-cirrus/+bug/251480 Can you confirm please? -- Comment By: Sren Hansen (shawarma) Date: 2008-07-24 17:29 Message: Logged In: YES user_id=567099 Originator: YES This time I add -verbose 99 to X's command line. It seems quite a bit more useful now :) # (II) config/hal: initialized(WW) Failed to open protocol names file /etc/X11/xserver/protocol.txt This is a pre-release version of the X server from The X.Org Foundation. It is not supported in any way. Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/. Select the xorg product for bugs you find in this release. Before reporting bugs in pre-release versions please check the latest version in the X.Org Foundation git repository. See http://wiki.x.org/wiki/GitPage for git access instructions. X.Org X Server 1.4.99.905 (1.5.0 RC 5) Release Date: 5 September 2007 X Protocol Version 11, Revision 0 Build Operating System: Linux Ubuntu (xorg-server 2:1.4.99.905-0ubuntu4) Current Operating System: Linux ibsen 2.6.26-4-server #1 SMP Mon Jul 14 19:19:23 UTC 2008 x86_64 Build Date: 16 July 2008 03:40:43PM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Thu Jul 24 15:28:22 2008 (==) Using config file: /etc/X11/xorg.conf (==) ServerLayout Default Layout (**) |--Screen Default Screen (0) (**) | |--Monitor Configured Monitor (**) | |--Device Configured Video Device (==) Automatically adding devices (==) Automatically enabling devices (==) No FontPath specified. Using compiled-in default. (WW) The directory /usr/share/fonts/X11/cyrillic does not exist. Entry deleted from font path. (WW) The directory /usr/share/fonts/X11/100dpi/ does not exist. Entry deleted from font path. (WW) The directory /usr/share/fonts/X11/75dpi/ does not exist. Entry deleted from font path. (WW) The directory /usr/share/fonts/X11/Type1 does not exist. Entry deleted from font path. (WW) The directory /usr/share/fonts/X11/100dpi does not exist. Entry deleted from font path. (WW) The directory /usr/share/fonts/X11/75dpi does not exist. Entry deleted from font path. (WW) The directory /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType does not exist. Entry deleted from font path. (==) FontPath set to: /usr/share/fonts/X11/misc (==) ModulePath set to /usr/lib/xorg/modules (==) |--Input Device Configured Mouse (==) |--Input Device Generic Keyboard (==) The core pointer device wasn't specified explicitly in the layout. Using the first core pointer device. (==) The core keyboard device wasn't specified explicitly in the layout. Using the first keyboard device. (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory) (II) No APM support in BIOS or kernel (II) Loader magic: 0x7b3320 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 4.1 X.Org XInput driver : 2.1 X.Org Server Extension : 1.1 X.Org Font Renderer : 0.6 (II) Loader running on linux (--) using VT number 7 (--) PCI:*([EMAIL PROTECTED]:2:0) Cirrus Logic GD 5446 rev 0, Mem @
Re: mandrake-10 not able to boot on kvm-71-73
Avi Kivity wrote: Farkas Levente wrote: Avi Kivity wrote: Farkas Levente wrote: hi, mandrake-10 are not able to boot on kvm 71-73 while it's working on kvm-70. we noew try to install a minimal mandrake-10 from it's install cd and after the first boot it has the same error: lilo can't find keytable (or something like that). booting from a rescue cd we still able to rerun lilo and it seems to working, but not able to boot. after we downgrade to kvm-70 the system boot without any problem. Can you mix and match to see whether it is a userspace problem or kernel problem? e.g. kvm-71 userspace with kvm-70 modules, kvm-70 userspace with kvm-71 modules. yes. kvm-73 with kmod-kvm-70: not working kvm-70 with kmod-kvm-73: working So it's userspace breakage. Can you check with kvm-71 userspace to be certain that the breakage occured in kvm-71? no it's between 71 and 72 (i'm just not used 71 since it kmod not compiled on rhel-5.2). the situation is more stranger (but probably another bug) kvm-70 (and kvm-71) with kmod-kvm-73: working if and only if i start mandrake-10 as the first guest, if i start other guest and after i start mandrake-10 (both from command line and virt-manager) i've got this (not too long) error: - # /usr/bin/qemu-kvm -S -M pc -m 512 -smp 1 -name mandrake-10 -monitor pty -boot c -drive file=/dev/VolGroup00/mandrake-10,if=ide,index=0,boot=on -net nic,macaddr=00:16:3e:03:37:eb,vlan=0 -net tap,fd=20,script=,vlan=0,ifname=vnet3 -serial none -parallel none -usb -vnc 127.0.0.1:0 bind() failed - if i stop all other guest and start mandrake-10 again then it's work again?! but it's another problem and seems to exist in kvm-70 too. -- Levente Si vis pacem para bellum! -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] v2: Fix monitor console in curses mode
v2: dropped initial display size changes in curses.c -- not needed. The current curses code doesn't adjust the curses and text console display to match the size of the terminal and fails to adjust properly after a resize. The attach patches ensure that text_console_resize events adjust the Textconsole display area so they stay the same size as the curses display. The result is that we no longer see broken output like: QEMU 0.9.1 monitor - type 'help' for more information (qemu) (qemu) (qemu) and you can resize your terminal window and the monitor and serial text consoles adjust properly as well. The second patch is a trivial typo fix in the comments in console.c Comments welcome since I'm new to both curses and qemu console code. Signed-off-by: Ryan Harper [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] Fix typo in console.c comment
Signed-off-by: Ryan Harper [EMAIL PROTECTED] diff --git a/console.c b/console.c index 89bdc52..c7a5a80 100644 --- a/console.c +++ b/console.c @@ -172,7 +172,7 @@ void vga_hw_screen_dump(const char *filename) previous_active_console = active_console; active_console = consoles[0]; /* There is currently no way of specifying which screen we want to dump, - so always dump the dirst one. */ + so always dump the first one. */ if (consoles[0]-hw_screen_dump) consoles[0]-hw_screen_dump(consoles[0]-hw, filename); active_console = previous_active_console; -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Resend: patch: qemu + hugetlbfs..
This patch from over a month ago doesn't seem to have
made it into kvm-73 and may have been lost in the
shuffle. Attached is essentially the same patch but
as applied to kvm-73, and validated relative to that
version.
In a nutshell the intention here is to allow
preallocation of guest huge page backed memory at
qemu initialization time to avoid a quirk in the
kernel's huge page accounting allowing overcommit
of huge pages. Failure of the kernel to resolve a
guest fault to overcommitted huge page memory during
runtime results in sigkill termination of the guest.
This patch provides the option of avoiding such
behavior at the cost of up-front preallocation of
physical huge pages backing the guest.
-john
Anthony Liguori wrote:
john cooper wrote:
Anthony Liguori wrote:
john cooper wrote:
As it currently exists alloc_hpage_mem() is tied to
the notion of huge page allocation as it will reference
gethugepagesize() irrespective of *mem_path. So even
in the case of tmpfs backed files, if the host kernel
has been configured with CONFIG_HUGETLBFS we will wind
up doing allocations of /dev/shm mapped files at
/proc/meminfo:Hugepagesize granularity.
Which is fine. It just means we round -m values up to even numbers.
Well, yes it will round the allocation. But from a
minimally sufficient 4KB boundary to that of 4MB/2MB
relative to a 32/64 bit x86 host which is excessive.
Probably not what was intended but probably not too
much of a concern as -mem-path /dev/shm is likely
only used in debug of this flag and associated logic.
I don't see it currently being worth the trouble to
correct from a squeaky clean POV, and doing so may
drag in far more than the header file we've just
booted above to deal with this architecture/config
dependency.
Renaming a function to a name that's less accurate seems bad to me.
I don't mean to be pedantic, but it seems like a strange thing to
do. I prefer it the way it was before.
I don't see any harm reverting the name. But I do
believe it is largely cosmetic as given the above,
the current code does require some work to make it
independent of huge page assumptions. Update attached.
-john
Looks good to me.
Acked-by: Anthony Liguori [EMAIL PROTECTED]
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
[EMAIL PROTECTED]
vl.c | 48 ++--
1 file changed, 30 insertions(+), 18 deletions(-)
=
--- ./qemu/vl.c.PAORG
+++ ./qemu/vl.c
@@ -239,6 +239,7 @@ int autostart = 1;
int time_drift_fix = 0;
unsigned int kvm_shadow_memory = 0;
const char *mem_path = NULL;
+int mem_prealloc = 1; /* force preallocation of physical target memory */
int hpagesize = 0;
const char *cpu_vendor_string;
#ifdef TARGET_ARM
@@ -8423,7 +8424,10 @@ static void help(int exitcode)
#endif
-tdfinject timer interrupts that got lost\n
-kvm-shadow-memory megs set the amount of shadow pages to be
allocated\n
- -mem-path set the path to hugetlbfs/tmpfs mounted directory,
also enables allocation of guest memory with huge pages\n
+ -mem-path set the path to hugetlbfs/tmpfs mounted directory,
also\n
+ enables allocation of guest memory with huge
pages\n
+ -mem-prealloc toggles preallocation of -mem-path backed physical
memory\n
+ at startup. Default is enabled.\n
-option-rom rom load a file, rom, into the option ROM space\n
#ifdef TARGET_SPARC
-prom-env variable=value set OpenBIOS nvram variables\n
@@ -8546,6 +8550,7 @@ enum {
QEMU_OPTION_tdf,
QEMU_OPTION_kvm_shadow_memory,
QEMU_OPTION_mempath,
+QEMU_OPTION_mem_prealloc
};
typedef struct QEMUOption {
@@ -8671,6 +8676,7 @@ const QEMUOption qemu_options[] = {
{ tb-size, HAS_ARG, QEMU_OPTION_tb_size },
{ icount, HAS_ARG, QEMU_OPTION_icount },
{ mem-path, HAS_ARG, QEMU_OPTION_mempath },
+{ mem-prealloc, 0, QEMU_OPTION_mem_prealloc },
{ NULL },
};
@@ -8890,11 +8896,13 @@ static int gethugepagesize(void)
return hugepagesize;
}
+/* attempt to allocate memory mmap'ed to mem_path
+ */
void *alloc_mem_area(unsigned long memory, const char *path)
{
char *filename;
void *area;
-int fd;
+int fd, flags;
if (asprintf(filename, %s/kvm.XX, path) == -1)
return NULL;
@@ -8922,26 +8930,27 @@ void *alloc_mem_area(unsigned long memor
*/
ftruncate(fd, memory);
-area = mmap(0, memory, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0);
-if (area == MAP_FAILED) {
- perror(mmap);
- close(fd);
- return NULL;
-}
-
-return area;
+/* NB: MAP_POPULATE won't exhaustively alloc all phys pages in the case
+ * MAP_PRIVATE is requested. For
