Re: [PATCH 7/8] KVM: Optimize kvm_read_cr[04]_bits()
Avi Kivity wrote:
'mask' is always a constant, so we can check whether it includes a bit that
might be owned by the guest very cheaply, and avoid the decache call. Saves
a few hundred bytes of module text.
-no-kvm-irqchip -smp 2 is broken for my Linux guests since this commit.
Their user space applications receive #UD and things fall apart.
Jan
Signed-off-by: Avi Kivity a...@redhat.com
---
arch/x86/kvm/kvm_cache_regs.h |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/kvm_cache_regs.h b/arch/x86/kvm/kvm_cache_regs.h
index 6b419a3..5a109c6 100644
--- a/arch/x86/kvm/kvm_cache_regs.h
+++ b/arch/x86/kvm/kvm_cache_regs.h
@@ -1,6 +1,9 @@
#ifndef ASM_KVM_CACHE_REGS_H
#define ASM_KVM_CACHE_REGS_H
+#define KVM_POSSIBLE_CR0_GUEST_BITS X86_CR0_TS
+#define KVM_POSSIBLE_CR4_GUEST_BITS X86_CR4_PGE
+
static inline unsigned long kvm_register_read(struct kvm_vcpu *vcpu,
enum kvm_reg reg)
{
@@ -40,7 +43,8 @@ static inline u64 kvm_pdptr_read(struct kvm_vcpu *vcpu, int
index)
static inline ulong kvm_read_cr0_bits(struct kvm_vcpu *vcpu, ulong mask)
{
- if (mask vcpu-arch.cr0_guest_owned_bits)
+ ulong tmask = mask KVM_POSSIBLE_CR0_GUEST_BITS;
+ if (tmask vcpu-arch.cr0_guest_owned_bits)
kvm_x86_ops-decache_cr0_guest_bits(vcpu);
return vcpu-arch.cr0 mask;
}
@@ -52,7 +56,8 @@ static inline ulong kvm_read_cr0(struct kvm_vcpu *vcpu)
static inline ulong kvm_read_cr4_bits(struct kvm_vcpu *vcpu, ulong mask)
{
- if (mask vcpu-arch.cr4_guest_owned_bits)
+ ulong tmask = mask KVM_POSSIBLE_CR4_GUEST_BITS;
+ if (tmask vcpu-arch.cr4_guest_owned_bits)
kvm_x86_ops-decache_cr4_guest_bits(vcpu);
return vcpu-arch.cr4 mask;
}
signature.asc
Description: OpenPGP digital signature
[PATCH RFC: not fully tested yet] Fix the x86 emulation of in: remove redandancy
Fix the x86 emulation of in:
kvm_emulate_pio() and complete_pio() both read out the
RAX register value and copy it to a place into which
the value read out from the port will be copied later.
This patch removes this redundancy.
/*** snippet from arch/x86/kvm/x86.c ***/
int complete_pio(struct kvm_vcpu *vcpu)
{
...
if (!io-string) {
if (io-in) {
val = kvm_register_read(vcpu, VCPU_REGS_RAX);
memcpy(val, vcpu-arch.pio_data, io-size);
kvm_register_write(vcpu, VCPU_REGS_RAX, val);
}
...
Signed-off-by: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
---
arch/x86/kvm/x86.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index d47ceda..fcbe3a7 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3550,8 +3550,10 @@ int kvm_emulate_pio(struct kvm_vcpu *vcpu, int in, int
size, unsigned port)
trace_kvm_pio(vcpu-run-io.direction == KVM_EXIT_IO_OUT, port,
size, 1);
- val = kvm_register_read(vcpu, VCPU_REGS_RAX);
- memcpy(vcpu-arch.pio_data, val, 4);
+ if (!vcpu-arch.pio.in) {
+ val = kvm_register_read(vcpu, VCPU_REGS_RAX);
+ memcpy(vcpu-arch.pio_data, val, 4);
+ }
if (!kernel_pio(vcpu, vcpu-arch.pio_data)) {
complete_pio(vcpu);
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM-kmod upstream built on a fully updated F12 box cannot be loaded
Lucas Meneghel Rodrigues wrote: Hi folks: Today's upstream test couldn't go further due to a problem trying to load the module built with kvm-kmod: TestFail: Failed to load KVM modules: Command insmod /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/kvm.ko failed, rc=1, Command returned non-zero exit status * Command: insmod /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/kvm.ko Exit status: 1 Duration: 0 stderr: insmod: error inserting '/usr/local/autotest/tests/kvm/src/kvm_kmod/x86/kvm.ko': -1 Unknown symbol in module Having the kernel log here would be more helpful. But I bet you are bitten by the issue that breaks kvm-kmod builds against 2.6.32 and older since this night: http://buildbot.kiszka.org/kvm-kmod/waterfall Relevant commit hashes: 02/04 18:10:29 INFO | kvm_utils:0367| Commit hash for git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git is 336f40a728b9a4a5db5e1df5c89852c79ff95604 (tag v2.6.32-13441-g336f40a) 02/04 18:10:32 INFO | kvm_utils:0367| Commit hash for git://git.kernel.org/pub/scm/virt/kvm/kvm-kmod.git is 20c808f9020fea62cf22802e35c305ea23cb4565 (tag kvm-88-89-g20c808f) The full logs go attached on the message. Please take a look at this issue. The host is a fully updated F12 box. Cheers, Lucas Will look into this later. Thanks, Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM-kmod upstream built on a fully updated F12 box cannot be loaded
On Fri, 2010-02-05 at 10:25 +0100, Jan Kiszka wrote: Lucas Meneghel Rodrigues wrote: Hi folks: Today's upstream test couldn't go further due to a problem trying to load the module built with kvm-kmod: TestFail: Failed to load KVM modules: Command insmod /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/kvm.ko failed, rc=1, Command returned non-zero exit status * Command: insmod /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/kvm.ko Exit status: 1 Duration: 0 stderr: insmod: error inserting '/usr/local/autotest/tests/kvm/src/kvm_kmod/x86/kvm.ko': -1 Unknown symbol in module Having the kernel log here would be more helpful. But I bet you are bitten by the issue that breaks kvm-kmod builds against 2.6.32 and older since this night: http://buildbot.kiszka.org/kvm-kmod/waterfall Yes, sorry, forgot to post dmesg here: kvm: Unknown symbol getboottime kvm: Unknown symbol monotonic_to_bootbased Thanks for looking into this Jan! Lucas -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM-kmod upstream built on a fully updated F12 box cannot be loaded
Lucas Meneghel Rodrigues wrote: On Fri, 2010-02-05 at 10:25 +0100, Jan Kiszka wrote: Lucas Meneghel Rodrigues wrote: Hi folks: Today's upstream test couldn't go further due to a problem trying to load the module built with kvm-kmod: TestFail: Failed to load KVM modules: Command insmod /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/kvm.ko failed, rc=1, Command returned non-zero exit status * Command: insmod /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/kvm.ko Exit status: 1 Duration: 0 stderr: insmod: error inserting '/usr/local/autotest/tests/kvm/src/kvm_kmod/x86/kvm.ko': -1 Unknown symbol in module Having the kernel log here would be more helpful. But I bet you are bitten by the issue that breaks kvm-kmod builds against 2.6.32 and older since this night: http://buildbot.kiszka.org/kvm-kmod/waterfall Yes, sorry, forgot to post dmesg here: kvm: Unknown symbol getboottime kvm: Unknown symbol monotonic_to_bootbased Those two are addressed in next already (with a big-fat warning to not suspend your host if they are missing), will push this into master now. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] qemu-kvm: Speed up of the dirty-bitmap-traveling
dirty-bitmap-traveling is carried out by byte size in qemu-kvm.c.
But We think that dirty-bitmap-traveling by long size is faster than by byte
size especially when most of memory is not dirty.
Signed-off-by: OHMURA Kei ohmura@lab.ntt.co.jp
---
qemu-kvm.c | 49 ++---
1 files changed, 42 insertions(+), 7 deletions(-)
diff --git a/qemu-kvm.c b/qemu-kvm.c
index a305907..5459cdd 100644
--- a/qemu-kvm.c
+++ b/qemu-kvm.c
@@ -2433,22 +2433,21 @@ int kvm_physical_memory_set_dirty_tracking(int enable)
}
/* get kvm's dirty pages bitmap and update qemu's */
-static int kvm_get_dirty_pages_log_range(unsigned long start_addr,
- unsigned char *bitmap,
- unsigned long offset,
- unsigned long mem_size)
+static void kvm_get_dirty_pages_log_range_by_byte(unsigned int start,
+ unsigned int end,
+ unsigned char *bitmap,
+ unsigned long offset)
{
unsigned int i, j, n = 0;
unsigned char c;
unsigned long page_number, addr, addr1;
ram_addr_t ram_addr;
-unsigned int len = ((mem_size / TARGET_PAGE_SIZE) + 7) / 8;
/*
* bitmap-traveling is faster than memory-traveling (for addr...)
* especially when most of the memory is not dirty.
*/
-for (i = 0; i len; i++) {
+for (i = start; i end; i++) {
c = bitmap[i];
while (c 0) {
j = ffsl(c) - 1;
@@ -2461,13 +2460,49 @@ static int kvm_get_dirty_pages_log_range(unsigned long
start_addr,
n++;
}
}
+}
+
+static int kvm_get_dirty_pages_log_range_by_long(unsigned long start_addr,
+ unsigned char *bitmap,
+ unsigned long offset,
+ unsigned long mem_size)
+{
+unsigned int i;
+unsigned int len;
+unsigned long *bitmap_ul = (unsigned long *)bitmap;
+
+/* bitmap-traveling by long size is faster than by byte size
+ * especially when most of memory is not dirty.
+ * bitmap should be long-size aligned for traveling by long.
+ */
+if (((unsigned long)bitmap (TARGET_LONG_SIZE - 1)) == 0) {
+len = ((mem_size / TARGET_PAGE_SIZE) + TARGET_LONG_BITS - 1) /
+TARGET_LONG_BITS;
+for (i = 0; i len; i++)
+if (bitmap_ul[i] != 0)
+kvm_get_dirty_pages_log_range_by_byte(i * TARGET_LONG_SIZE,
+(i + 1) * TARGET_LONG_SIZE, bitmap, offset);
+/*
+ * We will check the remaining dirty-bitmap,
+ * when the mem_size is not a multiple of TARGET_LONG_SIZE.
+ */
+if ((mem_size (TARGET_LONG_SIZE - 1)) != 0) {
+len = ((mem_size / TARGET_PAGE_SIZE) + 7) / 8;
+kvm_get_dirty_pages_log_range_by_byte(i * TARGET_LONG_SIZE,
+len, bitmap, offset);
+}
+} else { /* slow path: traveling by byte. */
+len = ((mem_size / TARGET_PAGE_SIZE) + 7) / 8;
+kvm_get_dirty_pages_log_range_by_byte(0, len, bitmap, offset);
+}
+
return 0;
}
static int kvm_get_dirty_bitmap_cb(unsigned long start, unsigned long len,
void *bitmap, void *opaque)
{
-return kvm_get_dirty_pages_log_range(start, bitmap, start, len);
+return kvm_get_dirty_pages_log_range_by_long(start, bitmap, start, len);
}
/*
-- 1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/11] kvm: Change kvm_iommu_map_pages to map large pages
Hi Marcelo, Avi,
On Mon, Feb 01, 2010 at 05:30:17PM -0200, Marcelo Tosatti wrote:
On Mon, Feb 01, 2010 at 03:18:04PM +0100, Joerg Roedel wrote:
On Fri, Jan 29, 2010 at 10:32:33AM +0100, Joerg Roedel wrote:
On Thu, Jan 28, 2010 at 08:24:55PM -0200, Marcelo Tosatti wrote:
On Thu, Jan 28, 2010 at 12:37:57PM +0100, Joerg Roedel wrote:
+static pfn_t kvm_pin_pages(struct kvm *kvm, struct kvm_memory_slot
*slot,
+gfn_t gfn, unsigned long size)
+{
+ gfn_t end_gfn;
+ pfn_t pfn;
+
+ pfn = gfn_to_pfn_memslot(kvm, slot, gfn);
If gfn_to_pfn_memslot returns pfn of bad_page, you might create a
large iommu translation for it?
Right. But that was broken even before this patch. Anyway, I will fix
it.
+ /* Map into IO address space */
+ r = iommu_map(domain, gfn_to_gpa(gfn), pfn_to_hpa(pfn),
+ get_order(page_size), flags);
+
+ gfn += page_size PAGE_SHIFT;
Should increase gfn after checking for failure, otherwise wrong
npages is passed to kvm_iommu_put_pages.
True. Will fix that too.
Here is the updated patch (also updated in the iommu/largepage branch of
my tree). Does it look ok?
Yes, addresses the concern.
Are there any further objections against this patchset? If not it would
be cool if you could give me some acks for the kvm specific parts of
this patchset.
Joerg
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/11 v2] VT-d: Change {un}map_range functions to implement {un}map interface
Hi David, On Mon, Feb 01, 2010 at 03:16:46PM +0100, Joerg Roedel wrote: On Fri, Jan 29, 2010 at 10:05:26AM +0100, Joerg Roedel wrote: Um, that's not a page-size based interface. Page size isn't always 4KiB; this code runs on IA64 too. We have enough fun with CPU vs. DMA page size on IA64 already :) Ah right. So this should be size = PAGE_SIZE gfp_order; Right? The interface is meant to map the same amount of memory which alloc_pages(gfp_order) would return. Same for the return value of the unmap function. Ok, here is an updated patch (also updated in the iommu/largepage branch). Does it look ok to you David? have you had a chance to look at the new version of the patch? If you are fine with it and with the overall concept of this patchset I would be cool if you could give your Acks. I would like to send this code to Linus in the next merge window. Thanks, Joerg -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] KVM test: Ensure multiple pre/post commands can run
The way tests are currently defined, running unattended install + hugepages will allways skip unattended install setup step (coincidentally the tests on our test farm were working because previous executions of the unattended install script ran, leaving the environment prepared for unattended install). So, make sure pre_commands on default tests.cfg file are additive, and the preprocessor splits the pre_command string, and executes pre/post commands in sequence. Signed-off-by: Lucas Meneghel Rodrigues l...@redhat.com --- client/tests/kvm/kvm_preprocessing.py | 29 - client/tests/kvm/tests_base.cfg.sample |4 ++-- 2 files changed, 18 insertions(+), 15 deletions(-) diff --git a/client/tests/kvm/kvm_preprocessing.py b/client/tests/kvm/kvm_preprocessing.py index 8a0c151..2e35d9f 100644 --- a/client/tests/kvm/kvm_preprocessing.py +++ b/client/tests/kvm/kvm_preprocessing.py @@ -126,7 +126,7 @@ def postprocess_vm(test, params, env, name): vm.destroy(gracefully = params.get(kill_vm_gracefully) == yes) -def process_command(test, params, env, command, command_timeout, +def process_command(test, params, env, commands, command_timeout, command_noncritical): Pre- or post- custom commands to be executed before/after a test is run @@ -134,22 +134,23 @@ def process_command(test, params, env, command, command_timeout, @param test: An Autotest test object. @param params: A dict containing all VM and image parameters. @param env: The environment (a dict-like object). -@param command: Command to be run. +@param commands: List of commands to be run. @param command_timeout: Timeout for command execution. @param command_noncritical: If True test will not fail if command fails. # Export environment vars for k in params.keys(): os.putenv(KVM_TEST_%s % k, str(params[k])) -# Execute command -try: -utils.system(cd %s; %s % (test.bindir, command)) -except error.CmdError, e: -logging.warn(Custom processing command '%s' failed, output is: %s, - command, str(e)) -if not command_noncritical: -raise error.TestError(Custom processing command failed: %s % - str(e)) +# Execute commands +for command in commands: +try: +utils.system(cd %s; %s % (test.bindir, command)) +except error.CmdError, e: +logging.warn(Custom processing command '%s' failed, output is: %s, + command, str(e)) +if not command_noncritical: +raise error.TestError(Custom processing command failed: %s % + str(e)) def process(test, params, env, image_func, vm_func): @@ -220,7 +221,8 @@ def preprocess(test, params, env): # Execute any pre_commands if params.get(pre_command): -process_command(test, params, env, params.get(pre_command), +pre_commands = params.get(pre_command).spit() +process_command(test, params, env, pre_commands, int(params.get(pre_command_timeout, 600)), params.get(pre_command_noncritical) == yes) @@ -296,7 +298,8 @@ def postprocess(test, params, env): # Execute any post_commands if params.get(post_command): -process_command(test, params, env, params.get(post_command), +post_commands = params.get(post_command).split() +process_command(test, params, env, post_commands, int(params.get(post_command_timeout, 600)), params.get(post_command_noncritical) == yes) diff --git a/client/tests/kvm/tests_base.cfg.sample b/client/tests/kvm/tests_base.cfg.sample index 91daf48..8f88f3b 100644 --- a/client/tests/kvm/tests_base.cfg.sample +++ b/client/tests/kvm/tests_base.cfg.sample @@ -66,7 +66,7 @@ variants: kill_vm_gracefully = yes kill_vm_on_error = yes force_create_image = yes -pre_command = scripts/unattended.py +pre_command += scripts/unattended.py floppy = images/floppy.img extra_params += -boot d nic_mode = user @@ -953,7 +953,7 @@ variants: variants: - @smallpages: - hugepages: -pre_command = /usr/bin/python scripts/hugepage.py /mnt/kvm_hugepage +pre_command += scripts/hugepage.py extra_params += -mem-path /mnt/kvm_hugepage -- 1.6.6 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] qemu-kvm: Speed up of the dirty-bitmap-traveling
OHMURA Kei wrote:
dirty-bitmap-traveling is carried out by byte size in qemu-kvm.c.
But We think that dirty-bitmap-traveling by long size is faster than by byte
size especially when most of memory is not dirty.
Sounds logical - do you have numbers on the improvement?
Would be great if you could provide a version for upstream as well
because it will likely replace this qemu-kvm code on day.
Jan
Signed-off-by: OHMURA Kei ohmura@lab.ntt.co.jp
---
qemu-kvm.c | 49 ++---
1 files changed, 42 insertions(+), 7 deletions(-)
diff --git a/qemu-kvm.c b/qemu-kvm.c
index a305907..5459cdd 100644
--- a/qemu-kvm.c
+++ b/qemu-kvm.c
@@ -2433,22 +2433,21 @@ int kvm_physical_memory_set_dirty_tracking(int enable)
}
/* get kvm's dirty pages bitmap and update qemu's */
-static int kvm_get_dirty_pages_log_range(unsigned long start_addr,
- unsigned char *bitmap,
- unsigned long offset,
- unsigned long mem_size)
+static void kvm_get_dirty_pages_log_range_by_byte(unsigned int start,
+ unsigned int end,
+ unsigned char *bitmap,
+ unsigned long offset)
{
unsigned int i, j, n = 0;
unsigned char c;
unsigned long page_number, addr, addr1;
ram_addr_t ram_addr;
-unsigned int len = ((mem_size / TARGET_PAGE_SIZE) + 7) / 8;
/*
* bitmap-traveling is faster than memory-traveling (for addr...)
* especially when most of the memory is not dirty.
*/
-for (i = 0; i len; i++) {
+for (i = start; i end; i++) {
c = bitmap[i];
while (c 0) {
j = ffsl(c) - 1;
@@ -2461,13 +2460,49 @@ static int kvm_get_dirty_pages_log_range(unsigned
long start_addr,
n++;
}
}
+}
+
+static int kvm_get_dirty_pages_log_range_by_long(unsigned long start_addr,
+ unsigned char *bitmap,
+ unsigned long offset,
+ unsigned long mem_size)
+{
+unsigned int i;
+unsigned int len;
+unsigned long *bitmap_ul = (unsigned long *)bitmap;
+
+/* bitmap-traveling by long size is faster than by byte size
+ * especially when most of memory is not dirty.
+ * bitmap should be long-size aligned for traveling by long.
+ */
+if (((unsigned long)bitmap (TARGET_LONG_SIZE - 1)) == 0) {
+len = ((mem_size / TARGET_PAGE_SIZE) + TARGET_LONG_BITS - 1) /
+TARGET_LONG_BITS;
+for (i = 0; i len; i++)
+if (bitmap_ul[i] != 0)
+kvm_get_dirty_pages_log_range_by_byte(i * TARGET_LONG_SIZE,
+(i + 1) * TARGET_LONG_SIZE, bitmap, offset);
+/*
+ * We will check the remaining dirty-bitmap,
+ * when the mem_size is not a multiple of TARGET_LONG_SIZE.
+ */
+if ((mem_size (TARGET_LONG_SIZE - 1)) != 0) {
+len = ((mem_size / TARGET_PAGE_SIZE) + 7) / 8;
+kvm_get_dirty_pages_log_range_by_byte(i * TARGET_LONG_SIZE,
+len, bitmap, offset);
+}
+} else { /* slow path: traveling by byte. */
+len = ((mem_size / TARGET_PAGE_SIZE) + 7) / 8;
+kvm_get_dirty_pages_log_range_by_byte(0, len, bitmap, offset);
+}
+
return 0;
}
static int kvm_get_dirty_bitmap_cb(unsigned long start, unsigned long len,
void *bitmap, void *opaque)
{
-return kvm_get_dirty_pages_log_range(start, bitmap, start, len);
+return kvm_get_dirty_pages_log_range_by_long(start, bitmap, start, len);
}
/*
-- 1.6.3.3
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Passthrough PCI video capture card
2010/2/5 Ameya Pandit cont...@ameyapandit.com: SNIP Please find below logs for more information. I want to passthrough this PCI card to one of the VM. Any suggestions how to do this? You need to have a system with IOMMU support, eg. Intel VT-d or AMD I/O Virtualization Technology (IOMMU). Your chipset needs to support this, it has nothing to do with virtualization support of your CPU. If you have a proper system, you can use the following guide for passthrough: http://www.linux-kvm.org/page/How_to_assign_devices_with_VT-d_in_KVM Best Regards Kenni Lund -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Seabios incompatible with Linux 2.6.26 host?
On 4 févr. 2010, at 15:34, Pierre Riteau wrote: Hello, I'm having trouble running the latest qemu-kvm code on Debian Lenny (Linux 2.6.26). qemu-kvm dies with an error like this one: exception 13 (0) rax 0010 rbx 8c00 rcx 6ebe rdx 000c8c00 rsi e201 rdi 000c rsp 6eb4 rbp e201 r8 r9 r10 r11 r12 r13 r14 r15 rip 000fdeb0 rflags 00033002 cs (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ds (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) es (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ss (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) fs (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) gs (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) tr (feffd000/2088 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) ldt (/ p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0) gdt f7a20/37 idt f8aa0/0 cr0 10 cr2 0 cr3 0 cr4 0 cr8 0 efer 0 code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -- 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 I think I traced back the issue to the switch from Bochs BIOS to Seabios. By forcing the usage of Bochs BIOS 5f08bb45861f54be478b25075b90d2406a0f8bb3 works, while it dies without the -bios override. Unfortunately, newer versions don't seem to work with Bochs BIOS. Upgrading the host kernel to 2.6.32 (Debian Squeeze) solves the issue. No problem on Fedora 12 as well. Am I the only one to see this issue? -- Pierre Riteau -- PhD student, Myriads team, IRISA, Rennes, France http://perso.univ-rennes1.fr/pierre.riteau/ -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Seabios incompatible with Linux 2.6.26 host?
Pierre Riteau wrote: On 4 févr. 2010, at 15:34, Pierre Riteau wrote: Hello, I'm having trouble running the latest qemu-kvm code on Debian Lenny (Linux 2.6.26). qemu-kvm dies with an error like this one: exception 13 (0) rax 0010 rbx 8c00 rcx 6ebe rdx 000c8c00 rsi e201 rdi 000c rsp 6eb4 rbp e201 r8 r9 r10 r11 r12 r13 r14 r15 rip 000fdeb0 rflags 00033002 cs (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ds (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) es (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ss (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) fs (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) gs (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) tr (feffd000/2088 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) ldt (/ p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0) gdt f7a20/37 idt f8aa0/0 cr0 10 cr2 0 cr3 0 cr4 0 cr8 0 efer 0 code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -- 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 I think I traced back the issue to the switch from Bochs BIOS to Seabios. By forcing the usage of Bochs BIOS 5f08bb45861f54be478b25075b90d2406a0f8bb3 works, while it dies without the -bios override. Unfortunately, newer versions don't seem to work with Bochs BIOS. Upgrading the host kernel to 2.6.32 (Debian Squeeze) solves the issue. No problem on Fedora 12 as well. Am I the only one to see this issue? The oldest kernels I've running here are 2.6.27. They all run kvm-kmod, and they are all happy (mostly). Are you using the KVM support 2.6.26 provided or are you on some recent kvm-kmod? The latter is highly recommended for tons of reasons. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Seabios incompatible with Linux 2.6.26 host?
On 5 févr. 2010, at 15:46, Jan Kiszka wrote: Pierre Riteau wrote: On 4 févr. 2010, at 15:34, Pierre Riteau wrote: Hello, I'm having trouble running the latest qemu-kvm code on Debian Lenny (Linux 2.6.26). qemu-kvm dies with an error like this one: exception 13 (0) rax 0010 rbx 8c00 rcx 6ebe rdx 000c8c00 rsi e201 rdi 000c rsp 6eb4 rbp e201 r8 r9 r10 r11 r12 r13 r14 r15 rip 000fdeb0 rflags 00033002 cs (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ds (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) es (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ss (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) fs (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) gs (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) tr (feffd000/2088 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) ldt (/ p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0) gdt f7a20/37 idt f8aa0/0 cr0 10 cr2 0 cr3 0 cr4 0 cr8 0 efer 0 code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -- 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 I think I traced back the issue to the switch from Bochs BIOS to Seabios. By forcing the usage of Bochs BIOS 5f08bb45861f54be478b25075b90d2406a0f8bb3 works, while it dies without the -bios override. Unfortunately, newer versions don't seem to work with Bochs BIOS. Upgrading the host kernel to 2.6.32 (Debian Squeeze) solves the issue. No problem on Fedora 12 as well. Am I the only one to see this issue? The oldest kernels I've running here are 2.6.27. They all run kvm-kmod, and they are all happy (mostly). Are you using the KVM support 2.6.26 provided or are you on some recent kvm-kmod? The latter is highly recommended for tons of reasons. Jan I use the KVM modules provided by the distribution. -- Pierre Riteau -- PhD student, Myriads team, IRISA, Rennes, France http://perso.univ-rennes1.fr/pierre.riteau/ -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Seabios incompatible with Linux 2.6.26 host?
Pierre Riteau wrote: On 5 févr. 2010, at 15:46, Jan Kiszka wrote: Pierre Riteau wrote: On 4 févr. 2010, at 15:34, Pierre Riteau wrote: Hello, I'm having trouble running the latest qemu-kvm code on Debian Lenny (Linux 2.6.26). qemu-kvm dies with an error like this one: exception 13 (0) rax 0010 rbx 8c00 rcx 6ebe rdx 000c8c00 rsi e201 rdi 000c rsp 6eb4 rbp e201 r8 r9 r10 r11 r12 r13 r14 r15 rip 000fdeb0 rflags 00033002 cs (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ds (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) es (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ss (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) fs (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) gs (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) tr (feffd000/2088 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) ldt (/ p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0) gdt f7a20/37 idt f8aa0/0 cr0 10 cr2 0 cr3 0 cr4 0 cr8 0 efer 0 code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -- 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 I think I traced back the issue to the switch from Bochs BIOS to Seabios. By forcing the usage of Bochs BIOS 5f08bb45861f54be478b25075b90d2406a0f8bb3 works, while it dies without the -bios override. Unfortunately, newer versions don't seem to work with Bochs BIOS. Upgrading the host kernel to 2.6.32 (Debian Squeeze) solves the issue. No problem on Fedora 12 as well. Am I the only one to see this issue? The oldest kernels I've running here are 2.6.27. They all run kvm-kmod, and they are all happy (mostly). Are you using the KVM support 2.6.26 provided or are you on some recent kvm-kmod? The latter is highly recommended for tons of reasons. Jan I use the KVM modules provided by the distribution. Then it makes some sense to try with kvm-kmod first. I do not know what KVM patches debian people back-ported to their kernel, maybe you run into long-fixed bugs. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Seabios incompatible with Linux 2.6.26 host?
On Thu, Feb 04, 2010 at 03:34:24PM +0100, Pierre Riteau wrote: I think I traced back the issue to the switch from Bochs BIOS to Seabios. By forcing the usage of Bochs BIOS 5f08bb45861f54be478b25075b90d2406a0f8bb3 works, while it dies without the -bios override. Unfortunately, newer versions don't seem to work with Bochs BIOS. Upgrading the host kernel to 2.6.32 (Debian Squeeze) solves the issue. No problem on Fedora 12 as well. Even Linux 2.6.31 stopped working as a host for me since that commit. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] KVM: tests_base.cfg: major guest OS cleanup
Major update and cleanup on guest OS definition: * Fedora 8, 9, 10 dropped * RHEL versions bumped to the latest stable versions * Windows 2008, Vista and 7 bumped to the last versions * Some duplicate information re-organized Signed-off-by: Lucas Meneghel Rodrigues l...@redhat.com --- client/tests/kvm/tests_base.cfg.sample | 286 --- client/tests/kvm/unattended/winxp64.sif | 73 2 files changed, 149 insertions(+), 210 deletions(-) create mode 100644 client/tests/kvm/unattended/winxp64.sif diff --git a/client/tests/kvm/tests_base.cfg.sample b/client/tests/kvm/tests_base.cfg.sample index 8f88f3b..110be98 100644 --- a/client/tests/kvm/tests_base.cfg.sample +++ b/client/tests/kvm/tests_base.cfg.sample @@ -311,47 +311,8 @@ variants: shell_prompt = ^\[.*\][\#\$]\s*$ variants: -- 8.32: -no setup -image_name = fc8-32 -install: -steps = Fedora-8-i386.steps -cdrom = linux/Fedora-8-i386-DVD.iso -md5sum = dd6c79fddfff36d409d02242e7b10189 -md5sum_1m = dabae451bb69fbbad0e505b25144b1f9 - -- 8.64: -no setup -image_name = fc8-64 -install: -steps = Fedora-8-64.steps -cdrom = linux/Fedora-8-x86_64-DVD.iso -md5sum = 2cb231a86709dec413425fd2f8bf5295 -md5sum_1m = 145f6414e19492649a56c89f0a45e719 - -- 9.32: -image_name = fc9-32 -install: -steps = Fedora-9-i386.steps -cdrom = linux/Fedora-9-i386-DVD.iso -md5sum = 72601f685ea8c808c303353d8bf4d307 -md5sum_1m = f24fa25689e5863f1b99984c6feb787f - -- 9.64: -image_name = fc9-64 -install: -steps = Fedora-9-64.steps -cdrom = linux/Fedora-9-x86_64-DVD.iso -md5sum = 05b2ebeed273ec54d6f9ed3d61ea4c96 -md5sum_1m = 9822ab5097e37e8fe306ef2192727db4 - - 11.32: image_name = fc11-32 -install: -steps = Fedora-11-32.steps -cdrom = linux/Fedora-11-i386-DVD.iso -md5sum = e3b1e2d1ba42aa4705fa5f41771b3927 -md5sum_1m = dc8ddf90648c247339c721395aa49714 unattended_install: cdrom = linux/Fedora-11-i386-DVD.iso md5sum = e3b1e2d1ba42aa4705fa5f41771b3927 @@ -363,12 +324,6 @@ variants: - 11.64: image_name = fc11-64 -install: -cdrom = linux/Fedora-11-x86_64-DVD.iso -md5sum = 9d419844adeb93120215fe7505c9bce8 -md5sum_1m = 405ee05e2387a2e4328b008d5bcbdd1e -type = steps -steps = Fedora-11-64.steps unattended_install: cdrom = linux/Fedora-11-x86_64-DVD.iso md5sum = 9d419844adeb93120215fe7505c9bce8 @@ -482,108 +437,66 @@ variants: modprobe_module = acpiphp block_hotplug: modprobe_module = acpiphp +unattended_install: +tftp = images/tftpboot +extra_params += -bootp /pxelinux.0 -boot n +kernel_args = ks=floppy nicdelay=60 + variants: -- 5.3.i386: +- 5.4.i386: no setup image_name = rhel5-32 -install: -steps=RHEL-5.3-i386.steps -cdrom=linux/RHEL-5.3-i386-DVD.iso -md5sum=371c62851611fd32ead440df6f24a296 -md5sum_1m=242318dd44152210f6ff6cdda1bfbf51 unattended_install: -cdrom=linux/RHEL-5.3-i386-DVD.iso -md5sum=371c62851611fd32ead440df6f24a296 -md5sum_1m=242318dd44152210f6ff6cdda1bfbf51 -tftp = images/tftpboot -extra_params += -bootp /pxelinux.0 -boot n -kernel_args = ks=floppy nicdelay=60 +cdrom=linux/RHEL-5.4-i386-DVD.iso +
Re: Seabios incompatible with Linux 2.6.26 host?
Christoph Hellwig wrote: On Thu, Feb 04, 2010 at 03:34:24PM +0100, Pierre Riteau wrote: I think I traced back the issue to the switch from Bochs BIOS to Seabios. By forcing the usage of Bochs BIOS 5f08bb45861f54be478b25075b90d2406a0f8bb3 works, while it dies without the -bios override. Unfortunately, newer versions don't seem to work with Bochs BIOS. Upgrading the host kernel to 2.6.32 (Debian Squeeze) solves the issue. No problem on Fedora 12 as well. Even Linux 2.6.31 stopped working as a host for me since that commit. At least kvm-kmod-2.6.31.6 worked fine here, just recently run it with various versions of qemu-kvm. Does it bail out at the same address like Pierre? Looking at the code that fails, ljmp $0xf000,$0xdeb5, it might be affected by the KVM commit ee3d29e8be (KVM: x86 emulator: fix jmp far decoding (opcode 0xea)) which predates 2.6.31.1... Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] emulate accessed bit for EPT
On Thu, Feb 04, 2010 at 06:47:15PM +0100, Andrea Arcangeli wrote: On Thu, Feb 04, 2010 at 08:40:43AM -0500, Rik van Riel wrote: I suspect it won't be very many. I have been monitoring /proc/meminfo on my system while testing this patch, and it is quite typical that the size of the inactive anon list does not change for minutes at a time. In other words, no pages are moved onto or off of the inactive anon list for several minutes. That corresponds to a very small number of minor faults introduced by my patch. When there's light VM pressure, ideally there should be zero overhead caused by the patch. When there is VM pressure this will avoid some unnecessary I/O which should outweight the minor faults. It should be a good default behavior. Agree. But perhaps a module parameter to turn accessed bit emulation off might be handy in the future? -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] emulate accessed bit for EPT
On Fri, Feb 05, 2010 at 03:34:23PM -0200, Marcelo Tosatti wrote: But perhaps a module parameter to turn accessed bit emulation off might be handy in the future? Maybe, but somebody should show that this can overall become a downside, which I doubt... I think if it does, the VM is to blame for calling page_referenced when there is no point to do so just yet. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
