[PATCH] KVM: ia64: Define printk function for kvm-intel module
From: Xiantao Zhang [EMAIL PROTECTED]
kvm-intel module is relocated to an isolated address space
with kernel, so it can't call host kernel's printk for debug
purpose. In the module, we implement the printk to output debug
info of vmm.
Signed-off-by: Xiantao Zhang [EMAIL PROTECTED]
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
diff --git a/arch/ia64/include/asm/kvm_host.h b/arch/ia64/include/asm/kvm_host.h
index 678e264..0560f3f 100644
--- a/arch/ia64/include/asm/kvm_host.h
+++ b/arch/ia64/include/asm/kvm_host.h
@@ -39,6 +39,7 @@
#define EXIT_REASON_EXTERNAL_INTERRUPT 6
#define EXIT_REASON_IPI7
#define EXIT_REASON_PTC_G 8
+#define EXIT_REASON_DEBUG 20
/*Define vmm address space and vm data space.*/
#define KVM_VMM_SIZE (__IA64_UL_CONST(16)20)
@@ -126,6 +127,8 @@
KVM_MEM_DIRTY_LOG_SIZE) / sizeof(struct kvm_vcpu_data)
#define KVM_MAX_MEM_SIZE (KVM_P2M_SIZE 3 PAGE_SHIFT)
+#define VMM_LOG_LEN 256
+
#include linux/types.h
#include linux/mm.h
#include linux/kvm.h
@@ -437,6 +440,7 @@ struct kvm_vcpu_arch {
unsigned long opcode;
unsigned long cause;
+ char log_buf[VMM_LOG_LEN];
union context host;
union context guest;
};
diff --git a/arch/ia64/kvm/Makefile b/arch/ia64/kvm/Makefile
index 92cef66..76464dc 100644
--- a/arch/ia64/kvm/Makefile
+++ b/arch/ia64/kvm/Makefile
@@ -60,7 +60,7 @@ obj-$(CONFIG_KVM) += kvm.o
CFLAGS_vcpu.o += -mfixed-range=f2-f5,f12-f127
kvm-intel-objs = vmm.o vmm_ivt.o trampoline.o vcpu.o optvfault.o mmio.o \
- vtlb.o process.o
+ vtlb.o process.o kvm_lib.o
#Add link memcpy and memset to avoid possible structure assignment error
kvm-intel-objs += memcpy.o memset.o
obj-$(CONFIG_KVM_INTEL) += kvm-intel.o
diff --git a/arch/ia64/kvm/kvm-ia64.c b/arch/ia64/kvm/kvm-ia64.c
index 70eb829..b4d24e2 100644
--- a/arch/ia64/kvm/kvm-ia64.c
+++ b/arch/ia64/kvm/kvm-ia64.c
@@ -474,6 +474,13 @@ static int handle_external_interrupt(struct kvm_vcpu *vcpu,
return 1;
}
+static int handle_vcpu_debug(struct kvm_vcpu *vcpu,
+ struct kvm_run *kvm_run)
+{
+ printk(VMM: %s, vcpu-arch.log_buf);
+ return 1;
+}
+
static int (*kvm_vti_exit_handlers[])(struct kvm_vcpu *vcpu,
struct kvm_run *kvm_run) = {
[EXIT_REASON_VM_PANIC] = handle_vm_error,
@@ -485,6 +492,7 @@ static int (*kvm_vti_exit_handlers[])(struct kvm_vcpu *vcpu,
[EXIT_REASON_EXTERNAL_INTERRUPT]= handle_external_interrupt,
[EXIT_REASON_IPI] = handle_ipi,
[EXIT_REASON_PTC_G] = handle_global_purge,
+ [EXIT_REASON_DEBUG] = handle_vcpu_debug,
};
diff --git a/arch/ia64/kvm/kvm_lib.c b/arch/ia64/kvm/kvm_lib.c
new file mode 100644
index 000..a85cb61
--- /dev/null
+++ b/arch/ia64/kvm/kvm_lib.c
@@ -0,0 +1,15 @@
+/*
+ * kvm_lib.c: Compile some libraries for kvm-intel module.
+ *
+ * Just include kernel's library, and disable symbols export.
+ * Copyright (C) 2008, Intel Corporation.
+ * Xiantao Zhang ([EMAIL PROTECTED])
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+#undef CONFIG_MODULES
+#include ../../../lib/vsprintf.c
+#include ../../../lib/ctype.c
diff --git a/arch/ia64/kvm/vmm.c b/arch/ia64/kvm/vmm.c
index 2275bf4..9577795 100644
--- a/arch/ia64/kvm/vmm.c
+++ b/arch/ia64/kvm/vmm.c
@@ -62,5 +62,31 @@ void vmm_spin_unlock(spinlock_t *lock)
{
_vmm_raw_spin_unlock(lock);
}
+
+static void vcpu_debug_exit(struct kvm_vcpu *vcpu)
+{
+ struct exit_ctl_data *p = vcpu-arch.exit_data;
+ long psr;
+
+ local_irq_save(psr);
+ p-exit_reason = EXIT_REASON_DEBUG;
+ vmm_transition(vcpu);
+ local_irq_restore(psr);
+}
+
+asmlinkage int printk(const char *fmt, ...)
+{
+ struct kvm_vcpu *vcpu = current_vcpu;
+ va_list args;
+ int r;
+
+ memset(vcpu-arch.log_buf, 0, VMM_LOG_LEN);
+ va_start(args, fmt);
+ r = vsnprintf(vcpu-arch.log_buf, VMM_LOG_LEN, fmt, args);
+ va_end(args);
+ vcpu_debug_exit(vcpu);
+ return r;
+}
+
module_init(kvm_vmm_init)
module_exit(kvm_vmm_exit)
--
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: MMU: fix sync of ptes addressed at owner pagetable
From: Marcelo Tosatti [EMAIL PROTECTED]
During page sync, if a pagetable contains a self referencing pte (that
points to the pagetable), the corresponding spte may be marked as
writable even though all mappings are supposed to be write protected.
Fix by clearing page unsync before syncing individual sptes.
Signed-off-by: Marcelo Tosatti [EMAIL PROTECTED]
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 7d77730..fa3486d 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1046,13 +1046,13 @@ static int kvm_sync_page(struct kvm_vcpu *vcpu, struct
kvm_mmu_page *sp)
}
rmap_write_protect(vcpu-kvm, sp-gfn);
+ kvm_unlink_unsync_page(vcpu-kvm, sp);
if (vcpu-arch.mmu.sync_page(vcpu, sp)) {
kvm_mmu_zap_page(vcpu-kvm, sp);
return 1;
}
kvm_mmu_flush_tlb(vcpu);
- kvm_unlink_unsync_page(vcpu-kvm, sp);
return 0;
}
--
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: ia64: Add some debug points to provide crash infomation
From: Xiantao Zhang [EMAIL PROTECTED]
Use printk infrastructure to print out some debug info once VM crashes.
Signed-off-by: Xiantao Zhang [EMAIL PROTECTED]
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
diff --git a/arch/ia64/kvm/mmio.c b/arch/ia64/kvm/mmio.c
index 7f1a858..21f63ff 100644
--- a/arch/ia64/kvm/mmio.c
+++ b/arch/ia64/kvm/mmio.c
@@ -66,31 +66,25 @@ void lsapic_write(struct kvm_vcpu *v, unsigned long addr,
switch (addr) {
case PIB_OFST_INTA:
- /*panic_domain(NULL, Undefined write on PIB INTA\n);*/
- panic_vm(v);
+ panic_vm(v, Undefined write on PIB INTA\n);
break;
case PIB_OFST_XTP:
if (length == 1) {
vlsapic_write_xtp(v, val);
} else {
- /*panic_domain(NULL,
- Undefined write on PIB XTP\n);*/
- panic_vm(v);
+ panic_vm(v, Undefined write on PIB XTP\n);
}
break;
default:
if (PIB_LOW_HALF(addr)) {
- /*lower half */
+ /*Lower half */
if (length != 8)
- /*panic_domain(NULL,
- Can't LHF write with size %ld!\n,
- length);*/
- panic_vm(v);
+ panic_vm(v, Can't LHF write with size %ld!\n,
+ length);
else
vlsapic_write_ipi(v, addr, val);
- } else { /* upper half
- printk(IPI-UHF write %lx\n,addr);*/
- panic_vm(v);
+ } else { /*Upper half */
+ panic_vm(v, IPI-UHF write %lx\n, addr);
}
break;
}
@@ -108,22 +102,18 @@ unsigned long lsapic_read(struct kvm_vcpu *v, unsigned
long addr,
if (length == 1) /* 1 byte load */
; /* There is no i8259, there is no INTA access*/
else
- /*panic_domain(NULL,Undefined read on PIB INTA\n); */
- panic_vm(v);
+ panic_vm(v, Undefined read on PIB INTA\n);
break;
case PIB_OFST_XTP:
if (length == 1) {
result = VLSAPIC_XTP(v);
- /* printk(read xtp %lx\n, result); */
} else {
- /*panic_domain(NULL,
- Undefined read on PIB XTP\n);*/
- panic_vm(v);
+ panic_vm(v, Undefined read on PIB XTP\n);
}
break;
default:
- panic_vm(v);
+ panic_vm(v, Undefined addr access for lsapic!\n);
break;
}
return result;
@@ -162,7 +152,7 @@ static void mmio_access(struct kvm_vcpu *vcpu, u64 src_pa,
u64 *dest,
/* it's necessary to ensure zero extending */
*dest = p-u.ioreq.data (~0UL (64-(s*8)));
} else
- panic_vm(vcpu);
+ panic_vm(vcpu, Unhandled mmio access returned!\n);
out:
local_irq_restore(psr);
return ;
@@ -324,7 +314,9 @@ void emulate_io_inst(struct kvm_vcpu *vcpu, u64 padr, u64
ma)
return;
} else {
inst_type = -1;
- panic_vm(vcpu);
+ panic_vm(vcpu, Unsupported MMIO access instruction! \
+ Bunld[0]=0x%lx, Bundle[1]=0x%lx\n,
+ bundle.i64[0], bundle.i64[1]);
}
size = 1 size;
@@ -335,7 +327,7 @@ void emulate_io_inst(struct kvm_vcpu *vcpu, u64 padr, u64
ma)
if (inst_type == SL_INTEGER)
vcpu_set_gr(vcpu, inst.M1.r1, data, 0);
else
- panic_vm(vcpu);
+ panic_vm(vcpu, Unsupported instruction type!\n);
}
vcpu_increment_iip(vcpu);
diff --git a/arch/ia64/kvm/process.c b/arch/ia64/kvm/process.c
index 8008173..cefc349 100644
--- a/arch/ia64/kvm/process.c
+++ b/arch/ia64/kvm/process.c
@@ -527,7 +527,8 @@ void reflect_interruption(u64 ifa, u64 isr, u64 iim,
vector = vec2off[vec];
if (!(vpsr IA64_PSR_IC) (vector != IA64_DATA_NESTED_TLB_VECTOR)) {
- panic_vm(vcpu);
+ panic_vm(vcpu, Interruption with vector :0x%lx occurs
+ with psr.ic = 0\n, vector);
return;
}
@@ -586,7 +587,7 @@ static void set_pal_call_result(struct kvm_vcpu *vcpu)
vcpu_set_gr(vcpu, 10, p-u.pal_data.ret.v1, 0);
vcpu_set_gr(vcpu, 11, p-u.pal_data.ret.v2, 0);
} else
-
[PATCH] KVM: ia64: Fix: Use correct calling convention for PAL_VPS_RESUME_HANDLER
From: Xiantao Zhang [EMAIL PROTECTED] PAL_VPS_RESUME_HANDLER should use r26 to hold vac fields according to SDM. Signed-off-by: Xiantao Zhang [EMAIL PROTECTED] Signed-off-by: Avi Kivity [EMAIL PROTECTED] diff --git a/arch/ia64/kvm/optvfault.S b/arch/ia64/kvm/optvfault.S index 634abad..32254ce 100644 --- a/arch/ia64/kvm/optvfault.S +++ b/arch/ia64/kvm/optvfault.S @@ -107,10 +107,10 @@ END(kvm_vps_resume_normal) GLOBAL_ENTRY(kvm_vps_resume_handler) movl r30 = PAL_VPS_RESUME_HANDLER ;; - ld8 r27=[r25] + ld8 r26=[r25] shr r17=r17,IA64_ISR_IR_BIT ;; - dep r27=r17,r27,63,1 // bit 63 of r27 indicate whether enable CFLE + dep r26=r17,r26,63,1 // bit 63 of r26 indicate whether enable CFLE mov pr=r23,-2 br.sptk.many kvm_vps_entry END(kvm_vps_resume_handler) @@ -894,12 +894,15 @@ ENTRY(kvm_resume_to_guest) ;; ld8 r19=[r19] mov b0=r29 - cmp.ne p6,p7 = r0,r0 + mov r27=cr.isr ;; - tbit.z p6,p7 = r19,IA64_PSR_IC_BIT // p1=vpsr.ic + tbit.z p6,p7 = r19,IA64_PSR_IC_BIT // p7=vpsr.ic + shr r27=r27,IA64_ISR_IR_BIT ;; (p6) ld8 r26=[r25] (p7) mov b0=r28 + ;; + (p6) dep r26=r27,r26,63,1 mov pr=r31,-2 br.sptk.many b0 // call pal service ;; -- 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 07/12] Add VMRUN handler v6
On Fri, Nov 21, 2008 at 04:35:32PM +0100, Alexander Graf wrote:
Alexander Graf wrote:
Muli Ben-Yehuda wrote:
On Fri, Nov 21, 2008 at 04:14:37PM +0100, Alexander Graf wrote:
+static int vmrun_interception(struct vcpu_svm *svm, struct kvm_run
*kvm_run)
+{
+ nsvm_printk(VMrun\n);
+ if (nested_svm_check_permissions(svm))
+ return 1;
+
+ svm-next_rip = kvm_rip_read(svm-vcpu) + 3;
+ skip_emulated_instruction(svm-vcpu);
+
+ if (nested_svm_do(svm, svm-vmcb-save.rax, 0,
+ NULL, nested_svm_vmrun))
+ return 1;
+
+ if (nested_svm_do(svm, svm-vmcb-control.msrpm_base_pa, 0,
+ NULL, nested_svm_vmrun_msrpm))
+ return 1;
nested_svm_vmrun returns 1 unconditionally, so we never call
nested_svm_vmrun_msrpm.
Wow the one thing you pointed out earlier. I must've missed to write
that on my TODO list.
I'll fix this right now :). Await v7 any second now.
Wow this is more tricky than I thought. I gotta go now, but I'll
look into it in more detail on Tuesday. I promise :-). For now
please just don't use the MSR check.
No problem. While you are looking at it, another question: In the
vmrun handler, we call kvm_mmu_reset_context() in the SPT case
only. In the vmexit handler, we call kvm_mmu_reset_context() for both
SPT and NPT. Why the discrepancy?
Cheers,
Muli
--
The First Workshop on I/O Virtualization (WIOV '08)
Dec 2008, San Diego, CA, http://www.usenix.org/wiov08/
-
SYSTOR 2009---The Israeli Experimental Systems Conference
http://www.haifa.il.ibm.com/conferences/systor2009/
--
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: kvm kernel backtrace 2.6.27.3 using kvm 78 userspace
Kasper Sandberg wrote: Hello. I just noticed that my dmesg had been flooded with backtraces, appearing to be of KVM origin. I realize that my kernel is tainted, and slightly outdated, however, i just wanted to drop the log here in case it might be useful, but feel free to completely ignore it :) i am not subscribed to the kvm list, so please cc me in case you need further info.. my entire dmesg was flooded with backtraces looking practically identical to this one, so i will only paste a few of them, however, should you want more(though from a quick look they appear identical), i can put online the complete log What guest are you running? -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- 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: Is this a bug in qemu-img?
walt wrote: I do a fresh install of Windows vista on qcow2 which works perfectly. Thereafter I use that image as a backing file to make all kinds of updates to Vista, and all that works perfectly too. Then I use 'qemu-img commit' to commit all the changes I've made to Vista. The problem is that the updated base image doesn't work quite right if I try to run Vista from it -- there are minor malfunctions which indicate that the commit was incomplete or maybe just wrong. What's your sequence of commands? Are you using -snapshot? -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- 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 03/11] KVM: Replace irq_requested with more generic irq_requested_type
Sheng Yang wrote:
Separate guest irq type and host irq type, for we can support guest using INTx
with host using MSI (but not opposite combination).
Signed-off-by: Sheng Yang [EMAIL PROTECTED]
---
include/linux/kvm_host.h |4 +++-
virt/kvm/kvm_main.c |9 +
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 3a0fb77..c3d4b96 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -307,7 +307,9 @@ struct kvm_assigned_dev_kernel {
int host_devfn;
int host_irq;
int guest_irq;
- int irq_requested;
+#define KVM_ASSIGNED_DEV_GUEST_INTX(1 0)
+#define KVM_ASSIGNED_DEV_HOST_INTX (1 8)
+ unsigned long irq_requested_type;
int irq_source_id;
struct pci_dev *dev
Any particular reason the bits were not assigned sequentially?
--
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 09/11] KVM: Add assigned_device_msi_dispatch()
Sheng Yang wrote:
The function is used to dispatch MSI to lapic according to MSI message
address and message data.
+
+ deliver_bitmask = kvm_ioapic_get_delivery_bitmask(ioapic,
+ dest_id, dest_mode);
+ switch (delivery_mode) {
+ case MSI_DATA_DELIVERY_LOWPRI:
+ vcpu = kvm_get_lowest_prio_vcpu(ioapic-kvm, vector,
+ deliver_bitmask);
+ if (vcpu != NULL)
+ kvm_apic_set_irq(vcpu, vector, trig_mode);
+ else
+ printk(KERN_INFO kvm: null lowest priority vcpu!\n);
+ break;
+ case MSI_DATA_DELIVERY_FIXED:
+ for (vcpu_id = 0; deliver_bitmask != 0; vcpu_id++) {
+ if (!(deliver_bitmask (1 vcpu_id)))
+ continue;
+ deliver_bitmask = ~(1 vcpu_id);
+ vcpu = ioapic-kvm-vcpus[vcpu_id];
+ if (vcpu)
+ kvm_apic_set_irq(vcpu, vector, trig_mode);
+ }
+ break;
+ default:
This duplicates the ioapic code. That's fine for now, but eventually
we'll want to refactor this.
--
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] Fix off-by-one bug limiting VNC passwords to 7 chars
Fix off-by-one bug limiting VNC passwords to 7 characters instead of 8
monitor_readline expects buf_size to include the terminating \0, but
do_change_vnc in monitor.c calls it as though it doesn't. The other site
where monitor_readline reads a password (in vl.c) passes the buffer length
correctly.
Signed-off-by: Chris Webb [EMAIL PROTECTED]
---
monitor.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/monitor.c b/monitor.c
index 22360fc..6ae5729 100644
--- a/monitor.c
+++ b/monitor.c
@@ -433,7 +433,7 @@ static void do_change_vnc(const char *target)
if (strcmp(target, passwd) == 0 ||
strcmp(target, password) == 0) {
char password[9];
- monitor_readline(Password: , 1, password, sizeof(password)-1);
+ monitor_readline(Password: , 1, password, sizeof(password));
password[sizeof(password)-1] = '\0';
if (vnc_display_password(NULL, password) 0)
term_printf(could not set VNC server password\n);
--
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 3/4] Support for device capability
Sheng Yang wrote:
This framework can be easily extended to support device capability, like
MSI/MSI-x.
At least some of this should go into pci.c, so non-assigned devices can
benefit.
static void assigned_dev_pci_write_config(PCIDevice *d, uint32_t address,
uint32_t val, int len)
{
int fd;
ssize_t ret;
+AssignedDevice *pci_dev = (AssignedDevice *)d;
container_of()
--
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] Accept password as an argument to 'change vnc password'
Accept password as an argument to 'change vnc password' monitor command
This allows easier use of the change vnc password monitor command from
management scripts, without having to implement expect(1)-like behaviour.
Signed-off-by: Chris Webb [EMAIL PROTECTED]
---
monitor.c | 13 -
qemu-doc.texi |8
2 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/monitor.c b/monitor.c
index 22360fc..8ac73c1 100644
--- a/monitor.c
+++ b/monitor.c
@@ -428,12 +428,15 @@ static void do_change_block(const char *device, const
char *filename, const char
qemu_key_check(bs, filename);
}
-static void do_change_vnc(const char *target)
+static void do_change_vnc(const char *target, const char *arg)
{
if (strcmp(target, passwd) == 0 ||
strcmp(target, password) == 0) {
char password[9];
- monitor_readline(Password: , 1, password, sizeof(password));
+ if (arg)
+ strncpy(password, arg, sizeof(password));
+ else
+ monitor_readline(Password: , 1, password, sizeof(password));
password[sizeof(password)-1] = '\0';
if (vnc_display_password(NULL, password) 0)
term_printf(could not set VNC server password\n);
@@ -443,12 +446,12 @@ static void do_change_vnc(const char *target)
}
}
-static void do_change(const char *device, const char *target, const char *fmt)
+static void do_change(const char *device, const char *target, const char *arg)
{
if (strcmp(device, vnc) == 0) {
- do_change_vnc(target);
+ do_change_vnc(target, arg);
} else {
- do_change_block(device, target, fmt);
+ do_change_block(device, target, arg);
}
}
diff --git a/qemu-doc.texi b/qemu-doc.texi
index 1735d92..ca3b181 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -1233,11 +1233,11 @@ and @var{options} are described at
@ref{sec_invocation}. eg
(qemu) change vnc localhost:1
@end example
[EMAIL PROTECTED] change vnc password
[EMAIL PROTECTED] change vnc password [EMAIL PROTECTED]
-Change the password associated with the VNC server. The monitor will prompt for
-the new password to be entered. VNC passwords are only significant upto 8
letters.
-eg.
+Change the password associated with the VNC server. If the new password is not
+supplied, the monitor will prompt for it to be entered. VNC passwords are only
+significant up to 8 letters. eg
@example
(qemu) change vnc password
--
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 10/11] KVM: Enable MSI for device assignment
Sheng Yang wrote:
We enable guest MSI and host MSI support in this patch. The userspace want to
enable MSI should set KVM_DEV_IRQ_ASSIGN_ENABLE_MSI in the assigned_irq's flag.
Function would return -ENOTTY if can't enable MSI, userspace shouldn't set MSI
Enable bit when KVM_ASSIGN_IRQ return -ENOTTY with
KVM_DEV_IRQ_ASSIGN_ENABLE_MSI.
Userspace can tell the support of MSI device from #ifdef KVM_CAP_DEVICE_MSI.
Signed-off-by: Sheng Yang [EMAIL PROTECTED]
---
include/linux/kvm.h |3 ++
virt/kvm/kvm_main.c | 81 +++
2 files changed, 78 insertions(+), 6 deletions(-)
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index bb283c3..e7dae05 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -392,6 +392,9 @@ struct kvm_trace_rec {
#endif
#define KVM_CAP_IOMMU 18
#define KVM_CAP_NMI 19
+#if defined(CONFIG_X86)||defined(CONFIG_IA64)
+#define KVM_CAP_DEVICE_MSI 20
+#endif
Since the code only enables x86 for now, please drop ia64.
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index c41488f..8e0b599 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -158,9 +158,15 @@ static void kvm_assigned_dev_interrupt_work_handler(struct
work_struct *work)
* finer-grained lock, update this
*/
mutex_lock(assigned_dev-kvm-lock);
- kvm_set_irq(assigned_dev-kvm,
- assigned_dev-irq_source_id,
- assigned_dev-guest_irq, 1);
+ if (assigned_dev-irq_requested_type KVM_ASSIGNED_DEV_GUEST_INTX)
+ kvm_set_irq(assigned_dev-kvm,
+ assigned_dev-irq_source_id,
+ assigned_dev-guest_irq, 1);
+ else if (assigned_dev-irq_requested_type
+ KVM_ASSIGNED_DEV_GUEST_MSI) {
+ assigned_device_msi_dispatch(assigned_dev);
+ enable_irq(assigned_dev-host_irq);
+ }
Please move this logic to kvm_set_irq(). Hmm, that's not possible right
now, so we can leave it as is for now.
--
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: KVM: MMU: fix sync of ptes addressed at owner pagetable
Marcelo Tosatti wrote: During page sync, if a pagetable contains a self referencing pte (that points to the pagetable), the corresponding spte may be marked as writable even though all mappings are supposed to be write protected. Fix by clearing page unsync before syncing individual sptes. 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: [Qemu-devel] [PATCH] Fix off-by-one bug limiting VNC passwords to 7 chars
Chris Webb wrote:
Fix off-by-one bug limiting VNC passwords to 7 characters instead of 8
monitor_readline expects buf_size to include the terminating \0, but
do_change_vnc in monitor.c calls it as though it doesn't. The other site
where monitor_readline reads a password (in vl.c) passes the buffer length
correctly.
Signed-off-by: Chris Webb [EMAIL PROTECTED]
---
monitor.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/monitor.c b/monitor.c
index 22360fc..6ae5729 100644
--- a/monitor.c
+++ b/monitor.c
@@ -433,7 +433,7 @@ static void do_change_vnc(const char *target)
if (strcmp(target, passwd) == 0 ||
strcmp(target, password) == 0) {
char password[9];
- monitor_readline(Password: , 1, password, sizeof(password)-1);
+ monitor_readline(Password: , 1, password, sizeof(password));
password[sizeof(password)-1] = '\0';
The next line can go as well, the string is already NULL terminated.
Thiemo
--
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 07/11] x86: Rename MSI macro name
Sheng Yang wrote: Signed-off-by: Sheng Yang [EMAIL PROTECTED] --- arch/x86/include/asm/msidef.h |4 ++-- arch/x86/kernel/io_apic.c |4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/x86/include/asm/msidef.h b/arch/x86/include/asm/msidef.h index 6706b30..988cb27 100644 --- a/arch/x86/include/asm/msidef.h +++ b/arch/x86/include/asm/msidef.h @@ -15,8 +15,8 @@ MSI_DATA_VECTOR_MASK) #define MSI_DATA_DELIVERY_MODE_SHIFT 8 -#define MSI_DATA_DELIVERY_FIXED (0 MSI_DATA_DELIVERY_MODE_SHIFT) -#define MSI_DATA_DELIVERY_LOWPRI (1 MSI_DATA_DELIVERY_MODE_SHIFT) +#define MSI_DATA_DELIVERY_FIXED_BIT (0 MSI_DATA_DELIVERY_MODE_SHIFT) +#define MSI_DATA_DELIVERY_LOWPRI_BIT (1 MSI_DATA_DELIVERY_MODE_SHIFT) These are usually named _MASK, not _BIT. But I recommend dropping this patch, it can only cause conflicts with other development. -- 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 01/11] KVM: Move ack notifier register and IRQ sourcd ID request
Sheng Yang wrote: Signed-off-by: Sheng Yang [EMAIL PROTECTED] --- virt/kvm/kvm_main.c | 30 +++--- 1 files changed, 19 insertions(+), 11 deletions(-) Why is this needed? comment for the changelog. -- 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 02/11] KVM: Separate update irq to a single function
Sheng Yang wrote: Signed-off-by: Sheng Yang [EMAIL PROTECTED] Again, missing explanation in changelog comment. -- 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 00/05] Patchset of kvm/ia64
Zhang, Xiantao wrote: Hi, Avi Please apply the patchset of kvm/ia64. The first two implement debug mechanism for vmm module. And the third targets to support vmm crash handling. The 4th one is cleanupig vmm_ivt.S with uniform indentation. The last one are key fix for 2.6.28, so please also apply it as 2.6.28's fix. Applied all, and queued #5 for 2.6.28. 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 07/12] Add VMRUN handler v6
On 23.11.2008, at 08:06, Muli Ben-Yehuda [EMAIL PROTECTED] wrote:
On Fri, Nov 21, 2008 at 04:35:32PM +0100, Alexander Graf wrote:
Alexander Graf wrote:
Muli Ben-Yehuda wrote:
On Fri, Nov 21, 2008 at 04:14:37PM +0100, Alexander Graf wrote:
+static int vmrun_interception(struct vcpu_svm *svm, struct
kvm_run *kvm_run)
+{
+nsvm_printk(VMrun\n);
+if (nested_svm_check_permissions(svm))
+return 1;
+
+svm-next_rip = kvm_rip_read(svm-vcpu) + 3;
+skip_emulated_instruction(svm-vcpu);
+
+if (nested_svm_do(svm, svm-vmcb-save.rax, 0,
+ NULL, nested_svm_vmrun))
+return 1;
+
+if (nested_svm_do(svm, svm-vmcb-control.msrpm_base_pa, 0,
+ NULL, nested_svm_vmrun_msrpm))
+return 1;
nested_svm_vmrun returns 1 unconditionally, so we never call
nested_svm_vmrun_msrpm.
Wow the one thing you pointed out earlier. I must've missed to write
that on my TODO list.
I'll fix this right now :). Await v7 any second now.
Wow this is more tricky than I thought. I gotta go now, but I'll
look into it in more detail on Tuesday. I promise :-). For now
please just don't use the MSR check.
No problem. While you are looking at it, another question: In the
vmrun handler, we call kvm_mmu_reset_context() in the SPT case
only. In the vmexit handler, we call kvm_mmu_reset_context() for both
SPT and NPT. Why the discrepancy?
It should only be necessary on the SPT case, because with NPT our mmu
stays the same. We still only convert from host to l1 guest.
IIRC npt broke for me without that reset though and thus I put it
in :-/.
Alex
Cheers,
Muli
--
The First Workshop on I/O Virtualization (WIOV '08)
Dec 2008, San Diego, CA, http://www.usenix.org/wiov08/
-
SYSTOR 2009---The Israeli Experimental Systems Conference
http://www.haifa.il.ibm.com/conferences/systor2009/
--
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/RFC] kvm: fix refcounting race release vs. module unload
Christian Borntraeger wrote:
The problem is that kvm_destroy_vm can run while the module count
is 0. That means, you can remove the module while kvm_destroy_vm
is running. But kvm_destroy_vm is part of the module text. This
causes a kerneloops. The race exists without the msleep but is much
harder to trigger.
Nevertheless, the right solution is to call kvm_destroy_vm only
with module_ref_count 0. This can be done by calling kvm_destroy_vm
only via a release function, since the VFS will not allow module unload.
This patch sets kvm_vcpu_fops.owner to the module and manually
increases the module refcount after anon_inode_getfd, since
anon_inode_getfd does not do it.
Signed-off-by: Christian Borntraeger [EMAIL PROTECTED]
---
virt/kvm/kvm_main.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Index: kvm/virt/kvm/kvm_main.c
===
--- kvm.orig/virt/kvm/kvm_main.c
+++ kvm/virt/kvm/kvm_main.c
@@ -1303,7 +1303,7 @@ static int kvm_vcpu_release(struct inode
return 0;
}
-static const struct file_operations kvm_vcpu_fops = {
+static struct file_operations kvm_vcpu_fops = {
.release= kvm_vcpu_release,
.unlocked_ioctl = kvm_vcpu_ioctl,
.compat_ioctl = kvm_vcpu_ioctl,
@@ -1318,6 +1318,7 @@ static int create_vcpu_fd(struct kvm_vcp
int fd = anon_inode_getfd(kvm-vcpu, kvm_vcpu_fops, vcpu, 0);
if (fd 0)
kvm_put_kvm(vcpu-kvm);
+ __module_get(kvm_vcpu_fops.owner);
return fd;
}
@@ -2061,6 +2062,7 @@ int kvm_init(void *opaque, unsigned int
}
kvm_chardev_ops.owner = module;
+ kvm_vcpu_fops.owner = module;
r = misc_register(kvm_dev);
if (r) {
Messing with module counts is slightly ugly. How about having a vm fd
fget() the /dev/kvm fd() instead?
--
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: *terrible* speed of savevm/loadvm/delvm
Michael Tokarev wrote: As you see, it writes 2 bytes, llseeks to THE SAME position, writes next 2 bytes and so on. This takes HUGE amount of time, and can be done, in most cases, in a single write without any seeks. Is it just me or are savevm/loadvm/delvm really THAT broken? It's qcow2 that is broken, with the new default cache=writethrough. Does cache=writeback speed things up? Please excuse me for this long delay replying... I tried other solutions meanwhile (migrate to exec:), but did not succeed there either. Well. While with writeback mode, the speed is definitely better. But it is still very very slow - not THAT terrible, but it still takes several mins to complete a 512MB VM with a single 4Gb qcow2 file. Any idea what is happening? Is it disk bound, or cpu bound? It shouldn't be that slow with writeback. -- 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: kvm kernel backtrace 2.6.27.3 using kvm 78 userspace
On Sun, 2008-11-23 at 10:49 +0200, Avi Kivity wrote: Kasper Sandberg wrote: Hello. I just noticed that my dmesg had been flooded with backtraces, appearing to be of KVM origin. I realize that my kernel is tainted, and slightly outdated, however, i just wanted to drop the log here in case it might be useful, but feel free to completely ignore it :) i am not subscribed to the kvm list, so please cc me in case you need further info.. my entire dmesg was flooded with backtraces looking practically identical to this one, so i will only paste a few of them, however, should you want more(though from a quick look they appear identical), i can put online the complete log What guest are you running? Yeah sorry, i was gonna include that in the mail, i apparently forgot. I have been running debian, both 32 and 64bit inside it, .18, .24 and .26 kernels, and ubuntu 8.10 .27 kernels, ATLEAST 32bit, i do not remember if i have run 64bit ubuntu 8.10 I can however give some information that _MIGHT_ (i have no clue myself) be relevant on one of the debian guests i had xrandr crash the X server while trying to change resolution, i did this a few times. Using -vga std. also, on the ubuntu 32bit guest, i ran qemu with debian stable, where X crashed during start inside the qemu on the ubuntu guest. This happened only once. im quite certain my ram and that is fine, no errors when doing memory testing etc. but as said, the kernel is tainted, i dont know if that affects the results or not, i just wanted to inform in case this can help someone. That being said, the box has NOT been rebooted since, and i can confirm that kvm works excellently, i have spawned several VMs and used a tad, since i wrote the mail. -- 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 07/12] Add VMRUN handler v6
On Sun, Nov 23, 2008 at 01:48:11PM +, Alexander Graf wrote: It should only be necessary on the SPT case, because with NPT our mmu stays the same. We still only convert from host to l1 guest. IIRC npt broke for me without that reset though and thus I put it in :-/. I think that merits a comment, if not an actual resolution ;-) Cheers, Muli -- The First Workshop on I/O Virtualization (WIOV '08) Dec 2008, San Diego, CA, http://www.usenix.org/wiov08/ - SYSTOR 2009---The Israeli Experimental Systems Conference http://www.haifa.il.ibm.com/conferences/systor2009/ -- 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: Weekly KVM Test report, kernel 30d95f ... userspace fc94d1 ...
Xu, Jiajun wrote: 2. failure to migrate guests with more than 4GB of RAM https://sourceforge.net/tracker/index.php?func=detailaid=1971512group_id=180599atid=893831 Can you retest this? I successfully migrated a 5G guest (from a 4G host to itself; slo...)/ -- 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: Is this a bug in qemu-img?
On Sun, 23 Nov 2008, Avi Kivity wrote: walt wrote: I do a fresh install of Windows vista on qcow2 which works perfectly. Thereafter I use that image as a backing file to make all kinds of updates to Vista, and all that works perfectly too. Then I use 'qemu-img commit' to commit all the changes I've made to Vista. The problem is that the updated base image doesn't work quite right if I try to run Vista from it -- there are minor malfunctions which indicate that the commit was incomplete or maybe just wrong. What's your sequence of commands? Are you using -snapshot? No, not using -snapshot anywhere. I'm not sure how much detail you want, but here's from the beginning: #qemu-img create -f qcow2 vista 20G #qemu-system-x86_64 -m 2048 -cdrom vistasp1.iso vista [install vista without updating and exit] #qemu-img create -f qcow2 -b vista vista.delta #qemu-system-x86_64 -m 2048 vista.delta [update vista with all the recent patches and exit] Everything above works perfectly. I can reboot vista, check for new updates, create user accounts, all the normal stuff. Now comes the trouble: #qemu-img commit vista.delta [takes 1 hour] Now, IIUC the base image vista should be entirely useable by itself, i.e. I can delete vista.delta and everyting should still work correctly? But it doesn't. For example, when I boot vista and try to look for windows updates, the updates page is almost blank and completely non-functional. There may be other problems too, but I haven't bothered to look. BTW, I've been through the same steps twice and get the same results, so I don't think it's flakey hardware. OTOH today is a new day, so I'll try it again to triple check. Any thoughts? Thanks. -- 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-2275173 ] savevm is extremely slow
Bugs item #2275173, was opened at 2008-11-13 10:36 Message generated for change (Comment added) made by avik You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2275173group_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: Open Resolution: None Priority: 5 Private: No Submitted By: Daniel van Vugt (danv) Assigned to: Nobody/Anonymous (nobody) Summary: savevm is extremely slow Initial Comment: In kvm-79, a 1.3MB snapshot has taken several minutes to savevm. In kvm-78 it was slightly faster taking only about one minute to savevm 2.4MB. It doesn't sound right to me. Also, Michael Tokarev is reporting the same thing on the kvm mailing list. kvm-79 Intel(R) Core(TM)2 Quad CPUQ6600 @ 2.40GHz Ubuntu 8.04 Desktop amd64(x86_64) -- Comment By: Avi Kivity (avik) Date: 2008-11-23 20:44 Message: A temporary workaround is to use -drive file=...,cache=writeback -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2275173group_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
[ kvm-Bugs-2318236 ] SCSI debug
Bugs item #2318236, was opened at 2008-11-20 20:41 Message generated for change (Comment added) made by avik You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2318236group_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: Open Resolution: None Priority: 5 Private: No Submitted By: Ryan Bair (ryandbair) Assigned to: Nobody/Anonymous (nobody) Summary: SCSI debug Initial Comment: Here is the stdout with SCSI_DEBUG enabled. The guest is Windows Server 2003 R2 x64 with an emulated scsi device being served from a 36GB raw file on a Debian Lenny host with KVM-79. I get the mentioned error on both quick and full format. Let me know if there is anything else I can provide that would be of assistance. -- Comment By: Avi Kivity (avik) Date: 2008-11-23 20:46 Message: What exactly is the problem you're seeing? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2318236group_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
[ kvm-Bugs-2318236 ] SCSI debug
Bugs item #2318236, was opened at 2008-11-20 20:41 Message generated for change (Settings changed) made by avik You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2318236group_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: Pending Resolution: None Priority: 5 Private: No Submitted By: Ryan Bair (ryandbair) Assigned to: Nobody/Anonymous (nobody) Summary: SCSI debug Initial Comment: Here is the stdout with SCSI_DEBUG enabled. The guest is Windows Server 2003 R2 x64 with an emulated scsi device being served from a 36GB raw file on a Debian Lenny host with KVM-79. I get the mentioned error on both quick and full format. Let me know if there is anything else I can provide that would be of assistance. -- Comment By: Avi Kivity (avik) Date: 2008-11-23 20:46 Message: What exactly is the problem you're seeing? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2318236group_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
[ kvm-Bugs-2327497 ] NFS copy makes guest network unstable
Bugs item #2327497, was opened at 2008-11-22 17:53 Message generated for change (Settings changed) made by avik You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2327497group_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: Pending Resolution: None Priority: 5 Private: No Submitted By: Jiajun Xu (jiajun) Assigned to: Nobody/Anonymous (nobody) Summary: NFS copy makes guest network unstable Initial Comment: The NFS network of KVM guest is very unstable. When we copy a 600M file to the guest by NFS mount. The guest's network will down after finishing at about 500M size. Then, guest's network is down. Host also can not use ping or scp. And sometimes, host also complains: ping: sendmsg: No buffer space available. I see memory by 'free', there is only 69MB free (While totally 8GB on the machine!). Using scp to copy file can not reproduce it. This issue is very easy to be reproduced (50%). Reproduce steps: 1. Create a guest and config NFS sharing folder on it 2. Mount the nfs folder to local folder --- /media 3. cp xxx /media 4. After some time, guest network is down -- Comment By: Avi Kivity (avik) Date: 2008-11-23 20:40 Message: Is this a regression, or a new test? It it is a regression, what was the last version that worked? -- Comment By: Fabio Coatti (cova) Date: 2008-11-23 17:12 Message: I can confirm a similar behaviour: a kvm machines gets large amounts of data via http protocol and saves that files over NFS. (file sizes are in the range of 4-20 MB approx and the machine downloads several of that files.) After some time (I don't have a precise figure, but some hundreds of MB) the guest nework goes down. No answers even to ping coming from outside. the guest uses virtio network drivers (as normal drivers are way too slow) host machine: 64 bit AMD dual quad core 16GB, tried with several kernels ranging from 2.6.27.4 to 2.6.25.19 guest: 32 bit kvm machines (tried 76/77/78 ). both UP and SMP configuration. kernels: same as host machine network setup: bridged network with br0 device on host machine. We are using 2 vlans for guest and we have tried all the configuration (single tap and vlans resolved on guest side,then two tap so two interfaces on guest machine and so on) without any improvement. I can exclude MTU issues, as we have seen that and solved, this issue is completely different. At some point, sniffing traffic on host interfaces we are able to see only ARP requests coming from guest, nothing more. I understand that data is in no way complete, but I'm willing to do any debug if someone gives me any hint on how to do so correctly. Thanks. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2327497group_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
[ kvm-Bugs-2219447 ] kvm_run: Cannot allocate memory
Bugs item #2219447, was opened at 2008-11-03 22:32 Message generated for change (Comment added) made by avik You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2219447group_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: Open Resolution: None Priority: 5 Private: No Submitted By: Torsten Wohlfarth (towo2099) Assigned to: Nobody/Anonymous (nobody) Summary: kvm_run: Cannot allocate memory Initial Comment: Since i testet kernel 2.6.28-rc2 and rc3, kvm quit running wit the following error: kvm -hda vdisk_xp.qcow -m 1024 -smp 2 -soundhw ac97 kvm_run: Cannot allocate memory kvm_run returned -12 It does not matter, if the gues is a linux or xp. kvm version is kvm-78 system is Linux Defiant 2.6.28-rc3-towo-1 #1 SMP PREEMPT Mon Nov 3 16:46:41 CET 2008 i686 GNU/Linux cpu is Intel Core2 Quad Q6700 @ 4096 KB cache flags( sse3 nx lm vmx ) the no-kvm-switches does not help Booting in kernel 2.6.27.4 let kvm running fine. -- Comment By: Avi Kivity (avik) Date: 2008-11-23 20:50 Message: Should be fixed in 2.6.28-rc6 -- Comment By: Torsten Wohlfarth (towo2099) Date: 2008-11-10 17:46 Message: Today, i have applyed your patch to linux-2.6.28-rc4 and kvm seem to run fine. I've testet a linux and a XP VM. -- Comment By: Glauber de Oliveira Costa (glommer) Date: 2008-11-08 02:37 Message: No, using that parameter won't work. I just got the fix for it today. It's not in any tree yet, but since you're using git, I'll assume you're confortable with applying a patch in your tree ;-) You can download it from http://glommer.net/0003-restart-search-at-beggining-of-vmalloc-address.patch -- Comment By: walt (w41ter) Date: 2008-11-07 23:07 Message: FWIW this seems to be a 32-bit-only problem for me. I track Linus.git and kvm-userspace.git in 32-bit and 64-bit linux installations on one machine, and the 64-bit kvm works perfectly. Only the 32-bit kvm has this error. Can I work around the problem with vmalloc=size? If yes, where do I use that vmalloc flag? Thanks. -- Comment By: Torsten Wohlfarth (towo2099) Date: 2008-11-03 23:13 Message: Yeah, there are many messages about vmalloc: http://rafb.net/p/4RvqBX81.html -- Comment By: Glauber de Oliveira Costa (glommer) Date: 2008-11-03 23:08 Message: check your dmesg in the host. If there's any message about vmalloc failing, so this is a known issue. I have a band aid patch that helps it, but we're still not sure what the proper fix is. I'm working on it right now. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2219447group_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
[ kvm-Bugs-2217430 ] Host crash in kvm:unsync_walk_fn with kvm-78
Bugs item #2217430, was opened at 2008-11-03 02:01 Message generated for change (Comment added) made by avik You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2217430group_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: libkvm Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Rousseau (johnrrousseau) Assigned to: Nobody/Anonymous (nobody) Summary: Host crash in kvm:unsync_walk_fn with kvm-78 Initial Comment: Built and installed kvm-78 today. Launched vista, ran several network and app tests on the guest and then walked away. The host Oops'ed sometime an hour or so later. Note that the last stable kvm version with this host/guest combo was kvm-75. Host: FC9 2.6.26.6-79.fc9.x86_64 Arch: x86_64 CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz Guest: Windows Vista Ultimate 64 Cmd: qemu-system-x86_64 -hda /home/jrr/vista-x86_64.img -m 2048M -net nic,vlan=0,macaddr=52:54:00:12:32:00 -net tap,vlan=0,ifname=tap0 -vga std -full-screen -smp 2 -soundhw all Nov 2 18:17:55 jrr-d830 kernel: BUG: unable to handle kernel NULL pointer dereference at 0051 Nov 2 18:17:55 jrr-d830 kernel: IP: [a0b68ab8] :kvm:unsync_walk_fn+0x4/0x17 Nov 2 18:17:55 jrr-d830 kernel: PGD dcde0067 PUD b6490067 PMD 0 Nov 2 18:17:55 jrr-d830 kernel: Oops: 0002 [1] SMP Nov 2 18:17:55 jrr-d830 kernel: CPU 1 Nov 2 18:17:55 jrr-d830 kernel: Modules linked in: tun kvm_intel kvm bridge fuse sunrpc ipt_REJECT nf_conntrack_ipv4 iptable_filter ip_tables ip6t_REJECT xt_tcpudp nf_conntrack_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables x_tables ipv6 cpufreq_ondemand acpi_cpufreq freq_table loop dm_multipath nvidia(P) snd_hda_intel sr_mod snd_seq_dummy cdrom snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device ata_generic snd_pcm_oss dcdbas pcspkr ata_piix snd_mixer_oss joydev i2c_i801 snd_pcm sg video snd_timer output firewire_ohci snd_page_alloc snd_hwdep firewire_core bay snd pata_acpi tg3 i2c_core wmi crc_itu_t yenta_socket soundcore ssb rsrc_nonstatic battery ac iTCO_wdt iTCO_vendor_support dm_snapshot dm_zero dm_mirror dm_log dm_mod ahci libata sd_mod scsi_mod ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd [last unloaded: microcode] Nov 2 18:17:55 jrr-d830 kernel: Pid: 5084, comm: qemu-system-x86 Tainted: P 2.6.26.6-79.fc9.x86_64 #1 Nov 2 18:17:55 jrr-d830 kernel: RIP: 0010:[a0b68ab8] [a0b68ab8] :kvm:unsync_walk_fn+0x4/0x17 Nov 2 18:17:55 jrr-d830 kernel: RSP: 0018:8100b646f978 EFLAGS: 00010202 Nov 2 18:17:55 jrr-d830 kernel: RAX: 00b3a1d8 RBX: RCX: 0005bc1c Nov 2 18:17:55 jrr-d830 kernel: RDX: e200 RSI: RDI: Nov 2 18:17:55 jrr-d830 kernel: RBP: 8100b646f9b8 R08: R09: 0040 Nov 2 18:17:55 jrr-d830 kernel: R10: R11: R12: 0008 Nov 2 18:17:55 jrr-d830 kernel: R13: 81002f02d840 R14: a0b68ab4 R15: 8100b647 Nov 2 18:17:55 jrr-d830 kernel: FS: 4246c950() GS:81011fc04880() knlGS: Nov 2 18:17:55 jrr-d830 kernel: CS: 0010 DS: 002b ES: 002b CR0: 8005003b Nov 2 18:17:55 jrr-d830 kernel: CR2: 0051 CR3: dcd0f000 CR4: 26e0 Nov 2 18:17:55 jrr-d830 kernel: DR0: DR1: DR2: Nov 2 18:17:55 jrr-d830 kernel: DR3: DR6: 0ff0 DR7: 0400 Nov 2 18:17:55 jrr-d830 kernel: Process qemu-system-x86 (pid: 5084, threadinfo 8100b646e000, task 81010d8dad40) Nov 2 18:17:55 jrr-d830 kernel: Stack: 8100b646f9b8 a0b689ce 81002f02d818 8100259545a0 Nov 2 18:17:55 jrr-d830 kernel: 8100b647 9b9aa063 0061 0003 Nov 2 18:17:55 jrr-d830 kernel: 8100b646fa18 a0b69ce5 8100b646fa48 01ff8108cc14 Nov 2 18:17:55 jrr-d830 kernel: Call Trace: Nov 2 18:17:55 jrr-d830 kernel: [a0b689ce] ? :kvm:mmu_parent_walk+0x97/0xd5 Nov 2 18:17:55 jrr-d830 kernel: [a0b69ce5] :kvm:set_spte+0x358/0x3e8 Nov 2 18:17:55 jrr-d830 kernel: [a0b6a32d] :kvm:mmu_set_spte+0xe1/0x2bd Nov 2 18:17:55 jrr-d830 kernel: [a0b6af01] :kvm:paging64_shadow_walk_entry+0x9e/0x1c0 Nov 2 18:17:55 jrr-d830 kernel: [8113c1a5] ? __up_read+0x7a/0x85 Nov 2 18:17:55 jrr-d830 kernel: [a0b681a4] :kvm:walk_shadow+0x8c/0xb1 Nov 2 18:17:55 jrr-d830 kernel: [a0b6c5d6] :kvm:paging64_page_fault+0x1a8/0x201 Nov 2 18:17:55 jrr-d830 kernel: [a0b69367] ? :kvm:mmu_free_roots+0x3f/0xf6 Nov 2 18:17:55 jrr-d830 kernel: [a0b6ae63] ? :kvm:paging64_shadow_walk_entry+0x0/0x1c0 Nov 2 18:17:55 jrr-d830 kernel: [a0b6b45a]
[ kvm-Bugs-2217430 ] Host crash in kvm:unsync_walk_fn with kvm-78
Bugs item #2217430, was opened at 2008-11-03 02:01 Message generated for change (Settings changed) made by avik You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2217430group_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: libkvm Group: None Status: Pending Resolution: None Priority: 5 Private: No Submitted By: John Rousseau (johnrrousseau) Assigned to: Nobody/Anonymous (nobody) Summary: Host crash in kvm:unsync_walk_fn with kvm-78 Initial Comment: Built and installed kvm-78 today. Launched vista, ran several network and app tests on the guest and then walked away. The host Oops'ed sometime an hour or so later. Note that the last stable kvm version with this host/guest combo was kvm-75. Host: FC9 2.6.26.6-79.fc9.x86_64 Arch: x86_64 CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz Guest: Windows Vista Ultimate 64 Cmd: qemu-system-x86_64 -hda /home/jrr/vista-x86_64.img -m 2048M -net nic,vlan=0,macaddr=52:54:00:12:32:00 -net tap,vlan=0,ifname=tap0 -vga std -full-screen -smp 2 -soundhw all Nov 2 18:17:55 jrr-d830 kernel: BUG: unable to handle kernel NULL pointer dereference at 0051 Nov 2 18:17:55 jrr-d830 kernel: IP: [a0b68ab8] :kvm:unsync_walk_fn+0x4/0x17 Nov 2 18:17:55 jrr-d830 kernel: PGD dcde0067 PUD b6490067 PMD 0 Nov 2 18:17:55 jrr-d830 kernel: Oops: 0002 [1] SMP Nov 2 18:17:55 jrr-d830 kernel: CPU 1 Nov 2 18:17:55 jrr-d830 kernel: Modules linked in: tun kvm_intel kvm bridge fuse sunrpc ipt_REJECT nf_conntrack_ipv4 iptable_filter ip_tables ip6t_REJECT xt_tcpudp nf_conntrack_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables x_tables ipv6 cpufreq_ondemand acpi_cpufreq freq_table loop dm_multipath nvidia(P) snd_hda_intel sr_mod snd_seq_dummy cdrom snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device ata_generic snd_pcm_oss dcdbas pcspkr ata_piix snd_mixer_oss joydev i2c_i801 snd_pcm sg video snd_timer output firewire_ohci snd_page_alloc snd_hwdep firewire_core bay snd pata_acpi tg3 i2c_core wmi crc_itu_t yenta_socket soundcore ssb rsrc_nonstatic battery ac iTCO_wdt iTCO_vendor_support dm_snapshot dm_zero dm_mirror dm_log dm_mod ahci libata sd_mod scsi_mod ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd [last unloaded: microcode] Nov 2 18:17:55 jrr-d830 kernel: Pid: 5084, comm: qemu-system-x86 Tainted: P 2.6.26.6-79.fc9.x86_64 #1 Nov 2 18:17:55 jrr-d830 kernel: RIP: 0010:[a0b68ab8] [a0b68ab8] :kvm:unsync_walk_fn+0x4/0x17 Nov 2 18:17:55 jrr-d830 kernel: RSP: 0018:8100b646f978 EFLAGS: 00010202 Nov 2 18:17:55 jrr-d830 kernel: RAX: 00b3a1d8 RBX: RCX: 0005bc1c Nov 2 18:17:55 jrr-d830 kernel: RDX: e200 RSI: RDI: Nov 2 18:17:55 jrr-d830 kernel: RBP: 8100b646f9b8 R08: R09: 0040 Nov 2 18:17:55 jrr-d830 kernel: R10: R11: R12: 0008 Nov 2 18:17:55 jrr-d830 kernel: R13: 81002f02d840 R14: a0b68ab4 R15: 8100b647 Nov 2 18:17:55 jrr-d830 kernel: FS: 4246c950() GS:81011fc04880() knlGS: Nov 2 18:17:55 jrr-d830 kernel: CS: 0010 DS: 002b ES: 002b CR0: 8005003b Nov 2 18:17:55 jrr-d830 kernel: CR2: 0051 CR3: dcd0f000 CR4: 26e0 Nov 2 18:17:55 jrr-d830 kernel: DR0: DR1: DR2: Nov 2 18:17:55 jrr-d830 kernel: DR3: DR6: 0ff0 DR7: 0400 Nov 2 18:17:55 jrr-d830 kernel: Process qemu-system-x86 (pid: 5084, threadinfo 8100b646e000, task 81010d8dad40) Nov 2 18:17:55 jrr-d830 kernel: Stack: 8100b646f9b8 a0b689ce 81002f02d818 8100259545a0 Nov 2 18:17:55 jrr-d830 kernel: 8100b647 9b9aa063 0061 0003 Nov 2 18:17:55 jrr-d830 kernel: 8100b646fa18 a0b69ce5 8100b646fa48 01ff8108cc14 Nov 2 18:17:55 jrr-d830 kernel: Call Trace: Nov 2 18:17:55 jrr-d830 kernel: [a0b689ce] ? :kvm:mmu_parent_walk+0x97/0xd5 Nov 2 18:17:55 jrr-d830 kernel: [a0b69ce5] :kvm:set_spte+0x358/0x3e8 Nov 2 18:17:55 jrr-d830 kernel: [a0b6a32d] :kvm:mmu_set_spte+0xe1/0x2bd Nov 2 18:17:55 jrr-d830 kernel: [a0b6af01] :kvm:paging64_shadow_walk_entry+0x9e/0x1c0 Nov 2 18:17:55 jrr-d830 kernel: [8113c1a5] ? __up_read+0x7a/0x85 Nov 2 18:17:55 jrr-d830 kernel: [a0b681a4] :kvm:walk_shadow+0x8c/0xb1 Nov 2 18:17:55 jrr-d830 kernel: [a0b6c5d6] :kvm:paging64_page_fault+0x1a8/0x201 Nov 2 18:17:55 jrr-d830 kernel: [a0b69367] ? :kvm:mmu_free_roots+0x3f/0xf6 Nov 2 18:17:55 jrr-d830 kernel: [a0b6ae63] ? :kvm:paging64_shadow_walk_entry+0x0/0x1c0 Nov 2 18:17:55 jrr-d830 kernel: [a0b6b45a]
[ kvm-Bugs-2215532 ] SMP IA32e RHEL5.1 guest can not boot up
Bugs item #2215532, was opened at 2008-11-02 07:58 Message generated for change (Comment added) made by avik You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2215532group_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: Open Resolution: None Priority: 5 Private: No Submitted By: Jiajun Xu (jiajun) Assigned to: Nobody/Anonymous (nobody) Summary: SMP IA32e RHEL5.1 guest can not boot up Initial Comment: Against kernel.git:20d09323d7b91819e35194773ea000e9d79badd2 user-space.git: ccabb53f1a84f11896c840391f7ade3756214086, SMP IA32e RHEL5/RHEL4 Guest can not boot up. UP IA32e Guest can boot up well. The issue disappeare if nmi_watchdog=0 in guest kernel parameter. -- Comment By: Avi Kivity (avik) Date: 2008-11-23 21:12 Message: Should be fixed now. Please retest. -- Comment By: Jiajun Xu (jiajun) Date: 2008-11-04 11:21 Message: File Added: config-2.6.18-53.el5 -- Comment By: Jiajun Xu (jiajun) Date: 2008-11-04 11:20 Message: Please see attachement, I uploaded all the call trace messages. I also attched my RHEL5.1 config. The kernel version is 2.6.18-53. File Added: call_trace -- Comment By: Jan Kiszka (kiszka) Date: 2008-11-04 10:08 Message: Please use a (virtual) serial console or a netconsole to catch the guest output. The screenshot only tells the tail of the report. Is there a chance to get my hands on some image to reproduce? I don't have that RHEL version at hand. Which .config does RHEL use? Which kernel version? Any special patches that may make a difference? -- Comment By: Jiajun Xu (jiajun) Date: 2008-11-04 09:34 Message: You can find snapshot of guest call trace in attachement. Guest call trace after loading kernel and start udev. There are a lot of messages printed on guest console, most are related to NMI. There is no any error message on host console. -- Comment By: Jan Kiszka (kiszka) Date: 2008-11-02 11:31 Message: Could you be more specific: Where does it hang? What does the guest kernel console say? Also, what is the nmi_watchdog default otherwise? And is there any message in the host kernel's log? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2215532group_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
[ kvm-Bugs-2215532 ] SMP IA32e RHEL5.1 guest can not boot up
Bugs item #2215532, was opened at 2008-11-02 07:58 Message generated for change (Settings changed) made by avik You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2215532group_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: Pending Resolution: None Priority: 5 Private: No Submitted By: Jiajun Xu (jiajun) Assigned to: Nobody/Anonymous (nobody) Summary: SMP IA32e RHEL5.1 guest can not boot up Initial Comment: Against kernel.git:20d09323d7b91819e35194773ea000e9d79badd2 user-space.git: ccabb53f1a84f11896c840391f7ade3756214086, SMP IA32e RHEL5/RHEL4 Guest can not boot up. UP IA32e Guest can boot up well. The issue disappeare if nmi_watchdog=0 in guest kernel parameter. -- Comment By: Avi Kivity (avik) Date: 2008-11-23 21:12 Message: Should be fixed now. Please retest. -- Comment By: Jiajun Xu (jiajun) Date: 2008-11-04 11:21 Message: File Added: config-2.6.18-53.el5 -- Comment By: Jiajun Xu (jiajun) Date: 2008-11-04 11:20 Message: Please see attachement, I uploaded all the call trace messages. I also attched my RHEL5.1 config. The kernel version is 2.6.18-53. File Added: call_trace -- Comment By: Jan Kiszka (kiszka) Date: 2008-11-04 10:08 Message: Please use a (virtual) serial console or a netconsole to catch the guest output. The screenshot only tells the tail of the report. Is there a chance to get my hands on some image to reproduce? I don't have that RHEL version at hand. Which .config does RHEL use? Which kernel version? Any special patches that may make a difference? -- Comment By: Jiajun Xu (jiajun) Date: 2008-11-04 09:34 Message: You can find snapshot of guest call trace in attachement. Guest call trace after loading kernel and start udev. There are a lot of messages printed on guest console, most are related to NMI. There is no any error message on host console. -- Comment By: Jan Kiszka (kiszka) Date: 2008-11-02 11:31 Message: Could you be more specific: Where does it hang? What does the guest kernel console say? Also, what is the nmi_watchdog default otherwise? And is there any message in the host kernel's log? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2215532group_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
[ kvm-Bugs-2087432 ] Full-screen conflict with compiz
Bugs item #2087432, was opened at 2008-09-01 22:56 Message generated for change (Comment added) made by avik You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2087432group_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: Interface (example) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: fabiengb (fabiengb) Assigned to: Nobody/Anonymous (nobody) Summary: Full-screen conflict with compiz Initial Comment: Configuration CPU : Intel Core 2 Duo E6850 OS : Ubuntu 8.04 Kernel : 2.6.24-19-generic Compiz version details : Checking for Xgl: not present. Detected PCI ID for VGA: 01:00.0 0300: 10de:0402 (rev a1) (prog-if 00 [VGA controller]) Checking for texture_from_pixmap: present. Checking for non power of two support: present. Checking for Composite extension: present. Comparing resolution (1280x1024) to maximum 3D texture size (8192): Passed. Checking for nVidia: present. Checking for FBConfig: present. Checking for Xgl: not present. compiz 0.7.4 Bug reproduction : - Active compiz specials effects - Run virtual machine - Set vm resolution to the same resolution of your host - Switch to full-screen mode - BUG : - KVM switch quickly to full-screen mode, and then, switch back to window mode - It becomes very difficult to control vm mouse (cursor movement very weird) - If vm resolution switched back to a lower resolution, host mouse pointer is clipped to the vm window (!) - Vm must be shut down to unclip mouse pointer No problem when compiz deactivated. -- Comment By: Avi Kivity (avik) Date: 2008-11-23 21:16 Message: This is a compiz bug. The window manager should be transparent to applications. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2087432group_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
[ kvm-Bugs-2087432 ] Full-screen conflict with compiz
Bugs item #2087432, was opened at 2008-09-01 22:56 Message generated for change (Settings changed) made by avik You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2087432group_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: Interface (example) Group: None Status: Closed Resolution: Rejected Priority: 5 Private: No Submitted By: fabiengb (fabiengb) Assigned to: Nobody/Anonymous (nobody) Summary: Full-screen conflict with compiz Initial Comment: Configuration CPU : Intel Core 2 Duo E6850 OS : Ubuntu 8.04 Kernel : 2.6.24-19-generic Compiz version details : Checking for Xgl: not present. Detected PCI ID for VGA: 01:00.0 0300: 10de:0402 (rev a1) (prog-if 00 [VGA controller]) Checking for texture_from_pixmap: present. Checking for non power of two support: present. Checking for Composite extension: present. Comparing resolution (1280x1024) to maximum 3D texture size (8192): Passed. Checking for nVidia: present. Checking for FBConfig: present. Checking for Xgl: not present. compiz 0.7.4 Bug reproduction : - Active compiz specials effects - Run virtual machine - Set vm resolution to the same resolution of your host - Switch to full-screen mode - BUG : - KVM switch quickly to full-screen mode, and then, switch back to window mode - It becomes very difficult to control vm mouse (cursor movement very weird) - If vm resolution switched back to a lower resolution, host mouse pointer is clipped to the vm window (!) - Vm must be shut down to unclip mouse pointer No problem when compiz deactivated. -- Comment By: Avi Kivity (avik) Date: 2008-11-23 21:16 Message: This is a compiz bug. The window manager should be transparent to applications. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2087432group_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
[ kvm-Bugs-1971512 ] failure to migrate guests with more than 4GB of RAM
Bugs item #1971512, was opened at 2008-05-25 00:45 Message generated for change (Comment added) made by avik You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=1971512group_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: Open Resolution: None Priority: 3 Private: No Submitted By: Marcelo Tosatti (mtosatti) Assigned to: Anthony Liguori (aliguori) Summary: failure to migrate guests with more than 4GB of RAM Initial Comment: The migration code assumes linear phys_ram_base: [EMAIL PROTECTED] kvm-userspace.tip]# qemu/x86_64-softmmu/qemu-system-x86_64 -hda /root/images/marcelo5-io-test.img -m 4097 -net nic,model=rtl8139 -net tap,script=/root/iptables/ifup -incoming tcp://0:/ audit_log_user_command(): Connection refused audit_log_user_command(): Connection refused migration: memory size mismatch: recv 22032384 mine 4316999680 migrate_incoming_fd failed (rc=232) -- Comment By: Avi Kivity (avik) Date: 2008-11-23 21:18 Message: Fixed by new migration protocol from upstream qemu. -- Comment By: Anthony Liguori (aliguori) Date: 2008-05-26 19:48 Message: Logged In: YES user_id=120449 Originator: NO The issue isn't actually the use of phys_ram_base. In the case of migration, we don't care about the layout of physical memory. We just want to look at memory from phys_ram_base .. ram_size. The problem is that we encode physical addresses in the migration protocol as 32-bit values. We'll need to figure out a way to switch to encoding PFNs while maintaining backwards compatibility with the current code. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=1971512group_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
[ kvm-Bugs-1971512 ] failure to migrate guests with more than 4GB of RAM
Bugs item #1971512, was opened at 2008-05-25 00:45 Message generated for change (Settings changed) made by avik You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=1971512group_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: Pending Resolution: Fixed Priority: 3 Private: No Submitted By: Marcelo Tosatti (mtosatti) Assigned to: Anthony Liguori (aliguori) Summary: failure to migrate guests with more than 4GB of RAM Initial Comment: The migration code assumes linear phys_ram_base: [EMAIL PROTECTED] kvm-userspace.tip]# qemu/x86_64-softmmu/qemu-system-x86_64 -hda /root/images/marcelo5-io-test.img -m 4097 -net nic,model=rtl8139 -net tap,script=/root/iptables/ifup -incoming tcp://0:/ audit_log_user_command(): Connection refused audit_log_user_command(): Connection refused migration: memory size mismatch: recv 22032384 mine 4316999680 migrate_incoming_fd failed (rc=232) -- Comment By: Avi Kivity (avik) Date: 2008-11-23 21:18 Message: Fixed by new migration protocol from upstream qemu. -- Comment By: Anthony Liguori (aliguori) Date: 2008-05-26 19:48 Message: Logged In: YES user_id=120449 Originator: NO The issue isn't actually the use of phys_ram_base. In the case of migration, we don't care about the layout of physical memory. We just want to look at memory from phys_ram_base .. ram_size. The problem is that we encode physical addresses in the migration protocol as 32-bit values. We'll need to figure out a way to switch to encoding PFNs while maintaining backwards compatibility with the current code. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=1971512group_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
[ kvm-Bugs-1978070 ] Launching KVM freezes the system
Bugs item #1978070, was opened at 2008-05-29 19:59 Message generated for change (Comment added) made by avik You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=1978070group_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: amd Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Edo Monticelli (emonticel) Assigned to: Nobody/Anonymous (nobody) Summary: Launching KVM freezes the system Initial Comment: Every time kvm is launched, the qemu window opens. Then, after a few seconds, the whole system(Ubuntu-8.04) freezes or reboot. Tried the ubuntu repository version(kvm-62) and the kvm-69 version, whitout any significant difference. Tried different guests, Ubuntu(32/64 bit), Gentoo(32), Windows XP, but none is alive for more than 5-6 seconds. I have a Dell latitude D531 laptop with Ubuntu-8.04 (32bit i686 version) and the Ubuntu standard kernel: Linux edos 2.6.24-17-generic #1 SMP Thu May 29 00:18:56 CEST 2008 i686 GNU/Linux AMD Turion CPU: processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 104 model name : AMD Turion(tm) 64 X2 Mobile Technology TL-60 processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 104 model name : AMD Turion(tm) 64 X2 Mobile Technology TL-60 launching with: qemu-system-x86_64 -hda /home/Debian.img tried the options -no-kvm-irqchip or -no-kvm-pit but no effects. with -no-kvm it works. I compiled with -DDEBUG option and attached the resluting file. -- Comment By: Avi Kivity (avik) Date: 2008-11-23 21:20 Message: Does this still happen with kvm-78? Please try the latest BIOS update from the box vendor. -- Comment By: Edo Monticelli (emonticel) Date: 2008-06-06 16:28 Message: Logged In: YES user_id=2102037 Originator: YES No, it appeans ANYTIME I try to launch kvm. Tried various images. Also tried 2.6.25.4 kernel from kernel.org without success. I can follow any suggestion to get more debug output... -- Comment By: Anthony Liguori (aliguori) Date: 2008-06-06 00:55 Message: Logged In: YES user_id=120449 Originator: NO Does this happen after suspending? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=1978070group_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
[ kvm-Bugs-1978070 ] Launching KVM freezes the system
Bugs item #1978070, was opened at 2008-05-29 19:59 Message generated for change (Settings changed) made by avik You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=1978070group_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: amd Group: None Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Edo Monticelli (emonticel) Assigned to: Nobody/Anonymous (nobody) Summary: Launching KVM freezes the system Initial Comment: Every time kvm is launched, the qemu window opens. Then, after a few seconds, the whole system(Ubuntu-8.04) freezes or reboot. Tried the ubuntu repository version(kvm-62) and the kvm-69 version, whitout any significant difference. Tried different guests, Ubuntu(32/64 bit), Gentoo(32), Windows XP, but none is alive for more than 5-6 seconds. I have a Dell latitude D531 laptop with Ubuntu-8.04 (32bit i686 version) and the Ubuntu standard kernel: Linux edos 2.6.24-17-generic #1 SMP Thu May 29 00:18:56 CEST 2008 i686 GNU/Linux AMD Turion CPU: processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 104 model name : AMD Turion(tm) 64 X2 Mobile Technology TL-60 processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 104 model name : AMD Turion(tm) 64 X2 Mobile Technology TL-60 launching with: qemu-system-x86_64 -hda /home/Debian.img tried the options -no-kvm-irqchip or -no-kvm-pit but no effects. with -no-kvm it works. I compiled with -DDEBUG option and attached the resluting file. -- Comment By: Avi Kivity (avik) Date: 2008-11-23 21:20 Message: Does this still happen with kvm-78? Please try the latest BIOS update from the box vendor. -- Comment By: Edo Monticelli (emonticel) Date: 2008-06-06 16:28 Message: Logged In: YES user_id=2102037 Originator: YES No, it appeans ANYTIME I try to launch kvm. Tried various images. Also tried 2.6.25.4 kernel from kernel.org without success. I can follow any suggestion to get more debug output... -- Comment By: Anthony Liguori (aliguori) Date: 2008-06-06 00:55 Message: Logged In: YES user_id=120449 Originator: NO Does this happen after suspending? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=1978070group_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
[ kvm-Bugs-2327497 ] NFS copy makes guest network unstable
Bugs item #2327497, was opened at 2008-11-22 16:53 Message generated for change (Comment added) made by cova You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2327497group_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: Pending Resolution: None Priority: 5 Private: No Submitted By: Jiajun Xu (jiajun) Assigned to: Nobody/Anonymous (nobody) Summary: NFS copy makes guest network unstable Initial Comment: The NFS network of KVM guest is very unstable. When we copy a 600M file to the guest by NFS mount. The guest's network will down after finishing at about 500M size. Then, guest's network is down. Host also can not use ping or scp. And sometimes, host also complains: ping: sendmsg: No buffer space available. I see memory by 'free', there is only 69MB free (While totally 8GB on the machine!). Using scp to copy file can not reproduce it. This issue is very easy to be reproduced (50%). Reproduce steps: 1. Create a guest and config NFS sharing folder on it 2. Mount the nfs folder to local folder --- /media 3. cp xxx /media 4. After some time, guest network is down -- Comment By: Fabio Coatti (cova) Date: 2008-11-23 21:15 Message: I can't find out easily wich kvm version worked (nor be sure that is kvm executable itself to have issues), as the subsystems involved are quite a lot an some time passet prior to spot the problem. (kvm itself, network birdge, host kernel may be involved, of course). Now I'm trying to find out the combination that worked, but at the same time I'll be willing to do some tests to discover (on the actual non working setup) some hints, as the bisection can be a very daunting task. (this issue has been noticed after several upgrades). -- Comment By: Avi Kivity (avik) Date: 2008-11-23 19:40 Message: Is this a regression, or a new test? It it is a regression, what was the last version that worked? -- Comment By: Fabio Coatti (cova) Date: 2008-11-23 16:12 Message: I can confirm a similar behaviour: a kvm machines gets large amounts of data via http protocol and saves that files over NFS. (file sizes are in the range of 4-20 MB approx and the machine downloads several of that files.) After some time (I don't have a precise figure, but some hundreds of MB) the guest nework goes down. No answers even to ping coming from outside. the guest uses virtio network drivers (as normal drivers are way too slow) host machine: 64 bit AMD dual quad core 16GB, tried with several kernels ranging from 2.6.27.4 to 2.6.25.19 guest: 32 bit kvm machines (tried 76/77/78 ). both UP and SMP configuration. kernels: same as host machine network setup: bridged network with br0 device on host machine. We are using 2 vlans for guest and we have tried all the configuration (single tap and vlans resolved on guest side,then two tap so two interfaces on guest machine and so on) without any improvement. I can exclude MTU issues, as we have seen that and solved, this issue is completely different. At some point, sniffing traffic on host interfaces we are able to see only ARP requests coming from guest, nothing more. I understand that data is in no way complete, but I'm willing to do any debug if someone gives me any hint on how to do so correctly. Thanks. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2327497group_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
[ kvm-Bugs-2327497 ] NFS copy makes guest network unstable
Bugs item #2327497, was opened at 2008-11-22 17:53 Message generated for change (Comment added) made by avik You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2327497group_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: Pending Resolution: None Priority: 5 Private: No Submitted By: Jiajun Xu (jiajun) Assigned to: Nobody/Anonymous (nobody) Summary: NFS copy makes guest network unstable Initial Comment: The NFS network of KVM guest is very unstable. When we copy a 600M file to the guest by NFS mount. The guest's network will down after finishing at about 500M size. Then, guest's network is down. Host also can not use ping or scp. And sometimes, host also complains: ping: sendmsg: No buffer space available. I see memory by 'free', there is only 69MB free (While totally 8GB on the machine!). Using scp to copy file can not reproduce it. This issue is very easy to be reproduced (50%). Reproduce steps: 1. Create a guest and config NFS sharing folder on it 2. Mount the nfs folder to local folder --- /media 3. cp xxx /media 4. After some time, guest network is down -- Comment By: Avi Kivity (avik) Date: 2008-11-23 23:13 Message: It's almost certainly a problem with the qemu process, not the bridge. -- Comment By: Fabio Coatti (cova) Date: 2008-11-23 22:15 Message: I can't find out easily wich kvm version worked (nor be sure that is kvm executable itself to have issues), as the subsystems involved are quite a lot an some time passet prior to spot the problem. (kvm itself, network birdge, host kernel may be involved, of course). Now I'm trying to find out the combination that worked, but at the same time I'll be willing to do some tests to discover (on the actual non working setup) some hints, as the bisection can be a very daunting task. (this issue has been noticed after several upgrades). -- Comment By: Avi Kivity (avik) Date: 2008-11-23 20:40 Message: Is this a regression, or a new test? It it is a regression, what was the last version that worked? -- Comment By: Fabio Coatti (cova) Date: 2008-11-23 17:12 Message: I can confirm a similar behaviour: a kvm machines gets large amounts of data via http protocol and saves that files over NFS. (file sizes are in the range of 4-20 MB approx and the machine downloads several of that files.) After some time (I don't have a precise figure, but some hundreds of MB) the guest nework goes down. No answers even to ping coming from outside. the guest uses virtio network drivers (as normal drivers are way too slow) host machine: 64 bit AMD dual quad core 16GB, tried with several kernels ranging from 2.6.27.4 to 2.6.25.19 guest: 32 bit kvm machines (tried 76/77/78 ). both UP and SMP configuration. kernels: same as host machine network setup: bridged network with br0 device on host machine. We are using 2 vlans for guest and we have tried all the configuration (single tap and vlans resolved on guest side,then two tap so two interfaces on guest machine and so on) without any improvement. I can exclude MTU issues, as we have seen that and solved, this issue is completely different. At some point, sniffing traffic on host interfaces we are able to see only ARP requests coming from guest, nothing more. I understand that data is in no way complete, but I'm willing to do any debug if someone gives me any hint on how to do so correctly. Thanks. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2327497group_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: [PATCH 05/11] KVM: Add fields for MSI device assignment
On Sunday 23 November 2008 18:10:47 Avi Kivity wrote:
Sheng Yang wrote:
Prepared for kvm_arch_assigned_device_msi_dispatch().
@@ -507,10 +507,17 @@ struct kvm_assigned_irq {
__u32 guest_irq;
__u32 flags;
union {
+ struct {
+ __u32 addr_lo;
+ __u32 addr_hi;
__u64 addr;
?
Here I followed the spec that distinguish the Message Address and Message
Upper address. And the native Linux structure:
struct msi_msg {
u32 address_lo; /* low 32 bits of msi message address */
u32 address_hi; /* high 32 bits of msi message address */
u32 data; /* 16 bits of msi message data */
};
For now, we needn't care about address_hi. I can only see address_hi used in
hypertransport part... So I think keep it independence here is OK.
(In fact, PCI spec defined message data length is u64, but as you see, now
msi_msg for whole Linux only have u32...)
--
regards
Yang, Sheng
+ __u32 data;
@@ -307,8 +308,11 @@ struct kvm_assigned_dev_kernel {
int host_devfn;
int host_irq;
int guest_irq;
+ struct msi_msg guest_msi;
#define KVM_ASSIGNED_DEV_GUEST_INTX(1 0)
+#define KVM_ASSIGNED_DEV_GUEST_MSI (1 1)
#define KVM_ASSIGNED_DEV_HOST_INTX (1 8)
+#define KVM_ASSIGNED_DEV_HOST_MSI (1 9)
Okay, I see the reason for non sequential assignment.
--
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 09/11] KVM: Add assigned_device_msi_dispatch()
On Sunday 23 November 2008 18:22:47 Avi Kivity wrote:
Sheng Yang wrote:
The function is used to dispatch MSI to lapic according to MSI message
address and message data.
+
+ deliver_bitmask = kvm_ioapic_get_delivery_bitmask(ioapic,
+ dest_id, dest_mode);
+ switch (delivery_mode) {
+ case MSI_DATA_DELIVERY_LOWPRI:
+ vcpu = kvm_get_lowest_prio_vcpu(ioapic-kvm, vector,
+ deliver_bitmask);
+ if (vcpu != NULL)
+ kvm_apic_set_irq(vcpu, vector, trig_mode);
+ else
+ printk(KERN_INFO kvm: null lowest priority vcpu!\n);
+ break;
+ case MSI_DATA_DELIVERY_FIXED:
+ for (vcpu_id = 0; deliver_bitmask != 0; vcpu_id++) {
+ if (!(deliver_bitmask (1 vcpu_id)))
+ continue;
+ deliver_bitmask = ~(1 vcpu_id);
+ vcpu = ioapic-kvm-vcpus[vcpu_id];
+ if (vcpu)
+ kvm_apic_set_irq(vcpu, vector, trig_mode);
+ }
+ break;
+ default:
This duplicates the ioapic code. That's fine for now, but eventually
we'll want to refactor this.
Sure. Put on my todo list...
--
regards
Yang, Sheng
--
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 4/9] KVM: Clean up assigned_device_update_irq
Signed-off-by: Sheng Yang [EMAIL PROTECTED]
---
virt/kvm/kvm_main.c | 10 --
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 638de47..2089f8b 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -180,11 +180,11 @@ static int assigned_device_update_intx(struct kvm *kvm,
struct kvm_assigned_dev_kernel *adev,
struct kvm_assigned_irq *airq)
{
- if (adev-irq_requested_type KVM_ASSIGNED_DEV_GUEST_INTX) {
- adev-guest_irq = airq-guest_irq;
- adev-ack_notifier.gsi = airq-guest_irq;
+ adev-guest_irq = airq-guest_irq;
+ adev-ack_notifier.gsi = airq-guest_irq;
+
+ if (adev-irq_requested_type KVM_ASSIGNED_DEV_HOST_INTX)
return 0;
- }
if (irqchip_in_kernel(kvm)) {
if (!capable(CAP_SYS_RAWIO))
@@ -194,8 +194,6 @@ static int assigned_device_update_intx(struct kvm *kvm,
adev-host_irq = airq-host_irq;
else
adev-host_irq = adev-dev-irq;
- adev-guest_irq = airq-guest_irq;
- adev-ack_notifier.gsi = airq-guest_irq;
/* Even though this is PCI, we don't want to use shared
* interrupts. Sharing host devices with guest-assigned devices
--
1.5.4.5
--
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 1/9] KVM: Move ack notifier register and IRQ sourcd ID request
Distinguish common part for device assignment and INTx part, perparing for
refactor later.
Signed-off-by: Sheng Yang [EMAIL PROTECTED]
---
virt/kvm/kvm_main.c | 30 +++---
1 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 4727c08..8966fd1 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -192,16 +192,31 @@ static int kvm_vm_ioctl_assign_irq(struct kvm *kvm,
return -EINVAL;
}
- if (match-irq_requested) {
+ if (!match-irq_requested) {
+ INIT_WORK(match-interrupt_work,
+ kvm_assigned_dev_interrupt_work_handler);
+ if (irqchip_in_kernel(kvm)) {
+ /* Register ack nofitier */
+ match-ack_notifier.gsi = -1;
+ match-ack_notifier.irq_acked =
+ kvm_assigned_dev_ack_irq;
+ kvm_register_irq_ack_notifier(kvm,
+ match-ack_notifier);
+
+ /* Request IRQ source ID */
+ r = kvm_request_irq_source_id(kvm);
+ if (r 0)
+ goto out_release;
+ else
+ match-irq_source_id = r;
+ }
+ } else {
match-guest_irq = assigned_irq-guest_irq;
match-ack_notifier.gsi = assigned_irq-guest_irq;
mutex_unlock(kvm-lock);
return 0;
}
- INIT_WORK(match-interrupt_work,
- kvm_assigned_dev_interrupt_work_handler);
-
if (irqchip_in_kernel(kvm)) {
if (!capable(CAP_SYS_RAWIO)) {
r = -EPERM;
@@ -214,13 +229,6 @@ static int kvm_vm_ioctl_assign_irq(struct kvm *kvm,
match-host_irq = match-dev-irq;
match-guest_irq = assigned_irq-guest_irq;
match-ack_notifier.gsi = assigned_irq-guest_irq;
- match-ack_notifier.irq_acked = kvm_assigned_dev_ack_irq;
- kvm_register_irq_ack_notifier(kvm, match-ack_notifier);
- r = kvm_request_irq_source_id(kvm);
- if (r 0)
- goto out_release;
- else
- match-irq_source_id = r;
/* Even though this is PCI, we don't want to use shared
* interrupts. Sharing host devices with guest-assigned devices
--
1.5.4.5
--
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/9][v6] Enable MSI for KVM
Hi MSI patchset v6 is coming... v5-v6 Addressed all comments from Avi on v5. I also set msi2intx=0 in non-x86 architecture machines. And the TODO list after this patchset: 1. A independence IOCTL to deliver MSI message data/address and related info, so that kvm_set_irq() can deliver MSI message directly. 2. Merge MSI parsing process with IOAPIC. Also speed it up with bit ops. 3. Separate lock for IOAPIC, maybe also LAPIC. Thanks! -- regards Yang, Sheng -- 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 7/9] KVM: Add assigned_device_msi_dispatch()
The function is used to dispatch MSI to lapic according to MSI message
address and message data.
Signed-off-by: Sheng Yang [EMAIL PROTECTED]
---
virt/kvm/kvm_main.c | 55 +++
1 files changed, 55 insertions(+), 0 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 2089f8b..228c1d1 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -47,6 +47,10 @@
#include asm/uaccess.h
#include asm/pgtable.h
+#ifdef CONFIG_X86
+#include asm/msidef.h
+#endif
+
#ifdef KVM_COALESCED_MMIO_PAGE_OFFSET
#include coalesced_mmio.h
#endif
@@ -78,6 +82,57 @@ static long kvm_vcpu_ioctl(struct file *file, unsigned int
ioctl,
bool kvm_rebooting;
#ifdef KVM_CAP_DEVICE_ASSIGNMENT
+
+#ifdef CONFIG_X86
+static void assigned_device_msi_dispatch(struct kvm_assigned_dev_kernel *dev)
+{
+ int vcpu_id;
+ struct kvm_vcpu *vcpu;
+ struct kvm_ioapic *ioapic = ioapic_irqchip(dev-kvm);
+ int dest_id = (dev-guest_msi.address_lo MSI_ADDR_DEST_ID_MASK)
+MSI_ADDR_DEST_ID_SHIFT;
+ int vector = (dev-guest_msi.data MSI_DATA_VECTOR_MASK)
+MSI_DATA_VECTOR_SHIFT;
+ int dest_mode = test_bit(MSI_ADDR_DEST_MODE_SHIFT,
+ (unsigned long *)dev-guest_msi.address_lo);
+ int trig_mode = test_bit(MSI_DATA_TRIGGER_SHIFT,
+ (unsigned long *)dev-guest_msi.data);
+ int delivery_mode = test_bit(MSI_DATA_DELIVERY_MODE_SHIFT,
+ (unsigned long *)dev-guest_msi.data);
+ u32 deliver_bitmask;
+
+ BUG_ON(!ioapic);
+
+ deliver_bitmask = kvm_ioapic_get_delivery_bitmask(ioapic,
+ dest_id, dest_mode);
+ /* IOAPIC delivery mode value is the same as MSI here */
+ switch (delivery_mode) {
+ case IOAPIC_LOWEST_PRIORITY:
+ vcpu = kvm_get_lowest_prio_vcpu(ioapic-kvm, vector,
+ deliver_bitmask);
+ if (vcpu != NULL)
+ kvm_apic_set_irq(vcpu, vector, trig_mode);
+ else
+ printk(KERN_INFO kvm: null lowest priority vcpu!\n);
+ break;
+ case IOAPIC_FIXED:
+ for (vcpu_id = 0; deliver_bitmask != 0; vcpu_id++) {
+ if (!(deliver_bitmask (1 vcpu_id)))
+ continue;
+ deliver_bitmask = ~(1 vcpu_id);
+ vcpu = ioapic-kvm-vcpus[vcpu_id];
+ if (vcpu)
+ kvm_apic_set_irq(vcpu, vector, trig_mode);
+ }
+ break;
+ default:
+ printk(KERN_INFO kvm: unsupported MSI delivery mode\n);
+ }
+}
+#else
+static void assigned_device_msi_dispatch(struct kvm_assigned_dev_kernel *dev)
{}
+#endif
+
static struct kvm_assigned_dev_kernel *kvm_find_assigned_dev(struct list_head
*head,
int assigned_dev_id)
{
--
1.5.4.5
--
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 6/9] KVM: Export ioapic_get_delivery_bitmask
It would be used for MSI in device assignment, for MSI dispatch.
Signed-off-by: Sheng Yang [EMAIL PROTECTED]
---
virt/kvm/ioapic.c |7 ---
virt/kvm/ioapic.h |2 ++
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c
index c8f939c..23b81cf 100644
--- a/virt/kvm/ioapic.c
+++ b/virt/kvm/ioapic.c
@@ -153,8 +153,8 @@ static void ioapic_inj_nmi(struct kvm_vcpu *vcpu)
kvm_vcpu_kick(vcpu);
}
-static u32 ioapic_get_delivery_bitmask(struct kvm_ioapic *ioapic, u8 dest,
- u8 dest_mode)
+u32 kvm_ioapic_get_delivery_bitmask(struct kvm_ioapic *ioapic, u8 dest,
+ u8 dest_mode)
{
u32 mask = 0;
int i;
@@ -208,7 +208,8 @@ static int ioapic_deliver(struct kvm_ioapic *ioapic, int
irq)
vector=%x trig_mode=%x\n,
dest, dest_mode, delivery_mode, vector, trig_mode);
- deliver_bitmask = ioapic_get_delivery_bitmask(ioapic, dest, dest_mode);
+ deliver_bitmask = kvm_ioapic_get_delivery_bitmask(ioapic, dest,
+ dest_mode);
if (!deliver_bitmask) {
ioapic_debug(no target on destination\n);
return 0;
diff --git a/virt/kvm/ioapic.h b/virt/kvm/ioapic.h
index cd7ae76..49c9581 100644
--- a/virt/kvm/ioapic.h
+++ b/virt/kvm/ioapic.h
@@ -85,5 +85,7 @@ void kvm_ioapic_update_eoi(struct kvm *kvm, int vector, int
trigger_mode);
int kvm_ioapic_init(struct kvm *kvm);
void kvm_ioapic_set_irq(struct kvm_ioapic *ioapic, int irq, int level);
void kvm_ioapic_reset(struct kvm_ioapic *ioapic);
+u32 kvm_ioapic_get_delivery_bitmask(struct kvm_ioapic *ioapic, u8 dest,
+ u8 dest_mode);
#endif
--
1.5.4.5
--
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 3/9] KVM: Replace irq_requested with more generic irq_requested_type
Separate guest irq type and host irq type, for we can support guest using INTx
with host using MSI (but not opposite combination).
Signed-off-by: Sheng Yang [EMAIL PROTECTED]
---
include/linux/kvm_host.h |4 +++-
virt/kvm/kvm_main.c |9 +
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 3a0fb77..c3d4b96 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -307,7 +307,9 @@ struct kvm_assigned_dev_kernel {
int host_devfn;
int host_irq;
int guest_irq;
- int irq_requested;
+#define KVM_ASSIGNED_DEV_GUEST_INTX(1 0)
+#define KVM_ASSIGNED_DEV_HOST_INTX (1 8)
+ unsigned long irq_requested_type;
int irq_source_id;
struct pci_dev *dev;
struct kvm *kvm;
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index ef2f03c..638de47 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -140,7 +140,7 @@ static void kvm_free_assigned_device(struct kvm *kvm,
struct kvm_assigned_dev_kernel
*assigned_dev)
{
- if (irqchip_in_kernel(kvm) assigned_dev-irq_requested)
+ if (irqchip_in_kernel(kvm) assigned_dev-irq_requested_type)
free_irq(assigned_dev-host_irq, (void *)assigned_dev);
kvm_unregister_irq_ack_notifier(assigned_dev-ack_notifier);
@@ -180,7 +180,7 @@ static int assigned_device_update_intx(struct kvm *kvm,
struct kvm_assigned_dev_kernel *adev,
struct kvm_assigned_irq *airq)
{
- if (adev-irq_requested) {
+ if (adev-irq_requested_type KVM_ASSIGNED_DEV_GUEST_INTX) {
adev-guest_irq = airq-guest_irq;
adev-ack_notifier.gsi = airq-guest_irq;
return 0;
@@ -207,7 +207,8 @@ static int assigned_device_update_intx(struct kvm *kvm,
return -EIO;
}
- adev-irq_requested = true;
+ adev-irq_requested_type = KVM_ASSIGNED_DEV_GUEST_INTX |
+ KVM_ASSIGNED_DEV_HOST_INTX;
return 0;
}
@@ -227,7 +228,7 @@ static int kvm_vm_ioctl_assign_irq(struct kvm *kvm,
return -EINVAL;
}
- if (!match-irq_requested) {
+ if (!match-irq_requested_type) {
INIT_WORK(match-interrupt_work,
kvm_assigned_dev_interrupt_work_handler);
if (irqchip_in_kernel(kvm)) {
--
1.5.4.5
--
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 8/9] KVM: Enable MSI for device assignment
We enable guest MSI and host MSI support in this patch. The userspace want to
enable MSI should set KVM_DEV_IRQ_ASSIGN_ENABLE_MSI in the assigned_irq's flag.
Function would return -ENOTTY if can't enable MSI, userspace shouldn't set MSI
Enable bit when KVM_ASSIGN_IRQ return -ENOTTY with
KVM_DEV_IRQ_ASSIGN_ENABLE_MSI.
Userspace can tell the support of MSI device from #ifdef KVM_CAP_DEVICE_MSI.
Signed-off-by: Sheng Yang [EMAIL PROTECTED]
---
include/linux/kvm.h |3 ++
virt/kvm/kvm_main.c | 81 +++
2 files changed, 78 insertions(+), 6 deletions(-)
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index bb283c3..0997e6f 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -392,6 +392,9 @@ struct kvm_trace_rec {
#endif
#define KVM_CAP_IOMMU 18
#define KVM_CAP_NMI 19
+#if defined(CONFIG_X86)
+#define KVM_CAP_DEVICE_MSI 20
+#endif
/*
* ioctls for VM fds
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 228c1d1..bf36ae9 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -159,9 +159,15 @@ static void kvm_assigned_dev_interrupt_work_handler(struct
work_struct *work)
* finer-grained lock, update this
*/
mutex_lock(assigned_dev-kvm-lock);
- kvm_set_irq(assigned_dev-kvm,
- assigned_dev-irq_source_id,
- assigned_dev-guest_irq, 1);
+ if (assigned_dev-irq_requested_type KVM_ASSIGNED_DEV_GUEST_INTX)
+ kvm_set_irq(assigned_dev-kvm,
+ assigned_dev-irq_source_id,
+ assigned_dev-guest_irq, 1);
+ else if (assigned_dev-irq_requested_type
+ KVM_ASSIGNED_DEV_GUEST_MSI) {
+ assigned_device_msi_dispatch(assigned_dev);
+ enable_irq(assigned_dev-host_irq);
+ }
mutex_unlock(assigned_dev-kvm-lock);
kvm_put_kvm(assigned_dev-kvm);
}
@@ -197,6 +203,8 @@ static void kvm_free_assigned_device(struct kvm *kvm,
{
if (irqchip_in_kernel(kvm) assigned_dev-irq_requested_type)
free_irq(assigned_dev-host_irq, (void *)assigned_dev);
+ if (assigned_dev-irq_requested_type KVM_ASSIGNED_DEV_HOST_MSI)
+ pci_disable_msi(assigned_dev-dev);
kvm_unregister_irq_ack_notifier(assigned_dev-ack_notifier);
kvm_free_irq_source_id(kvm, assigned_dev-irq_source_id);
@@ -242,6 +250,11 @@ static int assigned_device_update_intx(struct kvm *kvm,
return 0;
if (irqchip_in_kernel(kvm)) {
+ if (adev-irq_requested_type KVM_ASSIGNED_DEV_HOST_MSI) {
+ free_irq(adev-host_irq, (void *)kvm);
+ pci_disable_msi(adev-dev);
+ }
+
if (!capable(CAP_SYS_RAWIO))
return -EPERM;
@@ -265,6 +278,41 @@ static int assigned_device_update_intx(struct kvm *kvm,
return 0;
}
+#ifdef CONFIG_X86
+static int assigned_device_update_msi(struct kvm *kvm,
+ struct kvm_assigned_dev_kernel *adev,
+ struct kvm_assigned_irq *airq)
+{
+ int r;
+
+ /* x86 don't care upper address of guest msi message addr */
+ adev-guest_msi.address_lo = airq-guest_msi.addr_lo;
+ adev-guest_msi.data = airq-guest_msi.data;
+ adev-ack_notifier.gsi = -1;
+
+ if (adev-irq_requested_type KVM_ASSIGNED_DEV_HOST_MSI)
+ return 0;
+
+ if (irqchip_in_kernel(kvm)) {
+ if (adev-irq_requested_type KVM_ASSIGNED_DEV_HOST_INTX)
+ free_irq(adev-host_irq, (void *)adev);
+
+ r = pci_enable_msi(adev-dev);
+ if (r)
+ return r;
+
+ adev-host_irq = adev-dev-irq;
+ if (request_irq(adev-host_irq, kvm_assigned_dev_intr, 0,
+ kvm_assigned_msi_device, (void *)adev))
+ return -EIO;
+ }
+
+ adev-irq_requested_type = KVM_ASSIGNED_DEV_GUEST_MSI |
+ KVM_ASSIGNED_DEV_HOST_MSI;
+ return 0;
+}
+#endif
+
static int kvm_vm_ioctl_assign_irq(struct kvm *kvm,
struct kvm_assigned_irq
*assigned_irq)
@@ -301,9 +349,30 @@ static int kvm_vm_ioctl_assign_irq(struct kvm *kvm,
}
}
- r = assigned_device_update_intx(kvm, match, assigned_irq);
- if (r)
- goto out_release;
+ if (assigned_irq-flags KVM_DEV_IRQ_ASSIGN_ENABLE_MSI) {
+#ifdef CONFIG_X86
+ r = assigned_device_update_msi(kvm, match, assigned_irq);
+ if (r) {
+ printk(KERN_WARNING kvm: failed to enable
+ MSI device!\n);
+ goto out_release;
+ }
+#else
+ r = -ENOTTY;
+#endif
+ } else if
[PATCH 2/9] KVM: Separate update irq to a single function
Separate INTx enabling part to a independence function, so that we can add MSI
enabling part easily.
Signed-off-by: Sheng Yang [EMAIL PROTECTED]
---
virt/kvm/kvm_main.c | 68 --
1 files changed, 38 insertions(+), 30 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 8966fd1..ef2f03c 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -176,6 +176,41 @@ void kvm_free_all_assigned_devices(struct kvm *kvm)
}
}
+static int assigned_device_update_intx(struct kvm *kvm,
+ struct kvm_assigned_dev_kernel *adev,
+ struct kvm_assigned_irq *airq)
+{
+ if (adev-irq_requested) {
+ adev-guest_irq = airq-guest_irq;
+ adev-ack_notifier.gsi = airq-guest_irq;
+ return 0;
+ }
+
+ if (irqchip_in_kernel(kvm)) {
+ if (!capable(CAP_SYS_RAWIO))
+ return -EPERM;
+
+ if (airq-host_irq)
+ adev-host_irq = airq-host_irq;
+ else
+ adev-host_irq = adev-dev-irq;
+ adev-guest_irq = airq-guest_irq;
+ adev-ack_notifier.gsi = airq-guest_irq;
+
+ /* Even though this is PCI, we don't want to use shared
+* interrupts. Sharing host devices with guest-assigned devices
+* on the same interrupt line is not a happy situation: there
+* are going to be long delays in accepting, acking, etc.
+*/
+ if (request_irq(adev-host_irq, kvm_assigned_dev_intr,
+ 0, kvm_assigned_intx_device, (void *)adev))
+ return -EIO;
+ }
+
+ adev-irq_requested = true;
+ return 0;
+}
+
static int kvm_vm_ioctl_assign_irq(struct kvm *kvm,
struct kvm_assigned_irq
*assigned_irq)
@@ -210,39 +245,12 @@ static int kvm_vm_ioctl_assign_irq(struct kvm *kvm,
else
match-irq_source_id = r;
}
- } else {
- match-guest_irq = assigned_irq-guest_irq;
- match-ack_notifier.gsi = assigned_irq-guest_irq;
- mutex_unlock(kvm-lock);
- return 0;
}
- if (irqchip_in_kernel(kvm)) {
- if (!capable(CAP_SYS_RAWIO)) {
- r = -EPERM;
- goto out_release;
- }
-
- if (assigned_irq-host_irq)
- match-host_irq = assigned_irq-host_irq;
- else
- match-host_irq = match-dev-irq;
- match-guest_irq = assigned_irq-guest_irq;
- match-ack_notifier.gsi = assigned_irq-guest_irq;
-
- /* Even though this is PCI, we don't want to use shared
-* interrupts. Sharing host devices with guest-assigned devices
-* on the same interrupt line is not a happy situation: there
-* are going to be long delays in accepting, acking, etc.
-*/
- if (request_irq(match-host_irq, kvm_assigned_dev_intr, 0,
- kvm_assigned_device, (void *)match)) {
- r = -EIO;
- goto out_release;
- }
- }
+ r = assigned_device_update_intx(kvm, match, assigned_irq);
+ if (r)
+ goto out_release;
- match-irq_requested = true;
mutex_unlock(kvm-lock);
return r;
out_release:
--
1.5.4.5
--
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 9/9] KVM: MSI to INTx translate
Now we use MSI as default one, and translate MSI to INTx when guest need
INTx rather than MSI. For legacy device, we provide support for non-sharing
host IRQ.
Provide a parameter msi2intx for this method. The value is true by default in
x86 architecture.
We can't guarantee this mode can work on every device, but for most of us
tested, it works. If your device encounter some trouble with this mode, you can
try set msi2intx modules parameter to 0. If the device is OK with msi2intx=0,
then please report it to KVM mailing list or me. We may prepare a blacklist for
the device that can't work in this mode.
Signed-off-by: Sheng Yang [EMAIL PROTECTED]
---
virt/kvm/kvm_main.c | 70 +++---
1 files changed, 54 insertions(+), 16 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index bf36ae9..54d25e6 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -64,6 +64,9 @@
MODULE_AUTHOR(Qumranet);
MODULE_LICENSE(GPL);
+static int msi2intx = 1;
+module_param(msi2intx, bool, 0);
+
DEFINE_SPINLOCK(kvm_lock);
LIST_HEAD(vm_list);
@@ -250,7 +253,8 @@ static int assigned_device_update_intx(struct kvm *kvm,
return 0;
if (irqchip_in_kernel(kvm)) {
- if (adev-irq_requested_type KVM_ASSIGNED_DEV_HOST_MSI) {
+ if (!msi2intx
+ adev-irq_requested_type KVM_ASSIGNED_DEV_HOST_MSI) {
free_irq(adev-host_irq, (void *)kvm);
pci_disable_msi(adev-dev);
}
@@ -285,21 +289,33 @@ static int assigned_device_update_msi(struct kvm *kvm,
{
int r;
- /* x86 don't care upper address of guest msi message addr */
- adev-guest_msi.address_lo = airq-guest_msi.addr_lo;
- adev-guest_msi.data = airq-guest_msi.data;
- adev-ack_notifier.gsi = -1;
+ if (airq-flags KVM_DEV_IRQ_ASSIGN_ENABLE_MSI) {
+ /* x86 don't care upper address of guest msi message addr */
+ adev-irq_requested_type |= KVM_ASSIGNED_DEV_GUEST_MSI;
+ adev-irq_requested_type = ~KVM_ASSIGNED_DEV_GUEST_INTX;
+ adev-guest_msi.address_lo = airq-guest_msi.addr_lo;
+ adev-guest_msi.data = airq-guest_msi.data;
+ adev-ack_notifier.gsi = -1;
+ } else if (msi2intx) {
+ adev-irq_requested_type |= KVM_ASSIGNED_DEV_GUEST_INTX;
+ adev-irq_requested_type = ~KVM_ASSIGNED_DEV_GUEST_MSI;
+ adev-guest_irq = airq-guest_irq;
+ adev-ack_notifier.gsi = airq-guest_irq;
+ }
if (adev-irq_requested_type KVM_ASSIGNED_DEV_HOST_MSI)
return 0;
if (irqchip_in_kernel(kvm)) {
- if (adev-irq_requested_type KVM_ASSIGNED_DEV_HOST_INTX)
- free_irq(adev-host_irq, (void *)adev);
-
- r = pci_enable_msi(adev-dev);
- if (r)
- return r;
+ if (!msi2intx) {
+ if (adev-irq_requested_type
+ KVM_ASSIGNED_DEV_HOST_INTX)
+ free_irq(adev-host_irq, (void *)adev);
+
+ r = pci_enable_msi(adev-dev);
+ if (r)
+ return r;
+ }
adev-host_irq = adev-dev-irq;
if (request_irq(adev-host_irq, kvm_assigned_dev_intr, 0,
@@ -307,8 +323,10 @@ static int assigned_device_update_msi(struct kvm *kvm,
return -EIO;
}
- adev-irq_requested_type = KVM_ASSIGNED_DEV_GUEST_MSI |
- KVM_ASSIGNED_DEV_HOST_MSI;
+ if (!msi2intx)
+ adev-irq_requested_type = KVM_ASSIGNED_DEV_GUEST_MSI;
+
+ adev-irq_requested_type |= KVM_ASSIGNED_DEV_HOST_MSI;
return 0;
}
#endif
@@ -346,10 +364,19 @@ static int kvm_vm_ioctl_assign_irq(struct kvm *kvm,
goto out_release;
else
match-irq_source_id = r;
+
+#ifdef CONFIG_X86
+ /* Determine host device irq type, we can know the
+* result from dev-msi_enabled */
+ if (msi2intx)
+ pci_enable_msi(match-dev);
+#endif
}
}
- if (assigned_irq-flags KVM_DEV_IRQ_ASSIGN_ENABLE_MSI) {
+ if ((!msi2intx
+(assigned_irq-flags KVM_DEV_IRQ_ASSIGN_ENABLE_MSI)) ||
+ (msi2intx match-dev-msi_enabled)) {
#ifdef CONFIG_X86
r = assigned_device_update_msi(kvm, match, assigned_irq);
if (r) {
@@ -362,8 +389,16 @@ static int kvm_vm_ioctl_assign_irq(struct kvm *kvm,
#endif
} else if (assigned_irq-host_irq == 0 match-dev-irq == 0) {
/* Host device IRQ 0 means don't support INTx */
- printk(KERN_WARNING kvm: wait
[ kvm-Bugs-2327497 ] NFS copy makes guest network unstable
Bugs item #2327497, was opened at 2008-11-22 07:53 Message generated for change (Comment added) made by jiajun You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2327497group_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: Open Resolution: None Priority: 5 Private: No Submitted By: Jiajun Xu (jiajun) Assigned to: Nobody/Anonymous (nobody) Summary: NFS copy makes guest network unstable Initial Comment: The NFS network of KVM guest is very unstable. When we copy a 600M file to the guest by NFS mount. The guest's network will down after finishing at about 500M size. Then, guest's network is down. Host also can not use ping or scp. And sometimes, host also complains: ping: sendmsg: No buffer space available. I see memory by 'free', there is only 69MB free (While totally 8GB on the machine!). Using scp to copy file can not reproduce it. This issue is very easy to be reproduced (50%). Reproduce steps: 1. Create a guest and config NFS sharing folder on it 2. Mount the nfs folder to local folder --- /media 3. cp xxx /media 4. After some time, guest network is down -- Comment By: Jiajun Xu (jiajun) Date: 2008-11-23 23:01 Message: We did not test such case before. I think the issue also exists before. -- Comment By: Avi Kivity (avik) Date: 2008-11-23 13:13 Message: It's almost certainly a problem with the qemu process, not the bridge. -- Comment By: Fabio Coatti (cova) Date: 2008-11-23 12:15 Message: I can't find out easily wich kvm version worked (nor be sure that is kvm executable itself to have issues), as the subsystems involved are quite a lot an some time passet prior to spot the problem. (kvm itself, network birdge, host kernel may be involved, of course). Now I'm trying to find out the combination that worked, but at the same time I'll be willing to do some tests to discover (on the actual non working setup) some hints, as the bisection can be a very daunting task. (this issue has been noticed after several upgrades). -- Comment By: Avi Kivity (avik) Date: 2008-11-23 10:40 Message: Is this a regression, or a new test? It it is a regression, what was the last version that worked? -- Comment By: Fabio Coatti (cova) Date: 2008-11-23 07:12 Message: I can confirm a similar behaviour: a kvm machines gets large amounts of data via http protocol and saves that files over NFS. (file sizes are in the range of 4-20 MB approx and the machine downloads several of that files.) After some time (I don't have a precise figure, but some hundreds of MB) the guest nework goes down. No answers even to ping coming from outside. the guest uses virtio network drivers (as normal drivers are way too slow) host machine: 64 bit AMD dual quad core 16GB, tried with several kernels ranging from 2.6.27.4 to 2.6.25.19 guest: 32 bit kvm machines (tried 76/77/78 ). both UP and SMP configuration. kernels: same as host machine network setup: bridged network with br0 device on host machine. We are using 2 vlans for guest and we have tried all the configuration (single tap and vlans resolved on guest side,then two tap so two interfaces on guest machine and so on) without any improvement. I can exclude MTU issues, as we have seen that and solved, this issue is completely different. At some point, sniffing traffic on host interfaces we are able to see only ARP requests coming from guest, nothing more. I understand that data is in no way complete, but I'm willing to do any debug if someone gives me any hint on how to do so correctly. Thanks. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2327497group_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: [PATCH 3/4] Support for device capability
On Sunday 23 November 2008 20:28:21 Avi Kivity wrote:
Sheng Yang wrote:
This framework can be easily extended to support device capability, like
MSI/MSI-x.
At least some of this should go into pci.c, so non-assigned devices can
benefit.
So you means a capability configuration space for native QEmu? Yeah, that's
reasonable if we can emulate them. :)
static void assigned_dev_pci_write_config(PCIDevice *d, uint32_t
address, uint32_t val, int len) {
int fd;
ssize_t ret;
+AssignedDevice *pci_dev = (AssignedDevice *)d;
container_of()
Oops, I just think QEmu don't have this macro...
--
regards
Yang, Sheng
--
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
