[PATCH] kvm: external module: add kvm-ia64.c to hack files list
From: Zhang, Yang yang.zh...@intel.com The function hrtimer_start_expires() in the kvm-ia64.c is not supported before the kernel 2.6.28. So we need to hack it. Signed-off-by: Yang Zhang yang.zh...@intel.com Signed-off-by: Marcelo Tosatti mtosa...@redhat.com diff --git a/kernel/Makefile b/kernel/Makefile index 4b4e134..b7883ce 100644 --- a/kernel/Makefile +++ b/kernel/Makefile @@ -30,7 +30,7 @@ unifdef = mv $1 $1.orig cat unifdef.h $1.orig $1 rm $1.orig hack = $(call _hack,$T/$(strip $1)) hack-files-x86 = kvm_main.c mmu.c vmx.c svm.c x86.c irq.h lapic.c i8254.c kvm_trace.c timer.c -hack-files-ia64 = kvm_main.c kvm_fw.c kvm_lib.c +hack-files-ia64 = kvm_main.c kvm_fw.c kvm_lib.c kvm-ia64.c hack-files = $(hack-files-$(ARCH_DIR)) -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Merge branch 'qemu-cvs'
From: Avi Kivity a...@redhat.com * qemu-cvs: (135 commits) Use firmware configuration instead of NVRAM (initial patch by Aurelien Jarno) Add new entries to firmware configuration device Rename _BSD to HOST_BSD so that it's more obvious that it's defined by configure target-mips: remove dead code target-mips: rename helpers from do_ to helper_ do not pretend to support low voltage operation Fix correct reset value for ARM CP15 c1 auxiliary control register Work around QEMU GDB stub suboptimality Fix off-by-one errors for Altivec and SPE registers Use C99 initializers for BlockDriver methods clean build: Fix remaining m68k warnings clean build: Fix arm build warnings arm: Fix gic_irq_state.level bitfield type target-ppc: move the CD-ROM drive to the second IDE ppc_oldworld: swap the MACIO and CMD646 IDE controllers Use a dedicated function to request exit from execution loop Fix texinfo syntax errors. Disable BAT for 970 Fix mfcr on ppc64-softmmu Keep SLB in-CPU ... Conflicts: qemu/configure qemu/cpu-defs.h qemu/exec.c qemu/hw/pci-hotplug.c qemu/monitor.c qemu/net.c qemu/pc-bios/Makefile qemu/pc-bios/bios.bin qemu/qemu-tool.c qemu/sysemu.h qemu/vl.c Signed-off-by: Avi Kivity a...@redhat.com -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] kvm: qemu: fix warnings in ia64
From: Zhang, Yang yang.zh...@intel.com
clean up the warning info in the ia64's code
Signed-off-by: Yang Zhang yang.zh...@intel.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/qemu/hw/ipf.c b/qemu/hw/ipf.c
index eb9aaec..e2b53ee 100644
--- a/qemu/hw/ipf.c
+++ b/qemu/hw/ipf.c
@@ -387,7 +387,6 @@ static void ipf_init1(ram_addr_t ram_size, int vga_ram_size,
PCIBus *pci_bus;
int piix3_devfn = -1;
CPUState *env;
-NICInfo *nd;
qemu_irq *cpu_irq;
qemu_irq *i8259;
int page_size;
@@ -487,7 +486,7 @@ static void ipf_init1(ram_addr_t ram_size, int vga_ram_size,
kvm_ia64_copy_from_nvram_to_GFW(nvram_fd, g_fw_start);
close(nvram_fd);
}
-i = atexit(kvm_ia64_copy_from_GFW_to_nvram);
+i = atexit((void *)kvm_ia64_copy_from_GFW_to_nvram);
if (i != 0)
fprintf(stderr, cannot set exit function\n);
}
@@ -671,8 +670,8 @@ static void ipf_init_pci(ram_addr_t ram_size, int
vga_ram_size,
QEMUMachine ipf_machine = {
.name = itanium,
.desc = Itanium Platform,
-.init = ipf_init_pci,
-.ram_require = VGA_RAM_SIZE + GFW_SIZE,
+.init = (QEMUMachineInitFunc *)ipf_init_pci,
+.ram_require = (ram_addr_t)(VGA_RAM_SIZE + GFW_SIZE),
.max_cpus = 255,
};
diff --git a/qemu/qemu-kvm-ia64.c b/qemu/qemu-kvm-ia64.c
index f9e4b4b..66e4232 100644
--- a/qemu/qemu-kvm-ia64.c
+++ b/qemu/qemu-kvm-ia64.c
@@ -8,9 +8,9 @@
#include libkvm.h
#include pthread.h
#include sys/utsname.h
+#include sys/io.h
-extern kvm_context_t kvm_context;
int kvm_arch_qemu_create_context(void)
{
diff --git a/qemu/target-ia64/exec.h b/qemu/target-ia64/exec.h
index 0e6b9e8..37b64f7 100644
--- a/qemu/target-ia64/exec.h
+++ b/qemu/target-ia64/exec.h
@@ -45,7 +45,6 @@ void do_interrupt (CPUState *env);
void cpu_lock(void);
void cpu_unlock(void);
-void cpu_loop_exit(void);
static inline int cpu_halted(CPUState *env) {
/* handle exit of HALTED state */
diff --git a/qemu/target-ia64/firmware.c b/qemu/target-ia64/firmware.c
index 88fcaa8..87a8178 100644
--- a/qemu/target-ia64/firmware.c
+++ b/qemu/target-ia64/firmware.c
@@ -649,7 +649,8 @@ kvm_ia64_copy_from_nvram_to_GFW(unsigned long nvram_fd,
struct stat file_stat;
if ((fstat(nvram_fd, file_stat) 0) ||
(NVRAM_SIZE != file_stat.st_size) ||
-(read(nvram_fd, fw_start + NVRAM_OFFSET, NVRAM_SIZE) != NVRAM_SIZE))
+(read(nvram_fd, (void *)(fw_start + NVRAM_OFFSET),
+ NVRAM_SIZE) != NVRAM_SIZE))
return -1;
return 0;
}
diff --git a/qemu/target-ia64/firmware.h b/qemu/target-ia64/firmware.h
index 47aaa1d..c1707ac 100644
--- a/qemu/target-ia64/firmware.h
+++ b/qemu/target-ia64/firmware.h
@@ -57,7 +57,7 @@ extern int kvm_ia64_build_hob(unsigned long memsize, unsigned
long vcpus,
uint8_t *fw_start, unsigned long nvram_addr);
extern char *read_image(const char *filename, unsigned long *size);
-extern int kvm_ia64_copy_from_GFW_to_nvram();
+extern int kvm_ia64_copy_from_GFW_to_nvram(void);
extern int kvm_ia64_nvram_init(unsigned long type);
extern int kvm_ia64_copy_from_nvram_to_GFW(unsigned long nvram_fd,
const uint8_t *fw_start);
diff --git a/qemu/target-ia64/op_helper.c b/qemu/target-ia64/op_helper.c
index 78b32f9..d51525a 100644
--- a/qemu/target-ia64/op_helper.c
+++ b/qemu/target-ia64/op_helper.c
@@ -27,6 +27,12 @@
#include qemu-kvm.h
#include qemu-common.h
+void cpu_ia64_set_model(CPUIA64State *env, uint32_t id);
+void cpu_ia64_close(CPUIA64State *env);
+void switch_mode(CPUState *env, int mode);
+void do_interrupt(CPUIA64State *env);
+int cpu_ia64_handle_mmu_fault (CPUState *env, target_ulong address,
+ int access_type, int is_user, int is_softmmu);
CPUState *cpu_ia64_init(const char *cpu_model)
{
CPUState *env;
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] KVM: ia64: Drop in SN2 replacement of fast path ITC emulation fault handler
From: Jes Sorensen j...@sgi.com
Copy in SN2 RTC based ITC emulation for fast exit. The two versions
have the same size, so a dropin is simpler than patching the branch
instruction to hit the SN2 version.
Signed-off-by: Jes Sorensen j...@sgi.com
Acked-by: Xiantao Zhang xiantao.zh...@intel.com
Signed-off-by: Avi Kivity a...@redhat.com
diff --git a/arch/ia64/include/asm/kvm_host.h b/arch/ia64/include/asm/kvm_host.h
index 1243995..589536f 100644
--- a/arch/ia64/include/asm/kvm_host.h
+++ b/arch/ia64/include/asm/kvm_host.h
@@ -580,6 +580,8 @@ struct kvm_vmm_info{
kvm_vmm_entry *vmm_entry;
kvm_tramp_entry *tramp_entry;
unsigned long vmm_ivt;
+ unsigned long patch_mov_ar;
+ unsigned long patch_mov_ar_sn2;
};
int kvm_highest_pending_irq(struct kvm_vcpu *vcpu);
diff --git a/arch/ia64/kvm/kvm-ia64.c b/arch/ia64/kvm/kvm-ia64.c
index ff301a7..c25347f 100644
--- a/arch/ia64/kvm/kvm-ia64.c
+++ b/arch/ia64/kvm/kvm-ia64.c
@@ -1669,8 +1669,37 @@ out:
return 0;
}
+
+/*
+ * On SN2, the ITC isn't stable, so copy in fast path code to use the
+ * SN2 RTC, replacing the ITC based default verion.
+ */
+static void kvm_patch_vmm(struct kvm_vmm_info *vmm_info,
+ struct module *module)
+{
+ unsigned long new_ar, new_ar_sn2;
+ unsigned long module_base;
+
+ if (!ia64_platform_is(sn2))
+ return;
+
+ module_base = (unsigned long)module-module_core;
+
+ new_ar = kvm_vmm_base + vmm_info-patch_mov_ar - module_base;
+ new_ar_sn2 = kvm_vmm_base + vmm_info-patch_mov_ar_sn2 - module_base;
+
+ printk(KERN_INFO kvm: Patching ITC emulation to use SGI SN2 RTC
+ as source\n);
+
+ /*
+* Copy the SN2 version of mov_ar into place. They are both
+* the same size, so 6 bundles is sufficient (6 * 0x10).
+*/
+ memcpy((void *)new_ar, (void *)new_ar_sn2, 0x60);
+}
+
static int kvm_relocate_vmm(struct kvm_vmm_info *vmm_info,
- struct module *module)
+ struct module *module)
{
unsigned long module_base;
unsigned long vmm_size;
@@ -1692,6 +1721,7 @@ static int kvm_relocate_vmm(struct kvm_vmm_info *vmm_info,
return -EFAULT;
memcpy((void *)kvm_vmm_base, (void *)module_base, vmm_size);
+ kvm_patch_vmm(vmm_info, module);
kvm_flush_icache(kvm_vmm_base, vmm_size);
/*Recalculate kvm_vmm_info based on new VMM*/
diff --git a/arch/ia64/kvm/optvfault.S b/arch/ia64/kvm/optvfault.S
index 32254ce..f793be3 100644
--- a/arch/ia64/kvm/optvfault.S
+++ b/arch/ia64/kvm/optvfault.S
@@ -11,6 +11,7 @@
#include asm/asmmacro.h
#include asm/processor.h
+#include asm/kvm_host.h
#include vti.h
#include asm-offsets.h
@@ -140,6 +141,35 @@ GLOBAL_ENTRY(kvm_asm_mov_from_ar)
;;
END(kvm_asm_mov_from_ar)
+/*
+ * Special SGI SN2 optimized version of mov_from_ar using the SN2 RTC
+ * clock as it's source for emulating the ITC. This version will be
+ * copied on top of the original version if the host is determined to
+ * be an SN2.
+ */
+GLOBAL_ENTRY(kvm_asm_mov_from_ar_sn2)
+ add r18=VMM_VCPU_ITC_OFS_OFFSET, r21
+ movl r19 = (KVM_VMM_BASE+(1KVM_VMM_SHIFT))
+
+ add r16=VMM_VCPU_LAST_ITC_OFFSET,r21
+ extr.u r17=r25,6,7
+ mov r24=b0
+ ;;
+ ld8 r18=[r18]
+ ld8 r19=[r19]
+ addl r...@gprel(asm_mov_to_reg),gp
+ ;;
+ add r19=r19,r18
+ shladd r17=r17,4,r20
+ ;;
+ adds r30=kvm_resume_to_guest-asm_mov_to_reg,r20
+ st8 [r16] = r19
+ mov b0=r17
+ br.sptk.few b0
+ ;;
+END(kvm_asm_mov_from_ar_sn2)
+
+
// mov r1=rr[r3]
GLOBAL_ENTRY(kvm_asm_mov_from_rr)
diff --git a/arch/ia64/kvm/vmm.c b/arch/ia64/kvm/vmm.c
index 9eee5c0..f4b4c89 100644
--- a/arch/ia64/kvm/vmm.c
+++ b/arch/ia64/kvm/vmm.c
@@ -30,15 +30,19 @@ MODULE_AUTHOR(Intel);
MODULE_LICENSE(GPL);
extern char kvm_ia64_ivt;
+extern char kvm_asm_mov_from_ar;
+extern char kvm_asm_mov_from_ar_sn2;
extern fpswa_interface_t *vmm_fpswa_interface;
long vmm_sanity = 1;
struct kvm_vmm_info vmm_info = {
- .module = THIS_MODULE,
- .vmm_entry = vmm_entry,
- .tramp_entry = vmm_trampoline,
- .vmm_ivt = (unsigned long)kvm_ia64_ivt,
+ .module = THIS_MODULE,
+ .vmm_entry = vmm_entry,
+ .tramp_entry= vmm_trampoline,
+ .vmm_ivt= (unsigned long)kvm_ia64_ivt,
+ .patch_mov_ar = (unsigned long)kvm_asm_mov_from_ar,
+ .patch_mov_ar_sn2 = (unsigned long)kvm_asm_mov_from_ar_sn2,
};
static int __init kvm_vmm_init(void)
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM: x86: use smp_send_reschedule in kvm_vcpu_kick
Marcelo Tosatti wrote: OK, reworked patch: - change ia64 in addition to x86 - add comment on smp send reschedule handlers about KVM's usage Untested on IA64. KVM: use smp_send_reschedule in kvm_vcpu_kick KVM uses a function call IPI to cause the exit of a guest running on a physical cpu. For virtual interrupt notification there is no need to wait on IPI receival, or to execute any function. This is exactly what the reschedule IPI does, without the overhead of function IPI. So use it instead of smp_call_function_single in kvm_vcpu_kick. Also change the guest_mode variable to a bit in vcpu-requests, and use that to collapse multiple IPI's that would be issued between the first one and zeroing of guest mode. This allows kvm_vcpu_kick to called with interrupts disabled. Looks good. Will wait for Xiantao's test-n-ack before applying. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems KVM-84
J- MAN wrote: Also the second time i run the command, it only takes around 2-3 seconds for the window to open. I don't think this is a regression from kvm-83. Large qcow2 files have lots of metadata which needs to be loaded up front. If the kernel doesn't have this cached, it will take a long time. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems KVM-84
J- MAN wrote: I don't think this is a regression from kvm-83. Large qcow2 files have lots of metadata which needs to be loaded up front. If the kernel doesn't have this cached, it will take a long time. I'm just wondering what happend between 83 and 84, because there is no startup delay in 83. My real problem is that libvirt times out when waiting for my virtual machine to start using 84, unless i manually start the machine first to get it cached. This makes using libvirt virt-manager useless with 84 unless i pre-start all my VMs manually to get them cached. I'm suprised nobody else is having this issue. If there is anything else i can do to help please let me know. Try (with kvm-83): echo 255 /proc/sys/vm/drop-caches qemu ... -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2679041 ] BUG: scheduling while atomic: qemu-system-x86
Bugs item #2679041, was opened at 2009-03-10 10:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2679041group_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: kernel Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dave Sperry (sperryd) Assigned to: Nobody/Anonymous (nobody) Summary: BUG: scheduling while atomic: qemu-system-x86 Initial Comment: Syslog reports the following bug on a regular basis: Mar 10 09:19:02 jmeesoa1 kernel: BUG: scheduling while atomic: qemu-system-x86/0x0002/27555, CPU#0 Mar 10 09:19:02 jmeesoa1 kernel: Pid: 27555, comm: qemu-system-x86 Not tainted 2.6.24.7-75ibmrt2.18 #1 Mar 10 09:19:02 jmeesoa1 kernel: Mar 10 09:19:02 jmeesoa1 kernel: Call Trace: Mar 10 09:19:02 jmeesoa1 kernel: [81036dfd] __schedule_bug+0x66/0x6b Mar 10 09:19:02 jmeesoa1 kernel: [81284c0f] __schedule+0xe6/0x7f3 Mar 10 09:19:02 jmeesoa1 kernel: [8105dfb9] ? __rt_mutex_adjust_prio+0x11/0x24 Mar 10 09:19:02 jmeesoa1 kernel: [8105f001] ? task_blocks_on_rt_mutex+0x193/0x1fa Mar 10 09:19:02 jmeesoa1 kernel: [8128566a] schedule+0xdf/0xff Mar 10 09:19:02 jmeesoa1 kernel: [81286ce5] rt_spin_lock_slowlock+0x176/0x235 Mar 10 09:19:02 jmeesoa1 kernel: [81287380] __rt_spin_lock+0x4d/0x4f Mar 10 09:19:02 jmeesoa1 kernel: [8128738b] rt_spin_lock+0x9/0xb Mar 10 09:19:02 jmeesoa1 kernel: [81039818] __wake_up+0x1c/0x5b Mar 10 09:19:02 jmeesoa1 kernel: [8850d001] :kvm:kvm_vcpu_kick+0x54/0xaa Mar 10 09:19:02 jmeesoa1 kernel: [8851cb86] :kvm:kvm_apic_set_irq+0x70/0x77 Mar 10 09:19:02 jmeesoa1 kernel: [8851cdac] :kvm:ioapic_inj_irq+0x14/0x16 Mar 10 09:19:02 jmeesoa1 kernel: [8851d022] :kvm:ioapic_service+0xbf/0x1ad Mar 10 09:19:02 jmeesoa1 kernel: [8851d1f5] :kvm:kvm_ioapic_set_irq+0x5f/0x61 Mar 10 09:19:02 jmeesoa1 kernel: [8851e5bd] :kvm:kvm_set_ioapic_irq+0x15/0x17 Mar 10 09:19:02 jmeesoa1 kernel: [8851e6ec] :kvm:kvm_set_irq+0x61/0x8a Mar 10 09:19:02 jmeesoa1 kernel: [8851d4bc] :kvm:kvm_inject_pit_timer_irqs+0x7f/0xd9 Mar 10 09:19:02 jmeesoa1 kernel: [8851ae1e] :kvm:kvm_inject_pending_timer_irqs+0x19/0x1d Mar 10 09:19:02 jmeesoa1 kernel: [8850d91d] :kvm:kvm_arch_vcpu_ioctl_run+0x3e3/0x929 Mar 10 09:19:02 jmeesoa1 kernel: [81110ae5] ? inode_has_perm+0x6b/0x7a Mar 10 09:19:02 jmeesoa1 kernel: [8850971b] :kvm:kvm_vcpu_ioctl+0xf9/0x462 Mar 10 09:19:02 jmeesoa1 kernel: [81110b9b] ? file_has_perm+0xa7/0xb6 Mar 10 09:19:02 jmeesoa1 kernel: [810bc4b2] do_ioctl+0x2a/0x77 Mar 10 09:19:02 jmeesoa1 kernel: [810bc753] vfs_ioctl+0x254/0x271 Mar 10 09:19:02 jmeesoa1 kernel: [810bc7c7] sys_ioctl+0x57/0x7c Mar 10 09:19:02 jmeesoa1 kernel: [8100c37e] traceret+0x0/0x5 Mar 10 09:19:02 jmeesoa1 kernel: We are running KVM-84 on 2.6.24.7-75ibmrt2.18 #1 SMP PREEMPT RT on IBM HS21 blades Intel(R) Xeon(R) CPU E5450 @ 3.00GHz The guests are RHEL4.4 started on host with: qemu-system-x86_64 -localtime -name jmeevm03 -hda /zoo/SosDevVm03.cow -m 4048 -net nic,macaddr=00:00:8F:80:00:03 -net tap -smp 2 -vnc :6 From the menu.lst on guests: kernel /boot/vmlinuz-2.6.9-42.ELsmp ro root=LABEL=/ clock=pit quiet AND ntp running on guests an host Is this a kernel problem or a KVM problem? -Thanks -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2679041group_id=180599 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bulk] RE: [Qemu-devel] ANNOUNCE: QEMU 0.10.0 stable branch
Dietmar Maurer wrote: I just wonder if 0.XX is a good name for a stable release. May is suggest to increase the major number (1.XX). It's not that stable Doug. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ioapic/msi interrupt delivery consolidation.
On 05/03/09 16:34 +0200, Gleb Natapov wrote:
ioapic_deliver() and kvm_set_msi() have code duplication. Move
the code into ioapic_deliver_entry() function and call it from
both places.
+static int ioapic_deliver(struct kvm_ioapic *ioapic, int irq)
+{
+ union kvm_ioapic_redirect_entry entry = ioapic-redirtbl[irq];
+
+ ioapic_debug(dest=%x dest_mode=%x delivery_mode=%x
+ vector=%x trig_mode=%x\n,
+ entry.fields.dest, entry.fields.dest_mode,
+ entry.fields.delivery_mode, entry.fields.vector,
+ entry.fields.trig_mode);
+
+#ifdef CONFIG_X86
+ /* Always delivery PIT interrupt to vcpu 0 */
+ if (irq == 0) {
+ entry.fields.dest_mode = 0; /* Physical mode. */
+ entry.fields.dest_id = ioapic-kvm-vcpus[0]-vcpu_id;
+ }
+#endif
+ return ioapic_deliver_entry(ioapic-kvm, entry);
+}
+
Why is the PIT always handled by vcpu 0?
thanks,
Mike
--
Mike Day
http://www.ncultra.org
AIM: ncmikeday | Yahoo IM: ultra.runner
PGP key: http://www.ncultra.org/ncmike/pubkey.asc
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
new wiki missing pages?
Hi, I notice the old wiki has been replaced with http://www.linux-kvm.org/ ... unfortunately it seems to be missing *all* PowerPC information. Can this be recovered please? I have no idea what other pages may be missing. -- Hollis Blanchard IBM Linux Technology Center -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: new wiki missing pages?
* Hollis Blanchard holl...@us.ibm.com [2009-03-10 13:46]: Hi, I notice the old wiki has been replaced with http://www.linux-kvm.org/ ... unfortunately it seems to be missing *all* PowerPC information. Can this be recovered please? I have no idea what other pages may be missing. http://kvm.qumranet.com/kvmwiki/KVM_RegressionTest redirects to the main page at www.linux-kvm.org The Getting Started link tries to edit the page .. http://www.linux-kvm.org/wiki/index.php?title=KVM-Autotest/Getting_Startedaction=edit The Tests link also tries to edit the page ... http://www.linux-kvm.org/wiki/index.php?title=KVM-Autotest/Testsaction=edit -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ry...@us.ibm.com -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Virtulization instructions like skinit and TXT support inside KVM
On Sat, Feb 28, 2009 at 03:58:37AM +0100, Pravin wrote: Hi, I wanted to know how kvm handles special previlaged instructions provided for virtulization support like skinit in AMD and TXT in intel. Are they also virtualized in KVM..?? Is there any work going in this direction? Pointers to any documentations in this direction will be helpful to me. Skinit is not virtualized on AMD systems and there is no plan to implement this currently. Joerg -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: new wiki missing pages? / new wiki for kvm
Ryan Harper wrote: * Hollis Blanchard holl...@us.ibm.com [2009-03-10 13:46]: Hi, I notice the old wiki has been replaced with http://www.linux-kvm.org/ ... unfortunately it seems to be missing *all* PowerPC information. Can this be recovered please? I have no idea what other pages may be missing. http://kvm.qumranet.com/kvmwiki/KVM_RegressionTest redirects to the main page at www.linux-kvm.org The Getting Started link tries to edit the page .. http://www.linux-kvm.org/wiki/index.php?title=KVM-Autotest/Getting_Startedaction=edit The Tests link also tries to edit the page ... http://www.linux-kvm.org/wiki/index.php?title=KVM-Autotest/Testsaction=edit Sorry for that. It took IT only few month to change the Wiki... During this tight schedule some pages got lost as you can see.. Please report on a problematic/missing page. The original content can be reached using http://il.qumranet.com/kvmwiki In general, finally the kvm wiki just moved from qumranet.kvm.com to www.linux-kvm.org. We're considering an option to unite the kvm and qemu wikis together since there is allot of shared content and eventually we'll have a shared userspace executable. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with KVM-84 and more than 4 processors
Hi! Manually loading the kvm_intel module fails with an Cannot allocate memory error. Also starting VMs fails since he is unable to find /dev/kvm. Looks like a memory corruption issue. Please post your .config. Here it is... Best, Matthias # # Automatically generated make config: don't edit # Linux kernel version: 2.6.27-gentoo-r8 # Tue Mar 3 11:30:59 2009 # CONFIG_64BIT=y # CONFIG_X86_32 is not set CONFIG_X86_64=y CONFIG_X86=y CONFIG_ARCH_DEFCONFIG=arch/x86/configs/x86_64_defconfig # CONFIG_GENERIC_LOCKBREAK is not set CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_FAST_CMPXCHG_LOCAL=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y # CONFIG_GENERIC_GPIO is not set CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_RWSEM_XCHGADD_ALGORITHM is not set # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_HAVE_CPUMASK_OF_CPU_MAP=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ZONE_DMA32=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_AOUT=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_X86_SMP=y CONFIG_X86_64_SMP=y CONFIG_X86_HT=y CONFIG_X86_BIOS_REBOOT=y CONFIG_X86_TRAMPOLINE=y # CONFIG_KTIME_SCALAR is not set CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_TREE=y # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set CONFIG_CGROUP_NS=y # CONFIG_CGROUP_DEVICE is not set CONFIG_CPUSETS=y CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_GROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_RT_GROUP_SCHED is not set # CONFIG_USER_SCHED is not set CONFIG_CGROUP_SCHED=y CONFIG_CGROUP_CPUACCT=y CONFIG_RESOURCE_COUNTERS=y # CONFIG_CGROUP_MEM_RES_CTLR is not set # CONFIG_SYSFS_DEPRECATED_V2 is not set CONFIG_PROC_PID_CPUSET=y CONFIG_RELAY=y CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_IPC_NS=y CONFIG_USER_NS=y CONFIG_PID_NS=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y # CONFIG_COMPAT_BRK is not set CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_PROFILING=y CONFIG_MARKERS=y # CONFIG_OPROFILE is not set CONFIG_HAVE_OPROFILE=y CONFIG_KPROBES=y CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_KRETPROBES=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y # CONFIG_HAVE_ARCH_TRACEHOOK is not set # CONFIG_HAVE_DMA_ATTRS is not set CONFIG_USE_GENERIC_SMP_HELPERS=y # CONFIG_HAVE_CLK is not set CONFIG_PROC_PAGE_MONITOR=y # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y CONFIG_BLK_DEV_IO_TRACE=y CONFIG_BLK_DEV_BSG=y # CONFIG_BLK_DEV_INTEGRITY is not set CONFIG_BLOCK_COMPAT=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq CONFIG_PREEMPT_NOTIFIERS=y CONFIG_CLASSIC_RCU=y # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_SMP=y CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_GENERICARCH is not set #
Re: new wiki missing pages? / new wiki for kvm
On Tue, 2009-03-10 at 22:49 +0200, Dor Laor wrote: Sorry for that. It took IT only few month to change the Wiki... During this tight schedule some pages got lost as you can see.. Please report on a problematic/missing page. Are these emails sufficient, or are you asking us to report some other way? The original content can be reached using http://il.qumranet.com/kvmwiki Please restore all pages linked from here: http://il.qumranet.com/kvmwiki/CategoryPowerPC In general, finally the kvm wiki just moved from qumranet.kvm.com to www.linux-kvm.org. It's very confusing that linux-kvm.com and linux-kvm.org are apparently completely unrelated. I wonder why you chose to create .org when .com already existed. We're considering an option to unite the kvm and qemu wikis together since there is allot of shared content and eventually we'll have a shared userspace executable. That would be great! First we'll need a working qemu wiki though... maybe you can solve that problem at the same time. What timeframe are we talking about? Next week? 6 months? Just a brainstorm? -- Hollis Blanchard IBM Linux Technology Center -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] KVM: make 'lapic_timer_ops' and 'kpit_ops' static
Fix this sparse warnings:
arch/x86/kvm/lapic.c:916:22: warning: symbol 'lapic_timer_ops' was not
declared. Should it be static?
arch/x86/kvm/i8254.c:268:22: warning: symbol 'kpit_ops' was not declared.
Should it be static?
Signed-off-by: Hannes Eder han...@hanneseder.net
---
arch/x86/kvm/i8254.c |2 +-
arch/x86/kvm/lapic.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/i8254.c b/arch/x86/kvm/i8254.c
index 4e2e3f2..cf09bb6 100644
--- a/arch/x86/kvm/i8254.c
+++ b/arch/x86/kvm/i8254.c
@@ -265,7 +265,7 @@ static bool kpit_is_periodic(struct kvm_timer *ktimer)
return ps-is_periodic;
}
-struct kvm_timer_ops kpit_ops = {
+static struct kvm_timer_ops kpit_ops = {
.is_periodic = kpit_is_periodic,
};
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index dd934d2..4d76bb6 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -913,7 +913,7 @@ void kvm_apic_nmi_wd_deliver(struct kvm_vcpu *vcpu)
kvm_apic_local_deliver(apic, APIC_LVT0);
}
-struct kvm_timer_ops lapic_timer_ops = {
+static struct kvm_timer_ops lapic_timer_ops = {
.is_periodic = lapic_is_periodic,
};
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: new wiki missing pages? / new wiki for kvm
Hollis Blanchard wrote: On Tue, 2009-03-10 at 22:49 +0200, Dor Laor wrote: Sorry for that. It took IT only few month to change the Wiki... During this tight schedule some pages got lost as you can see.. Please report on a problematic/missing page. Are these emails sufficient, or are you asking us to report some other way? It is sufficient, I meant that all of the content writers should double check. Thanks. The original content can be reached using http://il.qumranet.com/kvmwiki Please restore all pages linked from here: http://il.qumranet.com/kvmwiki/CategoryPowerPC Sure In general, finally the kvm wiki just moved from qumranet.kvm.com to www.linux-kvm.org. It's very confusing that linux-kvm.com and linux-kvm.org are apparently completely unrelated. I wonder why you chose to create .org when .com already existed. You're right, I didn't pick this. Also we need to get rid of the old usage for kvm acronyms :) If we move to qemu wiki the problem will vanish. We're considering an option to unite the kvm and qemu wikis together since there is allot of shared content and eventually we'll have a shared userspace executable. That would be great! First we'll need a working qemu wiki though... maybe you can solve that problem at the same time. What timeframe are we talking about? Next week? 6 months? Just a brainstorm? One of the qemu maintainers handles it. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ioapic/msi interrupt delivery consolidation.
On Wednesday 11 March 2009 00:54:37 Mike Day wrote:
On 05/03/09 16:34 +0200, Gleb Natapov wrote:
ioapic_deliver() and kvm_set_msi() have code duplication. Move
the code into ioapic_deliver_entry() function and call it from
both places.
+static int ioapic_deliver(struct kvm_ioapic *ioapic, int irq)
+{
+ union kvm_ioapic_redirect_entry entry = ioapic-redirtbl[irq];
+
+ ioapic_debug(dest=%x dest_mode=%x delivery_mode=%x
+vector=%x trig_mode=%x\n,
+entry.fields.dest, entry.fields.dest_mode,
+entry.fields.delivery_mode, entry.fields.vector,
+entry.fields.trig_mode);
+
+#ifdef CONFIG_X86
+ /* Always delivery PIT interrupt to vcpu 0 */
+ if (irq == 0) {
+ entry.fields.dest_mode = 0; /* Physical mode. */
+ entry.fields.dest_id = ioapic-kvm-vcpus[0]-vcpu_id;
+ }
+#endif
+ return ioapic_deliver_entry(ioapic-kvm, entry);
+}
+
Why is the PIT always handled by vcpu 0?
thanks,
Hi Mike
This due to a timer bug, please google The SMP RHEL 5.1 PAE guest can't boot
up issue. (should be http://www.mail-archive.com/kvm-
de...@lists.sourceforge.net/msg13250.html but damn it, seems I've blocked by
Chinese GFW to get the page...)
--
regards
Yang, Sheng
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm-autotest -- introducing kvm_runtest_2
- Ryan Harper ry...@us.ibm.com wrote: - guest install wizard using md5sum region matching ... ouch. This is quite fickle. I've seen different kvms generate different md5sum for the same region a couple of times. I know distributing screenshots of certain OSes is a grey area, but it would be nice to plumb through screenshot comparison and make that configurable. FWIW, I'll probably look at pulling the screenshot comparison bits from kvmtest and getting that integrated in kvm_runtest_2. Creating a step file is not as easy as it seems, exactly for that reason. One has to pick a part of the screenshot that only available when input is expected and that would be consistent. We were thinking of replacing the md5sum with a tiny compressed image of the part of the image that was picked. It isn't just that step file creation isn't easy is that even with a good stepfile with smart region boxes, md5sum can *still* fail because KVM renders one pixel in the region differently than the system where the original was created; this creates false positives failures. I'd like to comment on this. I don't doubt that some fuzzy matching algorithm (such as calculating match percentages) would generally be more robust. I do however doubt it would significantly lower the false positive rate in our case (which is fairly low already). False positive failures in step files are typically caused by: - an unexpected popup window covering the test region - a dialog which has a different position every time (and varies by many pixels) - a barrier that passes before the controls get input focus, which causes the following keystrokes to have no effect - in text mode, sometimes a line of text is printed unexpectedly and causes the entire screen to scroll up - addition/modification of a KVM feature which changes the course of the installation I may have left something out. In any case, all these problems are solved by picking better barrier regions, but none can be solved by using a more forgiving comparison method. I have encountered a single installation that rendered a single pixel in an indeterministic fashion, and though this problem was easily solved by correcting the barrier (using a stepfile editor), I do agree we might get a small decrease in the false positive rate if we use a more forgiving algorithm. However, there is also a risk: a more forgiving algorithm may forgive KVM for rendering errors. It may also make it risky to pick barriers that are meant to catch small text; I believe a button with a Yes caption and a button with a No caption would have a very high match percentage, especially if you have to pick the whole button, or maybe even some of its surroundings (and you often do). I still believe it's a good idea to look into other methods (we're already doing that) and start experimenting with them. Thanks, Michael -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[net-next PATCH 2/2] igb: add PF to pool if adding a VLVF register value and the VFTA bit is
From: Alexander Duyck alexander.h.du...@intel.com
already set.
This patch addresses the unlikely situation that the PF adds a vlan
entry when the vlvf is full, and a vf later adds the vlan to the vlvf.
Signed-off-by: Alexander Duyck alexander.h.du...@intel.com
Signed-off-by: Jeff Kirsher jeffrey.t.kirs...@intel.com
---
drivers/net/igb/e1000_mac.c | 21 ++---
drivers/net/igb/e1000_mac.h |2 +-
drivers/net/igb/igb_main.c |9 +++--
3 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/drivers/net/igb/e1000_mac.c b/drivers/net/igb/e1000_mac.c
index 2804db0..f11592f 100644
--- a/drivers/net/igb/e1000_mac.c
+++ b/drivers/net/igb/e1000_mac.c
@@ -126,19 +126,26 @@ void igb_write_vfta(struct e1000_hw *hw, u32 offset, u32
value)
* Sets or clears a bit in the VLAN filter table array based on VLAN id
* and if we are adding or removing the filter
**/
-void igb_vfta_set(struct e1000_hw *hw, u32 vid, bool add)
+s32 igb_vfta_set(struct e1000_hw *hw, u32 vid, bool add)
{
u32 index = (vid E1000_VFTA_ENTRY_SHIFT) E1000_VFTA_ENTRY_MASK;
u32 mask = 1 (vid E1000_VFTA_ENTRY_BIT_SHIFT_MASK);
- u32 vfta;
+ u32 vfta = array_rd32(E1000_VFTA, index);
+ s32 ret_val = 0;
- vfta = array_rd32(E1000_VFTA, index);
- if (add)
- vfta |= mask;
- else
- vfta = ~mask;
+ /* bit was set/cleared before we started */
+ if ((!!(vfta mask)) == add) {
+ ret_val = -E1000_ERR_CONFIG;
+ } else {
+ if (add)
+ vfta |= mask;
+ else
+ vfta = ~mask;
+ }
igb_write_vfta(hw, index, vfta);
+
+ return ret_val;
}
/**
diff --git a/drivers/net/igb/e1000_mac.h b/drivers/net/igb/e1000_mac.h
index eccc353..a34de52 100644
--- a/drivers/net/igb/e1000_mac.h
+++ b/drivers/net/igb/e1000_mac.h
@@ -58,7 +58,7 @@ s32 igb_write_8bit_ctrl_reg(struct e1000_hw *hw, u32 reg,
void igb_clear_hw_cntrs_base(struct e1000_hw *hw);
void igb_clear_vfta(struct e1000_hw *hw);
-void igb_vfta_set(struct e1000_hw *hw, u32 vid, bool add);
+s32 igb_vfta_set(struct e1000_hw *hw, u32 vid, bool add);
void igb_config_collision_dist(struct e1000_hw *hw);
void igb_mta_set(struct e1000_hw *hw, u32 hash_value);
void igb_put_hw_semaphore(struct e1000_hw *hw);
diff --git a/drivers/net/igb/igb_main.c b/drivers/net/igb/igb_main.c
index 78558f8..579435d 100644
--- a/drivers/net/igb/igb_main.c
+++ b/drivers/net/igb/igb_main.c
@@ -3894,10 +3894,15 @@ static s32 igb_vlvf_set(struct igb_adapter *adapter,
u32 vid, bool add, u32 vf)
/* if !enabled we need to set this up in vfta */
if (!(reg E1000_VLVF_VLANID_ENABLE)) {
- /* add VID to filter table */
- igb_vfta_set(hw, vid, true);
+ /* add VID to filter table, if bit already set
+* PF must have added it outside of table */
+ if (igb_vfta_set(hw, vid, true))
+ reg |= 1 (E1000_VLVF_POOLSEL_SHIFT +
+ adapter-vfs_allocated_count);
reg |= E1000_VLVF_VLANID_ENABLE;
}
+ reg = ~E1000_VLVF_VLANID_MASK;
+ reg |= vid;
wr32(E1000_VLVF(i), reg);
return 0;
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm-autotest -- introducing kvm_runtest_2
* Michael Goldish mgold...@redhat.com [2009-03-10 20:55]: - Ryan Harper ry...@us.ibm.com wrote: - guest install wizard using md5sum region matching ... ouch. This is quite fickle. I've seen different kvms generate different md5sum for the same region a couple of times. I know distributing screenshots of certain OSes is a grey area, but it would be nice to plumb through screenshot comparison and make that configurable. FWIW, I'll probably look at pulling the screenshot comparison bits from kvmtest and getting that integrated in kvm_runtest_2. Creating a step file is not as easy as it seems, exactly for that reason. One has to pick a part of the screenshot that only available when input is expected and that would be consistent. We were thinking of replacing the md5sum with a tiny compressed image of the part of the image that was picked. It isn't just that step file creation isn't easy is that even with a good stepfile with smart region boxes, md5sum can *still* fail because KVM renders one pixel in the region differently than the system where the original was created; this creates false positives failures. I'd like to comment on this. I don't doubt that some fuzzy matching algorithm (such as calculating match percentages) would generally be more robust. I do however doubt it would significantly lower the false positive rate in our case (which is fairly low already). False positive failures in step files are typically caused by: I've seen multiple failures during the windows guest installs which I assume are well tested stepfiles. For example, 2k8 installs and the fails to pass the barrier when trying to set the user password for the first time. The cropped region *looks* exactly like the the intended location on the screendump, but md5sums to something different. A recent run of 2k3 and 2k8 installs resulted in the following failures: Win2k3-32bit -- screenshot of Windows Setup and Setup is starting windows, cropped region is of Setup is starting Windows full screen dump matches this text from a human pov Win2k3-64-bit -- same as above Win2k8-32-bit -- screenshot of The user's password must be changed before logging in the first time with OK and cancel buttons. - cropped region is of the text The user's password must be changed before logging in the first time - matching the full screen screendump fine from a human POV Win2k8-64-bit -- same as above We've also been creating stepfiles for Linux guests as well that aren't here, various SLES and RHEL installs -- and I've repeatedly seen the same issue where the cropped region *should* match but isn't, and it isn't a result of any of the very correct reasons you've listed below as to why the stepfiles might fail. - an unexpected popup window covering the test region - a dialog which has a different position every time (and varies by many pixels) - a barrier that passes before the controls get input focus, which causes the following keystrokes to have no effect - in text mode, sometimes a line of text is printed unexpectedly and causes the entire screen to scroll up - addition/modification of a KVM feature which changes the course of the installation I may have left something out. In any case, all these problems are solved by picking better barrier regions, but none can be solved by using a more forgiving comparison method. I have encountered a single installation that rendered a single pixel in an indeterministic fashion, and though this problem was easily solved by correcting the barrier (using a stepfile editor), I do agree we might get a small decrease in the false positive rate if we use a more forgiving algorithm. Well, either there is a *bug* right now that is triggering a higher rate of false positives, or using a better algorithm is a requirement; distributing stepfiles and md5sums that don't work isn't productive, so in the case that it is a bug I still suggest we pursue a more resilient algorithm. However, there is also a risk: a more forgiving algorithm may forgive KVM for rendering errors. It may also make it risky to pick barriers that are meant to catch small text; I believe a button with a Yes caption and a button with a No caption would have a very high match percentage, especially if you have to pick the whole button, or maybe even some of its surroundings (and you often do). Noted, though I think as you indicated above, smart selection of the cropped region goes a long way toward avoiding these sorts of collisions. I still believe it's a good idea to look into other methods (we're already doing that) and start experimenting with them. Cool. Obviously without the original ppm files from the stepmaker run, we can't determine if a different algo would help so we're generating new stepfiles and ppm data and trying to reproduce the md5sum mismatch issues. If there is anything I can do to help
Re: [PATCH v10 4/7] PCI: add SR-IOV API for Physical Function driver
On Tue, Mar 10, 2009 at 09:37:53AM +0800, Yu Zhao wrote: On Tue, Mar 10, 2009 at 03:39:01AM +0800, Greg KH wrote: On Mon, Mar 09, 2009 at 04:25:05PM +0800, Yu Zhao wrote: + pci_device_add(virtfn, virtfn-bus); Greg is probably going to ding you here for adding the device, then creating the symlinks. I believe it's now best practice to create the symlinks first, so there's no window where userspace can get confused. Yes, but unfortunately we can't create links before adding a device. I double checked device_add(), there is no place for those links to be created before it sends uevent. So for now, we have to trigger another uevent for those links. What exactly are you trying to do with a symlink here that you need to do it this way? I vaguely remember you mentioning this in the past, but I thought you had dropped the symlinks after our conversation about this very problem. I'd like to create some symlinks to reflect the relationship between Physical Function and its associated Virtual Functions. The Physical Function is like a master device that controls the allocation of its Virtual Functions and owns the device physical resource. The Virtual Functions are like slave devices of the Physical Function. For example, if 01:00.0 is a Physical Function and 02:00.0 is a Virtual Function associated with 01:00.0. Then the symlinks (virtfnN and physfn) would look like: $ ls -l /sys/bus/pci/devices/:01:00.0/ ... ... virtfn0 - ../:02:00.0 ... virtfn1 - ../:02:00.1 ... virtfn2 - ../:02:00.2 ... $ ls -l /sys/bus/pci/devices/:02:00.0/ ... ... physfn - ../:01:00.0 ... This is very useful for userspace applications, both KVM and Xen need to know this kind of relationship so they can request the permission from a Physical Function before using its associated Virtual Functions. Ok, but then make sure you never rely on a udev rule or notifier to see these symlinks when the device is added to the kernel, as there will be a nice race condition there :) thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 1/7] PCI: initialize and release SR-IOV capability
On Tue, Mar 10, 2009 at 09:19:44AM +0800, Yu Zhao wrote:
On Sat, Mar 07, 2009 at 10:38:45AM +0800, Greg KH wrote:
On Fri, Mar 06, 2009 at 01:08:10PM -0700, Matthew Wilcox wrote:
On Fri, Feb 20, 2009 at 02:54:42PM +0800, Yu Zhao wrote:
+ list_for_each_entry(pdev, dev-bus-devices, bus_list)
+ if (pdev-sriov)
+ break;
+ if (list_empty(dev-bus-devices) || !pdev-sriov)
+ pdev = NULL;
+ ctrl = 0;
+ if (!pdev pci_ari_enabled(dev-bus))
+ ctrl |= PCI_SRIOV_CTRL_ARI;
+
I don't like this loop. At the end of a list_for_each_entry() loop,
pdev will not be pointing at a pci_device, it'll be pointing to some
offset from dev-bus-devices. So checking pdev-sriov at this point
is really, really bad. I would prefer to see something like this:
ctrl = 0;
list_for_each_entry(pdev, dev-bus-devices, bus_list) {
if (pdev-sriov)
goto ari_enabled;
}
if (pci_ari_enabled(dev-bus))
ctrl = PCI_SRIOV_CTRL_ARI;
ari_enabled:
pci_write_config_word(dev, pos + PCI_SRIOV_CTRL, ctrl);
No, please use bus_for_each_dev() instead, or bus_find_device(), don't
walk the bus list by hand. I'm kind of surprised that even builds. Hm,
in looking at the 2.6.29-rc kernels, I notice it will not even build at
all, you are now forced to use those functions, which is good.
The devices haven't been added at this time, so we can't use
bus_for_each_dev(). I guess that's why the `bus-devices' exists, and
actually pci_bus_add_devices() walks the bus list same way to retrieve
the devices and add them.
ah, this is struct pci_bus, not struct bus_type, my mistake.
sorry for the noise,
greg k-h
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2681442 ] Task Switch causes reboot
Bugs item #2681442, was opened at 2009-03-11 06:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2681442group_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: Julian Stecklina (bliitz) Assigned to: Nobody/Anonymous (nobody) Summary: Task Switch causes reboot Initial Comment: I have a small test kernel that measures some x86 task switching stuff. KVM reboots the virtual machine when my test kernel tries to do a hardware task switch by CALLing a TSS descriptor in the GDT. I have attached an ISO which boots my test kernel. I can provide the source of this, if it's helpful. Output using: kvm -serial stdio -cdrom losysbench.iso losysbench [lots of debugging output] Calling TASK0_2 directly... [VM reboots] Output using kvm -no-kvm -serial stdio -cdrom losysbench.iso: losysbench [lots of debugging output] Calling TASK0_2 directly... 90730 [more stuff, i.e. everything went fine] My system info: Gentoo Linux Intel Core Duo L2400 KVM 84 Vanilla Linux 2.6.29-rc7 i386 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2681442group_id=180599 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [net-next PATCH 1/2] igbvf: add new driver to support 82576 virtual functions
On Tue, 10 Mar 2009 19:09:28 -0700 Jeff Kirsher jeffrey.t.kirs...@intel.com
wrote:
From: Alexander Duyck alexander.h.du...@intel.com
This adds an igbvf driver to handle virtual functions provided
by the igb driver.
The drive-by reader is now wondering what a virtual function is.
...
+#define IGBVF_STAT(m, b) sizeof(((struct igbvf_adapter *)0)-m), \
+ offsetof(struct igbvf_adapter, m), \
+ offsetof(struct igbvf_adapter, b)
+static const struct igbvf_stats igbvf_gstrings_stats[] = {
+ { rx_packets, IGBVF_STAT(stats.gprc, stats.base_gprc) },
+ { tx_packets, IGBVF_STAT(stats.gptc, stats.base_gptc) },
+ { rx_bytes, IGBVF_STAT(stats.gorc, stats.base_gorc) },
+ { tx_bytes, IGBVF_STAT(stats.gotc, stats.base_gotc) },
+ { multicast, IGBVF_STAT(stats.mprc, stats.base_mprc) },
+ { lbrx_bytes, IGBVF_STAT(stats.gorlbc, stats.base_gorlbc) },
+ { lbrx_packets, IGBVF_STAT(stats.gprlbc, stats.base_gprlbc) },
+ { tx_restart_queue, IGBVF_STAT(restart_queue, zero_base) },
+ { rx_long_byte_count, IGBVF_STAT(stats.gorc, stats.base_gorc) },
+ { rx_csum_offload_good, IGBVF_STAT(hw_csum_good, zero_base) },
+ { rx_csum_offload_errors, IGBVF_STAT(hw_csum_err, zero_base) },
+ { rx_header_split, IGBVF_STAT(rx_hdr_split, zero_base) },
+ { alloc_rx_buff_failed, IGBVF_STAT(alloc_rx_buff_failed, zero_base) },
+};
stares at it for a while
It would be clearer if `m' and `b' were (much) more meaningful identifiers.
+#define IGBVF_GLOBAL_STATS_LEN \
+ (sizeof(igbvf_gstrings_stats) / sizeof(struct igbvf_stats))
This is ARRAY_SIZE().
+#define IGBVF_STATS_LEN (IGBVF_GLOBAL_STATS_LEN)
Why does this need to exist?
...
+static int igbvf_set_ringparam(struct net_device *netdev,
+ struct ethtool_ringparam *ring)
+{
+ struct igbvf_adapter *adapter = netdev_priv(netdev);
+ struct igbvf_ring *tx_ring, *tx_old;
+ struct igbvf_ring *rx_ring, *rx_old;
+ int err;
+
+ if ((ring-rx_mini_pending) || (ring-rx_jumbo_pending))
+ return -EINVAL;
+
+ while (test_and_set_bit(__IGBVF_RESETTING, adapter-state))
+ msleep(1);
No timeout needed here? Interrupts might not be working, for example..
+ if (netif_running(adapter-netdev))
+ igbvf_down(adapter);
+
+ tx_old = adapter-tx_ring;
+ rx_old = adapter-rx_ring;
+
+ err = -ENOMEM;
+ tx_ring = kzalloc(sizeof(struct igbvf_ring), GFP_KERNEL);
+ if (!tx_ring)
+ goto err_alloc_tx;
+ /*
+ * use a memcpy to save any previously configured
+ * items like napi structs from having to be
+ * reinitialized
+ */
+ memcpy(tx_ring, tx_old, sizeof(struct igbvf_ring));
+
+ rx_ring = kzalloc(sizeof(struct igbvf_ring), GFP_KERNEL);
+ if (!rx_ring)
+ goto err_alloc_rx;
+ memcpy(rx_ring, rx_old, sizeof(struct igbvf_ring));
+
+ adapter-tx_ring = tx_ring;
+ adapter-rx_ring = rx_ring;
+
+ rx_ring-count = max(ring-rx_pending, (u32)IGBVF_MIN_RXD);
+ rx_ring-count = min(rx_ring-count, (u32)(IGBVF_MAX_RXD));
+ rx_ring-count = ALIGN(rx_ring-count, REQ_RX_DESCRIPTOR_MULTIPLE);
+
+ tx_ring-count = max(ring-tx_pending, (u32)IGBVF_MIN_TXD);
+ tx_ring-count = min(tx_ring-count, (u32)(IGBVF_MAX_TXD));
+ tx_ring-count = ALIGN(tx_ring-count, REQ_TX_DESCRIPTOR_MULTIPLE);
+
+ if (netif_running(adapter-netdev)) {
+ /* Try to get new resources before deleting old */
+ err = igbvf_setup_rx_resources(adapter);
+ if (err)
+ goto err_setup_rx;
+ err = igbvf_setup_tx_resources(adapter);
+ if (err)
+ goto err_setup_tx;
+
+ /*
+ * restore the old in order to free it,
+ * then add in the new
+ */
+ adapter-rx_ring = rx_old;
+ adapter-tx_ring = tx_old;
+ igbvf_free_rx_resources(adapter);
+ igbvf_free_tx_resources(adapter);
+ kfree(tx_old);
+ kfree(rx_old);
That's odd-looking. Why take a copy of rx_old and tx_old when we're
about to free them?
+ adapter-rx_ring = rx_ring;
+ adapter-tx_ring = tx_ring;
+ err = igbvf_up(adapter);
+ if (err)
+ goto err_setup;
+ }
+
+ clear_bit(__IGBVF_RESETTING, adapter-state);
+ return 0;
+err_setup_tx:
+ igbvf_free_rx_resources(adapter);
+err_setup_rx:
+ adapter-rx_ring = rx_old;
+ adapter-tx_ring = tx_old;
+ kfree(rx_ring);
+err_alloc_rx:
+ kfree(tx_ring);
+err_alloc_tx:
+ igbvf_up(adapter);
+err_setup:
+ clear_bit(__IGBVF_RESETTING, adapter-state);
+ return err;
+}
+
...
+static void igbvf_diag_test(struct net_device *netdev,
+struct ethtool_test
