[PATCH] kvm: qemu: ia64 CPUStatebuild fix
From: Jes Sorensen j...@sgi.com
Define CPUState as struct CPUIA64State to avoid compile errors on ia64.
Signed-off-by: Jes Sorensen j...@sgi.com
Signed-off-by: Avi Kivity a...@redhat.com
diff --git a/qemu/target-ia64/cpu.h b/qemu/target-ia64/cpu.h
index 9bad6f6..e002d56 100644
--- a/qemu/target-ia64/cpu.h
+++ b/qemu/target-ia64/cpu.h
@@ -40,13 +40,15 @@
#include cpu-defs.h
#include softfloat.h
+
+#define CPUState struct CPUIA64State
+
typedef struct CPUIA64State {
CPU_COMMON;
uint32_t hflags;
int mp_state;
} CPUIA64State;
-#define CPUState CPUIA64State
#define cpu_gen_code cpu_ia64_gen_code
#define cpu_init cpu_ia64_init
#define cpu_signal_handler cpu_ia64_signal_handler
--
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: stop/start cpus before/after devices
From: Yaniv Kamay ya...@qumranet.com
Stop cpus before devices when stopping the VM, start cpus after devices
when starting VM. Otherwise a vcpu could access a stopped device.
Acked-by: Dor Laor dl...@redhat.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
Signed-off-by: Avi Kivity a...@redhat.com
diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
index 93af6ea..4164368 100644
--- a/qemu/qemu-kvm.c
+++ b/qemu/qemu-kvm.c
@@ -285,7 +285,7 @@ static int all_threads_paused(void)
return 1;
}
-static void pause_all_threads(void)
+void qemu_kvm_pause_all_threads(void)
{
CPUState *penv = first_cpu;
@@ -305,7 +305,7 @@ static void pause_all_threads(void)
qemu_cond_wait(qemu_pause_cond);
}
-static void resume_all_threads(void)
+void qemu_kvm_resume_all_threads(void)
{
CPUState *penv = first_cpu;
@@ -319,14 +319,6 @@ static void resume_all_threads(void)
}
}
-static void kvm_vm_state_change_handler(void *context, int running, int reason)
-{
-if (running)
- resume_all_threads();
-else
- pause_all_threads();
-}
-
static void update_regs_for_sipi(CPUState *env)
{
kvm_arch_update_regs_for_sipi(env);
@@ -371,7 +363,7 @@ static void qemu_kvm_system_reset(void)
{
CPUState *penv = first_cpu;
-pause_all_threads();
+qemu_kvm_pause_all_threads();
qemu_system_reset();
@@ -380,7 +372,7 @@ static void qemu_kvm_system_reset(void)
penv = (CPUState *)penv-next_cpu;
}
-resume_all_threads();
+qemu_kvm_resume_all_threads();
}
static int kvm_main_loop_cpu(CPUState *env)
@@ -466,7 +458,6 @@ int kvm_init_ap(void)
#ifdef TARGET_I386
kvm_tpr_opt_setup();
#endif
-qemu_add_vm_change_state_handler(kvm_vm_state_change_handler, NULL);
signal(SIG_IPI, sig_ipi_handler);
return 0;
@@ -610,7 +601,7 @@ int kvm_main_loop(void)
#endif
}
-pause_all_threads();
+qemu_kvm_pause_all_threads();
pthread_mutex_unlock(qemu_mutex);
return 0;
diff --git a/qemu/qemu-kvm.h b/qemu/qemu-kvm.h
index c0549df..ca59af8 100644
--- a/qemu/qemu-kvm.h
+++ b/qemu/qemu-kvm.h
@@ -119,6 +119,9 @@ int qemu_kvm_register_coalesced_mmio(target_phys_addr_t
addr,
int qemu_kvm_unregister_coalesced_mmio(target_phys_addr_t addr,
unsigned int size);
+void qemu_kvm_pause_all_threads(void);
+void qemu_kvm_resume_all_threads(void);
+
int kvm_coalesce_mmio_region(target_phys_addr_t start, ram_addr_t size);
int kvm_uncoalesce_mmio_region(target_phys_addr_t start, ram_addr_t size);
diff --git a/qemu/vl.c b/qemu/vl.c
index 7ae266e..c52d2d7 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -3596,6 +3596,8 @@ void vm_start(void)
cpu_enable_ticks();
vm_running = 1;
vm_state_notify(1, 0);
+if (kvm_enabled())
+qemu_kvm_resume_all_threads();
qemu_rearm_alarm_timer(alarm_timer);
}
}
@@ -3605,6 +3607,8 @@ void vm_stop(int reason)
if (vm_running) {
cpu_disable_ticks();
vm_running = 0;
+if (kvm_enabled())
+qemu_kvm_pause_all_threads();
vm_state_notify(0, reason);
}
}
--
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: VMX: Correct wrong vmcs field sizes
From: Sheng Yang sh...@linux.intel.com
EXIT_QUALIFICATION and GUEST_LINEAR_ADDRESS are natural width, not 64-bit.
Signed-off-by: Sheng Yang sh...@linux.intel.com
Signed-off-by: Avi Kivity a...@redhat.com
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 37ae13d..aba41ae 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2991,7 +2991,7 @@ static int handle_vmcall(struct kvm_vcpu *vcpu, struct
kvm_run *kvm_run)
static int handle_invlpg(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
{
- u64 exit_qualification = vmcs_read64(EXIT_QUALIFICATION);
+ unsigned long exit_qualification = vmcs_readl(EXIT_QUALIFICATION);
kvm_mmu_invlpg(vcpu, exit_qualification);
skip_emulated_instruction(vcpu);
@@ -3007,11 +3007,11 @@ static int handle_wbinvd(struct kvm_vcpu *vcpu, struct
kvm_run *kvm_run)
static int handle_apic_access(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
{
- u64 exit_qualification;
+ unsigned long exit_qualification;
enum emulation_result er;
unsigned long offset;
- exit_qualification = vmcs_read64(EXIT_QUALIFICATION);
+ exit_qualification = vmcs_readl(EXIT_QUALIFICATION);
offset = exit_qualification 0xffful;
er = emulate_instruction(vcpu, kvm_run, 0, 0, 0);
@@ -3062,11 +3062,11 @@ static int handle_task_switch(struct kvm_vcpu *vcpu,
struct kvm_run *kvm_run)
static int handle_ept_violation(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
{
- u64 exit_qualification;
+ unsigned long exit_qualification;
gpa_t gpa;
int gla_validity;
- exit_qualification = vmcs_read64(EXIT_QUALIFICATION);
+ exit_qualification = vmcs_readl(EXIT_QUALIFICATION);
if (exit_qualification (1 6)) {
printk(KERN_ERR EPT: GPA exceeds GAW!\n);
@@ -3078,7 +3078,7 @@ static int handle_ept_violation(struct kvm_vcpu *vcpu,
struct kvm_run *kvm_run)
printk(KERN_ERR EPT: Handling EPT violation failed!\n);
printk(KERN_ERR EPT: GPA: 0x%lx, GVA: 0x%lx\n,
(long unsigned int)vmcs_read64(GUEST_PHYSICAL_ADDRESS),
- (long unsigned int)vmcs_read64(GUEST_LINEAR_ADDRESS));
+ vmcs_readl(GUEST_LINEAR_ADDRESS));
printk(KERN_ERR EPT: Exit qualification is 0x%lx\n,
(long unsigned int)exit_qualification);
kvm_run-exit_reason = KVM_EXIT_UNKNOWN;
--
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: ia64: hw/ipf.c apic_set_irq_delivered() build fix
From: Jes Sorensen j...@sgi.com
Provide dummy apic_set_irq_delivered() function and update call to
kvm_set_irq() to add extra argument.
Signed-off-by: Jes Sorensen j...@sgi.com
Signed-off-by: Avi Kivity a...@redhat.com
diff --git a/qemu/hw/ipf.c b/qemu/hw/ipf.c
index e2b53ee..5ed2667 100644
--- a/qemu/hw/ipf.c
+++ b/qemu/hw/ipf.c
@@ -687,9 +687,15 @@ static int ioapic_map_irq(int devfn, int irq_num)
return irq;
}
+/*
+ * Dummy function to provide match for call from hw/apic.c
+ */
+void apic_set_irq_delivered(void) {
+}
+
void ioapic_set_irq(void *opaque, int irq_num, int level)
{
-int vector;
+int vector, pic_ret;
PCIDevice *pci_dev = (PCIDevice *)opaque;
vector = ioapic_map_irq(pci_dev-devfn, irq_num);
@@ -700,7 +706,9 @@ void ioapic_set_irq(void *opaque, int irq_num, int level)
ioapic_irq_count[vector] -= 1;
if (kvm_enabled()) {
- if (kvm_set_irq(vector, ioapic_irq_count[vector] == 0))
+ if (kvm_set_irq(vector, ioapic_irq_count[vector] == 0, pic_ret))
+if (pic_ret != 0)
+apic_set_irq_delivered();
return;
}
}
--
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 Port
do we have to port qemu as well? On Thu, Mar 26, 2009 at 7:22 AM, Liu Yu-B13201 yu@freescale.com wrote: IMHO, one thing you should keep in mind is how to isolate the guest space based on your hardware MMU. And then deal with the exceptions carefully, some may be directly send to guest and some should be handled by hypervisor. In powerpc BOOKE implementation, we have to hijack all exceptions, because BOOKE doesn't support technic like VT. -Original Message- From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of kvm port Sent: Wednesday, March 25, 2009 11:08 PM To: kvm@vger.kernel.org; kvm-...@vger.kernel.org Subject: KVM Port Hi KVM Gurus, We have a EVB with a fpga based RISC processor with VT support. As a proof of concept i have to port KVM onto it. we have run linux as of now. can anyof u help with how should i begin -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 Port
Yes. At least, you need an application to launch VM. It's helpful to use qemu to emulate the I/O. But if your hardware support the technic like iommu, you can move the part into KVM for better performance. -Original Message- From: kvm port [mailto:kvmp...@gmail.com] Sent: Thursday, March 26, 2009 2:03 PM To: Liu Yu-B13201 Cc: kvm@vger.kernel.org; kvm-...@vger.kernel.org Subject: Re: KVM Port do we have to port qemu as well? On Thu, Mar 26, 2009 at 7:22 AM, Liu Yu-B13201 yu@freescale.com wrote: IMHO, one thing you should keep in mind is how to isolate the guest space based on your hardware MMU. And then deal with the exceptions carefully, some may be directly send to guest and some should be handled by hypervisor. In powerpc BOOKE implementation, we have to hijack all exceptions, because BOOKE doesn't support technic like VT. -Original Message- From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of kvm port Sent: Wednesday, March 25, 2009 11:08 PM To: kvm@vger.kernel.org; kvm-...@vger.kernel.org Subject: KVM Port Hi KVM Gurus, We have a EVB with a fpga based RISC processor with VT support. As a proof of concept i have to port KVM onto it. we have run linux as of now. can anyof u help with how should i begin -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: Luvalley project: running KVM without Linux
Yes, we belong to the Operating System Engineering Research Center in China. Any message or advice is welcome. Currently, Luvalley is just an infant. We will do our best to make it grow if it is valuable and interesting. Thanks for your attention. Best regards, Xiaodong 2009/3/26 Sheng Yang sh...@linux.intel.com: On Thursday 26 March 2009 11:56:20 Jun Koi wrote: Very cool! Who is behind this project? Intel? Not us... According to http://lists.centos.org/pipermail/centos-promo/2009- February/000402.html, it is the Operating System Engineering Research Center in China. -- regards Yang, Sheng I will give it a try! Thanks, Jun On Thu, Mar 26, 2009 at 12:20 PM, Xiaodong Yi xdong...@gmail.com wrote: Luvalley is a Virtual Machine Monitor (VMM) spawned from the KVM project. Its part of source codes are derived from KVM to virtualize CPU instructions and memory management unit (MMU). However, its overall architecture is completely different from KVM, but somewhat like Xen. Luvalley runs outside of Linux, just like Xen's architecture, but it still uses Linux as its scheduler, memory manager, physical device driver provider and virtual IO device emulator. Moreover, Luvalley may run WITHOUT Linux. In theory, any operating system could take the place of Linux to provide the above services. Currently, Luvalley supports Linux and Windows. That is to say, one may run Luvalley to boot a Linux or Windows, and then run multiple virtualized operating systems on such Linux or Windows. If you are interested in Luvalley project, you may download the source codes from http://sourceforge.net/projects/luvalley/ The following is more details about Luvalley. Luvalley is an external hypervisor, just like Xen (http://www.xen.org). It boots and controls the X86 machine before starting up any operating system. However, Luvalley is much smaller and simpler than Xen. Most jobs of Xen, such as scheduling, memory management, interrupt management, etc, are shifted to Linux (or any other OS), which is running on top of Luvalley. Luvalley gets booted first when the X86 machine is power on. It boots up all CPUs in SMP system and enables their virtualization extensions. Then the MBR (Master Boot Record) is read out and executed in CPU's virtualization mode. Following this way, a Linux (or any other OS) will be booted up at last. Luvalley assigns all physical memory, programmable interrupt controller (PIC) and IO devices to this priviledged OS. Following Xen, we call this OS as domain 0 (dom0) OS. Like KVM, a modified Qemu is running on dom0 Linux to provide virtual IO devices for other operating systems running on top of Luvalley. We also follow Xen to call these operating systems domain user (domU). That is to say, there must be exact one dom0 OS and may be several domU OSs running on top of Luvalley. Each domU OS corresponds to a Qemu process in dom0 OS. The memory of domU is allocated from dom0 by Qemu. And when Qemu is scheduled to run by dom0 Scheduler, it will call Luvalley to run the corresponding domU. Moreover, as Luvalley requires nothing from the dom0 Linux kernel, other operating systems such as Windows, FreeBSD, etc can also serve as dom0 OS, provided that Qemu can be ported to these operating systems. Since Qemu is an userland application and is able to cross platform, such porting is feasible. Currently, we have added the Luvalley support into Qemu-0.10.0, which can be compiled and run in Windows. With the help of Luvalley, Qemu-0.10.0 runs much faster becuase it could utilize the VT support provided by Intel CPU. In summary, Luvalley inherited all merits from KVM. Especially, Luvalley is very small and simple. It is even more easy-to-use than KVM because it does not depend on specific Linux kernel version. Every version of Linux can serve as Luvalley's dom0 OS, except that Qemu cannot run on it. In addition, we think Luvalley's architecture meets the demand on both desktop and server operating system area: 1. In the desktop area, there are many kinds of operating systems runing on various hardwares and devices. In theory, it is rather easy to add virtualization ability for all kinds of operating systems, without sacrificing the hardware compatibility and the user experience. Moreover, Luvalley is very easy to install. It requires only a boot loader which supports Multiboot Specification, e.g., Grub, WinGrub (http://sourceforge.net/projects/grub4dos), etc. 2. In the server area, especially for large-scale server systems (for example, throusands of CPUs), a single Linux is not suitable to manage the whole system. Therefore, KVM cannot be used properly. Luvalley's architecture is more suitable for servers. For example, it can be used to divide physical resources to partitions, and run a Linux for each partition. In addition, Luvalley is very small and may
[PATCH] KVM: Fix one line MMU comment
From: Eddie Dong eddie.d...@intel.com The original one is for the code before reconstruct. Signed-off-by: Yaozu (Eddie) Dong eddie.d...@intel.com Signed-off-by: Sheng Yang sh...@linux.intel.com --- arch/x86/kvm/paging_tmpl.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h index 855eb71..eae9499 100644 --- a/arch/x86/kvm/paging_tmpl.h +++ b/arch/x86/kvm/paging_tmpl.h @@ -379,7 +379,7 @@ static int FNAME(page_fault)(struct kvm_vcpu *vcpu, gva_t addr, return r; /* -* Look up the shadow pte for the faulting address. +* Look up the guest pte for the faulting address. */ r = FNAME(walk_addr)(walker, vcpu, addr, write_fault, user_fault, fetch_fault); -- 1.5.4.5 -- 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] KVM: Fix one line MMU comment
Sheng Yang wrote: From: Eddie Dong eddie.d...@intel.com The original one is for the code before reconstruct. 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Split kvm source tarballs
On Wed, Mar 25, 2009 at 04:34:31PM -0500, Anthony Liguori wrote: But if you created a qemu-svn-stable branch that followed the QEMU stable tree in kvm-userspace, like the qemu-cvs branch follows trunk, then it would be pretty easy to create and maintain a kvm_stable_0_10 branch of whatever you'd like to call it in kvm-userspace. Any chance you could do this? I suspect it's just a matter of creating the branch based off of the qemu-cvs tree at dde and then doing a git-svn fetch. Slightly offtopic, but I always wondered why qemu is hosted in svn. For all project having semi-forks of qemu that they try to keep in sync or even merge back a distributed scm would work so much better. -- 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] KVM: IA64: enable external interrupt in vmm
Zhang, Yang wrote: From 2cf75eff171ef823b3b17c945504d0233a6bd427 Mon Sep 17 00:00:00 2001 From: Yang Zhang yang.zh...@intel.com Date: Mon, 23 Mar 2009 03:31:04 -0400 Subject: [PATCH] KVM: IA64: enable external interrupt in vmm In the previous version, the interrupt bit is cleared when in the vmm. This patch opens the bit and the externanl interrupt can be deal with when in the vmm. It will improve the I/O performance. 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] kvm: qemu: add warning message when assign device without IOMMU
When user wants to assign device with IOMMU, but IOMMU is not
enabled, add warning messages to prompt user this situation, and
return error. Or device will be assigned but it cannot work.
Signed-off-by: Weidong Han weidong@intel.com
---
qemu/hw/device-assignment.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/qemu/hw/device-assignment.c b/qemu/hw/device-assignment.c
index b7f9fa6..cef7c8a 100644
--- a/qemu/hw/device-assignment.c
+++ b/qemu/hw/device-assignment.c
@@ -616,6 +616,11 @@ static int assign_device(AssignedDevInfo *adev)
r = kvm_check_extension(kvm_context, KVM_CAP_IOMMU);
if (r !adev-disable_iommu)
assigned_dev_data.flags |= KVM_DEV_ASSIGN_ENABLE_IOMMU;
+else if (!adev-disable_iommu r == 0) {
+ fprintf(stderr, IOMMU is not enabled. You cannot use
+it to assign device!\n);
+ return -EINVAL;
+}
#endif
r = kvm_assign_pci_device(kvm_context, assigned_dev_data);
--
1.6.0.4
0001-kvm-qemu-add-warning-message-when-assign-device-wi.patch
Description: 0001-kvm-qemu-add-warning-message-when-assign-device-wi.patch
Re: Split kvm source tarballs
Christoph Hellwig wrote: - move qemu to the root of the repository, and reparent libkvm/ user/ and friends under it. this will give us easier merging. Yeah. While you're at it user/ might be renamed to something more descriptive. The subdirectory test/ under it can be ported to run under qemu and contributed into qemu's test suite. - move the external module kit into kvm.git As in your kvm development kernel tree? Not sure it's a good idea to suck this into a full kernel tree. Probably worth making it a small repository of it's own. If the repo contains only the kit (external-module.h and the hack scripts) we'll be left with dual repositories with their confusion and unbisectability. If the repo contains both the kit and the code, I'll need to commit every kvm.git change into that repository, which I'm sure to botch now and then. Do you see any specific problem with dropping kvm-userspace.git/kernel/* under kvm.git/scripts/kvm/? -- 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
[PATCH 2/2] kvm: qemu: check device assignment command
Device assignment command is like -pcidevice host=xx:yy.z.
Check bus:dev.func length to make sure its format is xx:yy.z.
Signed-off-by: Weidong Han weidong@intel.com
---
qemu/hw/device-assignment.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/qemu/hw/device-assignment.c b/qemu/hw/device-assignment.c
index cef7c8a..50a0d5c 100644
--- a/qemu/hw/device-assignment.c
+++ b/qemu/hw/device-assignment.c
@@ -1196,7 +1196,7 @@ out:
AssignedDevInfo *add_assigned_device(const char *arg)
{
char *cp, *cp1;
-char device[8];
+char device[9];
char dma[6];
int r;
AssignedDevInfo *adev;
@@ -1207,6 +1207,9 @@ AssignedDevInfo *add_assigned_device(const char *arg)
return NULL;
}
r = get_param_value(device, sizeof(device), host, arg);
+/* b:d.f format: xx:yy.z */
+if (r != 7)
+goto bad;
r = get_param_value(adev-name, sizeof(adev-name), name, arg);
if (!r)
snprintf(adev-name, sizeof(adev-name), %s, device);
--
1.6.0.4
0002-kvm-qemu-check-device-assignment-command.patch
Description: 0002-kvm-qemu-check-device-assignment-command.patch
Re: kvm: qemu: stop/start cpus before/after devices
Marcelo Tosatti wrote: On Wed, Mar 25, 2009 at 11:26:19AM -0300, Marcelo Tosatti wrote: On Wed, Mar 25, 2009 at 01:45:52PM +0200, Avi Kivity wrote: Marcelo Tosatti wrote: From: Yaniv Kamay ya...@qumranet.com Stop cpus before devices when stopping the VM, start cpus after devices when starting VM. Why is this needed? A vcpu could access a stopped device otherwise. Actually on vm_stop its safe because the order happens to be correct, but on vm_start its the other way around (vcpus start first, and they should be started last). But, we are holding qemu_mutex. How can vcpus access the devices? -- 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: Split kvm source tarballs
Anthony Liguori wrote: Hi Avi, I spent some time today putting together an approximation of the KVM stable release based on QEMU 0.10.x. In principle, it's not too bad at all because it's just a matter of creating a branch in kvm-userspace that's based a kvm commit sometime after the QEMU 0.10.x release but before the next qemu-cvs merge you did that happened post QEMU 0.10.x. Basically, it was a merge of 72ee81f and dde. The problem for me is pulling in the QEMU stable fixes. You don't have a branch that tracks the QEMU stable tree and I can pull in the QEMU stable git tree without rewriting history since the directory layout is different. But if you created a qemu-svn-stable branch that followed the QEMU stable tree in kvm-userspace, like the qemu-cvs branch follows trunk, then it would be pretty easy to create and maintain a kvm_stable_0_10 branch of whatever you'd like to call it in kvm-userspace. Any chance you could do this? I suspect it's just a matter of creating the branch based off of the qemu-cvs tree at dde and then doing a git-svn fetch. I pushed this under the old naming convention, as kvm-userspace.git maint/2.6.30. I'll rename it once I convert the repo. -- 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: IO on guest is 20 times slower than host
Kurt Yoder wrote: I see. I looked up another test: using hdparm -t. It doesn't show the situation as quite so bad, but the guest is still a little over half the speed of the host: m...@host:~$ sudo hdparm -t /dev/mapper/HW_RAID-ROOT /dev/mapper/HW_RAID-ROOT: Timing buffered disk reads: 282 MB in 3.00 seconds = 93.92 MB/sec m...@guest:~# hdparm -t /dev/vda /dev/vda: Timing buffered disk reads: 156 MB in 3.03 seconds = 51.56 MB/sec This is reasonable. IDE emulation is not expected to be as fast as the host. Something weird is happening with your system. If you extend the test, what does 'top' show? On both guest and host. If I extend the test thusly on the guest: dd if=/dev/zero of=/bigfile count=1000 I see 100% CPU utilization on the guest, and 100% CPU utilization on one of the host cores. Can you post 'vmstat 1' snippets on both guest and host while this is running? Oh, and try switching to the deadline I/O scheduler on the host instead of the default cfq. -- 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: KVM Port
AFAIK KVM userspace app creates a VM using /dev/kvm. Now if IO has a MMU managed by KVM arch module, do i still need qemu? On Thu, Mar 26, 2009 at 12:03 PM, Liu Yu-B13201 yu@freescale.com wrote: Yes. At least, you need an application to launch VM. It's helpful to use qemu to emulate the I/O. But if your hardware support the technic like iommu, you can move the part into KVM for better performance. -Original Message- From: kvm port [mailto:kvmp...@gmail.com] Sent: Thursday, March 26, 2009 2:03 PM To: Liu Yu-B13201 Cc: kvm@vger.kernel.org; kvm-...@vger.kernel.org Subject: Re: KVM Port do we have to port qemu as well? On Thu, Mar 26, 2009 at 7:22 AM, Liu Yu-B13201 yu@freescale.com wrote: IMHO, one thing you should keep in mind is how to isolate the guest space based on your hardware MMU. And then deal with the exceptions carefully, some may be directly send to guest and some should be handled by hypervisor. In powerpc BOOKE implementation, we have to hijack all exceptions, because BOOKE doesn't support technic like VT. -Original Message- From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of kvm port Sent: Wednesday, March 25, 2009 11:08 PM To: kvm@vger.kernel.org; kvm-...@vger.kernel.org Subject: KVM Port Hi KVM Gurus, We have a EVB with a fpga based RISC processor with VT support. As a proof of concept i have to port KVM onto it. we have run linux as of now. can anyof u help with how should i begin -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 Port
kvm port wrote: AFAIK KVM userspace app creates a VM using /dev/kvm. Now if IO has a MMU managed by KVM arch module, do i still need qemu? qemu is needed to allocate memory, and to emulate devices. For example the IDE disk controller is implemented in 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
Re: [PATCH 1/2] kvm: qemu: add warning message when assign device without IOMMU
Han, Weidong wrote: When user wants to assign device with IOMMU, but IOMMU is not enabled, add warning messages to prompt user this situation, and return error. Or device will be assigned but it cannot work. If the device has does not do DMA (say a serial port) then it can be assigned. Can we check the device for dma capability and allow this special case? -- 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: [PATCH 2/2] kvm: qemu: check device assignment command
Han, Weidong wrote:
Device assignment command is like -pcidevice host=xx:yy.z.
Check bus:dev.func length to make sure its format is xx:yy.z.
Signed-off-by: Weidong Han weidong@intel.com
---
qemu/hw/device-assignment.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/qemu/hw/device-assignment.c b/qemu/hw/device-assignment.c
index cef7c8a..50a0d5c 100644
--- a/qemu/hw/device-assignment.c
+++ b/qemu/hw/device-assignment.c
@@ -1196,7 +1196,7 @@ out:
AssignedDevInfo *add_assigned_device(const char *arg)
{
char *cp, *cp1;
-char device[8];
+char device[9];
char dma[6];
int r;
AssignedDevInfo *adev;
@@ -1207,6 +1207,9 @@ AssignedDevInfo *add_assigned_device(const char *arg)
return NULL;
}
r = get_param_value(device, sizeof(device), host, arg);
+/* b:d.f format: xx:yy.z */
+if (r != 7)
+goto bad;
r = get_param_value(adev-name, sizeof(adev-name), name, arg);
if (!r)
snprintf(adev-name, sizeof(adev-name), %s, device);
I suggest replacing the parsing code with pci_parse_devaddr() (needs to
be extended to support functions) so that all the checking and parsing
is done in one place.
--
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
[patch] kvm-userland vl.c compiler warning
Hi, A minor cosmetic fix to tell the compiler to shut up by including the header providing the prototype for dma_helper_init(). Cheers, Jes vl.c needs to include dma.h which provides the prototype for dma_helper_init() to avoid a compiler warning. Signed-off-by: Jes Sorensen j...@sgi.com --- qemu/vl.c |1 + 1 file changed, 1 insertion(+) Index: kvm-userspace.git/qemu/vl.c === --- kvm-userspace.git.orig/qemu/vl.c +++ kvm-userspace.git/qemu/vl.c @@ -154,6 +154,7 @@ #include kvm.h #include balloon.h #include qemu-kvm.h +#include dma.h #include hw/device-assignment.h #include disas.h
Re: Live memory allocation?
Evert schrieb: Hi all, According to the Wikipedia ( http://en.wikipedia.org/wiki/Comparison_of_platform_virtual_machines ) both VirtualBox VMware server support something called 'Live memory allocation'. Does KVM support this as well? What does this term mean exactly? Is it the same as ballooning used by KVM? -- Tomasz Chmielewski http://wpkg.org -- 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: Live memory allocation?
Tomasz Chmielewski wrote: Evert schrieb: Hi all, According to the Wikipedia ( http://en.wikipedia.org/wiki/Comparison_of_platform_virtual_machines ) both VirtualBox VMware server support something called 'Live memory allocation'. Does KVM support this as well? What does this term mean exactly? Is it the same as ballooning used by KVM? I guess it referring to memory allocation on first time access to the memory areas, Meaning the memory allocation will be made only when it really going to be used. (But this is just a guess) -- 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: Live memory allocation?
Izik Eidus schrieb: Tomasz Chmielewski wrote: Evert schrieb: Hi all, According to the Wikipedia ( http://en.wikipedia.org/wiki/Comparison_of_platform_virtual_machines ) both VirtualBox VMware server support something called 'Live memory allocation'. Does KVM support this as well? What does this term mean exactly? Is it the same as ballooning used by KVM? I guess it referring to memory allocation on first time access to the memory areas, Meaning the memory allocation will be made only when it really going to be used. Like, two guests, each with 2 GB memory allocated only use 1 GB of host's memory (as long as they don't have many programs/buffers/cache)? So yes, it's also supported by KVM. -- Tomasz Chmielewski http://wpkg.org -- 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
guest to guest communications
Hi!
I hope this is the proper mailing list. If not please tell me
where do I post my question. I have been attempting to create a setup
with a host debian (Lenny) system and currently two centos guest. I have
managed to get everything working except network communications between
my two guest. I can event login into the proper guest from my host. If
you need tcpdumps and/or arp results I can provide them. Thank you.
Here is my network configuration script.
---
#!/bin/sh
count=4
case $1 in
start)
brctl addbr br0
ifconfig br0 192.168.1.1 netmask 255.255.255.0 up
for i in `seq 0 $count`
do
j=$(($i+100));
tunctl -b -u uja -t tap$i
brctl addif br0 tap$i
ifconfig tap$i up 0.0.0.0 promisc
#route add -host 192.168.1.$j gw 192.168.1.1 dev
br0
done
#route add -net 192.168.1.0 netmask 255.255.255.0 gw
192.168.1.1
dev br0
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
;;
stop)
killall kvm
iptables --flush
iptables --table nat --flush
iptables --delete-chain
iptables --table nat --delete-chain
route del -net 192.168.1.0 netmask 255.255.255.0 dev br0
for i in `seq 0 $count`
do
ifconfig tap$i down
brctl delif br0 tap$i
tunctl -d tap$i
done
ifconfig br0 down
brctl delbr br0
;;
*)
echo Usage: $0 start|stop 2
exit 3
;;
esac
-
This is the commands I use to start my kvm instants.
macaddr=$(/sbin/ifconfig tap0 | grep HWaddr | awk -F ' ' '{print $5}')
kvm -name mds -no-acpi -hda $HOME/work/image1.img -net nic,macaddr=$macaddr
-net tap,ifname=tap0,script=no,downscript=no
macaddr=$(/sbin/ifconfig tap1 | grep HWaddr | awk -F ' ' '{print $5}')
kvm -name oss -no-acpi -hda $HOME/work/image2.img -net nic,macaddr=$macaddr
-net tap,ifname=tap1,script=no,downscript=no
--
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: qemu: stop/start cpus before/after devices
On Thu, Mar 26, 2009 at 12:03:30PM +0200, Avi Kivity wrote: Marcelo Tosatti wrote: On Wed, Mar 25, 2009 at 11:26:19AM -0300, Marcelo Tosatti wrote: On Wed, Mar 25, 2009 at 01:45:52PM +0200, Avi Kivity wrote: Marcelo Tosatti wrote: From: Yaniv Kamay ya...@qumranet.com Stop cpus before devices when stopping the VM, start cpus after devices when starting VM. Why is this needed? A vcpu could access a stopped device otherwise. Actually on vm_stop its safe because the order happens to be correct, but on vm_start its the other way around (vcpus start first, and they should be started last). But, we are holding qemu_mutex. How can vcpus access the devices? You're right, they can't. But its not bad to make it explicit, instead of relying on the locking behaviour? -- 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: how about performance?
Since it is almost impossible to find any KVM related number on real world workloads, it would be good to know why. Is it due to KVM still being in heavy developement? First off, you would have to use the same hardware to do a good comparison. Second, since setting up KVM is not that time consuming or difficult, one could argue that, keeping in mind that the person asking for the performance is looking for an alternative solution, yout could do the benchmarks yourself. Third, since open source programs in general are not aimed at gaining wealth through the distribution of the software itself, providing industry standard (and often senseless) benchmark results is not very high on everyones list of priorities. My 2 cents. -- Mit freundlichen Grüßen, Andreas OlsowskiSystem- und Netzwerktechnik Sysadmin extraordinaire -- 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: Live memory allocation?
Tomasz Chmielewski wrote: Izik Eidus schrieb: Tomasz Chmielewski wrote: Evert schrieb: Hi all, According to the Wikipedia ( http://en.wikipedia.org/wiki/Comparison_of_platform_virtual_machines ) both VirtualBox VMware server support something called 'Live memory allocation'. Does KVM support this as well? What does this term mean exactly? Is it the same as ballooning used by KVM? I guess it referring to memory allocation on first time access to the memory areas, Meaning the memory allocation will be made only when it really going to be used. Like, two guests, each with 2 GB memory allocated only use 1 GB of host's memory (as long as they don't have many programs/buffers/cache)? So yes, it's also supported by KVM. I have amended http://en.wikipedia.org/wiki/Comparison_of_platform_virtual_machines based on this thread :-) Greetings, Evert -- 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: Split kvm source tarballs
Avi Kivity wrote: Anthony Liguori wrote: Hi Avi, I spent some time today putting together an approximation of the KVM stable release based on QEMU 0.10.x. In principle, it's not too bad at all because it's just a matter of creating a branch in kvm-userspace that's based a kvm commit sometime after the QEMU 0.10.x release but before the next qemu-cvs merge you did that happened post QEMU 0.10.x. Basically, it was a merge of 72ee81f and dde. The problem for me is pulling in the QEMU stable fixes. You don't have a branch that tracks the QEMU stable tree and I can pull in the QEMU stable git tree without rewriting history since the directory layout is different. But if you created a qemu-svn-stable branch that followed the QEMU stable tree in kvm-userspace, like the qemu-cvs branch follows trunk, then it would be pretty easy to create and maintain a kvm_stable_0_10 branch of whatever you'd like to call it in kvm-userspace. Any chance you could do this? I suspect it's just a matter of creating the branch based off of the qemu-cvs tree at dde and then doing a git-svn fetch. I pushed this under the old naming convention, as kvm-userspace.git maint/2.6.30. I'll rename it once I convert the repo. Sweet, thanks! Regards, Anthony Liguori -- 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: Split kvm source tarballs
Christoph Hellwig wrote: On Wed, Mar 25, 2009 at 04:34:31PM -0500, Anthony Liguori wrote: But if you created a qemu-svn-stable branch that followed the QEMU stable tree in kvm-userspace, like the qemu-cvs branch follows trunk, then it would be pretty easy to create and maintain a kvm_stable_0_10 branch of whatever you'd like to call it in kvm-userspace. Any chance you could do this? I suspect it's just a matter of creating the branch based off of the qemu-cvs tree at dde and then doing a git-svn fetch. Slightly offtopic, but I always wondered why qemu is hosted in svn. For all project having semi-forks of qemu that they try to keep in sync or even merge back a distributed scm would work so much better. I'm going to switch it to git fwiw. Regards, Anthony Liguori -- 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 + virt-manager: which is the perfect host Linux distro?
Hi all, I am about to install a new host system, which will be hosting various guest systems by means of KVM virt-manager for GUI. What would be the best choice for host OS distro? Red Hat, or will any mature Linux distro do? Personally I am more of a Gentoo guy, but if there is 1 distro which is clearly better as host OS when it comes to KVM+virt-manager, I am willing to use something else... ;-) Regards, Evert -- 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: guest to guest communications
On Thursday 26 March 2009 11:30:29 James Simmons wrote:
Hi!
I hope this is the proper mailing list. If not please tell me
where do I post my question. I have been attempting to create a setup
with a host debian (Lenny) system and currently two centos guest. I have
managed to get everything working except network communications between
my two guest. I can event login into the proper guest from my host. If
you need tcpdumps and/or arp results I can provide them. Thank you.
Here is my network configuration script.
---
#!/bin/sh
count=4
case $1 in
start)
brctl addbr br0
ifconfig br0 192.168.1.1 netmask 255.255.255.0 up
for i in `seq 0 $count`
do
j=$(($i+100));
tunctl -b -u uja -t tap$i
brctl addif br0 tap$i
ifconfig tap$i up 0.0.0.0 promisc
#route add -host 192.168.1.$j gw 192.168.1.1 dev
br0
done
#route add -net 192.168.1.0 netmask 255.255.255.0 gw
192.168.1.1
dev br0
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
;;
stop)
killall kvm
iptables --flush
iptables --table nat --flush
iptables --delete-chain
iptables --table nat --delete-chain
route del -net 192.168.1.0 netmask 255.255.255.0 dev br0
for i in `seq 0 $count`
do
ifconfig tap$i down
brctl delif br0 tap$i
tunctl -d tap$i
done
ifconfig br0 down
brctl delbr br0
;;
*)
echo Usage: $0 start|stop 2
exit 3
;;
esac
---
--
This is the commands I use to start my kvm instants.
macaddr=$(/sbin/ifconfig tap0 | grep HWaddr | awk -F ' ' '{print $5}')
kvm -name mds -no-acpi -hda $HOME/work/image1.img -net nic,macaddr=$macaddr
-net tap,ifname=tap0,script=no,downscript=no
This means you'll have 2 devices on your network with the same mac. The tap
device and the guest.
macaddr=$(/sbin/ifconfig tap1 | grep HWaddr | awk -F ' ' '{print $5}')
kvm -name oss -no-acpi -hda $HOME/work/image2.img -net nic,macaddr=$macaddr
-net tap,ifname=tap1,script=no,downscript=no
--
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
--
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 + virt-manager: which is the perfect host Linux distro?
Evert schrieb: Hi all, I am about to install a new host system, which will be hosting various guest systems by means of KVM virt-manager for GUI. What would be the best choice for host OS distro? Red Hat, or will any mature Linux distro do? Personally I am more of a Gentoo guy, but if there is 1 distro which is clearly better as host OS when it comes to KVM+virt-manager, I am willing to use something else... ;-) Did you try this one: http://pve.proxmox.com/wiki/Main_Page It's Debian based and have everything you need for virtualisation already prepared. -- Tomasz Chmielewski http://wpkg.org -- 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 + virt-manager: which is the perfect host Linux distro?
Tomasz Chmielewski wrote: Evert schrieb: Hi all, I am about to install a new host system, which will be hosting various guest systems by means of KVM virt-manager for GUI. What would be the best choice for host OS distro? Red Hat, or will any mature Linux distro do? Personally I am more of a Gentoo guy, but if there is 1 distro which is clearly better as host OS when it comes to KVM+virt-manager, I am willing to use something else... ;-) Did you try this one: http://pve.proxmox.com/wiki/Main_Page It's Debian based and have everything you need for virtualisation already prepared. To my knowledge Proxmox does not support software RAID ( http://www.linux-kvm.com/content/kvm-83-released-support-amd-iommu-qemu-svn-merge ), unless you configure that manually... Otherwise Proxmox is promising, yes... Can I conclude from that that Debian is the best host distro to go for? Better than Red Hat Gentoo? Regards, Evert -- 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: Split kvm source tarballs
On Thu, Mar 26, 2009 at 11:09:07AM +0200, Avi Kivity wrote: If the repo contains only the kit (external-module.h and the hack scripts) we'll be left with dual repositories with their confusion and unbisectability. If the repo contains both the kit and the code, I'll need to commit every kvm.git change into that repository, which I'm sure to botch now and then. Do you see any specific problem with dropping kvm-userspace.git/kernel/* under kvm.git/scripts/kvm/? Adding more stuff to a kernel tree that doesn't apply to building that tree seems rather odd. But if it makes your life easier go for it, it's defintively much better than the current setup. -- 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: Split kvm source tarballs
On Thu, Mar 26, 2009 at 01:19:46PM -0500, Anthony Liguori wrote: Slightly offtopic, but I always wondered why qemu is hosted in svn. For all project having semi-forks of qemu that they try to keep in sync or even merge back a distributed scm would work so much better. I'm going to switch it to git fwiw. If it's soon enough maybe the kvm repository reorganization should wait for it so that the new repository can be cloned from upstream qemu? -- 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 v12 1/8] PCI: initialize and release SR-IOV capability
On Sat, 21 Mar 2009 22:05:11 +0800 Yu Zhao yu.z...@intel.com wrote: On Sat, Mar 21, 2009 at 01:54:09AM +0800, Jesse Barnes wrote: On Fri, 20 Mar 2009 11:25:11 +0800 Yu Zhao yu.z...@intel.com wrote: If a device has the SR-IOV capability, initialize it (set the ARI Capable Hierarchy in the lowest numbered PF if necessary; calculate the System Page Size for the VF MMIO, probe the VF Offset, Stride and BARs). A lock for the VF bus allocation is also initialized if a PF is the lowest numbered PF. Reviewed-by: Matthew Wilcox wi...@linux.intel.com Signed-off-by: Yu Zhao yu.z...@intel.com I applied this series to my linux-next branch, but there were a few conflicts here and there, so please check it out. Looks like from start to finish this took about 6 months to get banged into shape, thanks for staying on it, Yu! Yes, I checked them and found there is conflict between the SR-IOV changes and Yinghai's 'PCI/x86: detect host bridge config space size w/o using quirks'. Following is the fix, thanks! New pci_cfg_space_size() needs invalid pdev-class, put it in the right place in the pci_setup_device(). Signed-off-by: Yu Zhao yu.z...@intel.com Applied, thanks Yu. -- Jesse Barnes, Intel Open Source 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: [PATCH v4 0/6] PCI: support the ATS capability
On Mon, 23 Mar 2009 15:58:56 +0800 Yu Zhao yu.z...@intel.com wrote: This patch series implements Address Translation Service support for the Intel IOMMU. The PCIe Endpoint that supports ATS capability can request the DMA address translation from the IOMMU and cache the translation itself. This can alleviate IOMMU TLB pressure and improve the hardware performance in the I/O virtualization environment. The ATS is one of PCI-SIG I/O Virtualization (IOV) Specifications. The spec can be found at: http://www.pcisig.com/specifications/iov/ats/ (it requires membership). Changelog: v3 - v4 1, coding style fixes (Grant Grundler) 2, support the Virtual Function ATS capability v2 - v3 1, throw error message if VT-d hardware detects invalid descriptor on Queued Invalidation interface (David Woodhouse) 2, avoid using pci_find_ext_capability every time when reading ATS Invalidate Queue Depth (Matthew Wilcox) v1 - v2 added 'static' prefix to a local LIST_HEAD (Andrew Morton) This is a good sized chunk of new code, and you want it to come through the PCI tree, right? It looks like it's seen some review from Grant, David and Matthew but I don't see any Reviewed-by or Acked-by tags in there... Anyone willing to provide those? Thanks, -- Jesse Barnes, Intel Open Source 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: Split kvm source tarballs
Christoph Hellwig wrote: On Thu, Mar 26, 2009 at 01:19:46PM -0500, Anthony Liguori wrote: Slightly offtopic, but I always wondered why qemu is hosted in svn. For all project having semi-forks of qemu that they try to keep in sync or even merge back a distributed scm would work so much better. I'm going to switch it to git fwiw. If it's soon enough maybe the kvm repository reorganization should wait for it so that the new repository can be cloned from upstream qemu? It'll be compatible with the kernel.org git tree so there's no need to wait. Regards, Anthony Liguori -- 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 1/2] kvm: qemu: add warning message when assign device without IOMMU
Avi Kivity wrote: Han, Weidong wrote: When user wants to assign device with IOMMU, but IOMMU is not enabled, add warning messages to prompt user this situation, and return error. Or device will be assigned but it cannot work. If the device has does not do DMA (say a serial port) then it can be assigned. Can we check the device for dma capability and allow this special case? Do you have any hint to check it? This warning be triggered only when user wants to assign device with IOMMU. If user doesn't want to use IOMMU to assign device, he can use -pcidevice host=xx:yy.z,dma=none. Regards, Weidong -- 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: Qemu: Do not use log dirty in IA64
hi please checkin it to kvm85, thanks! IA64 does not support log dirty. We should not use it in IA64, or it will have some problem. Signed-off-by: Yang Zhang yang.zh...@intel.com --- qemu/qemu-kvm.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c index 4164368..ed76367 100644 --- a/qemu/qemu-kvm.c +++ b/qemu/qemu-kvm.c @@ -1374,7 +1374,10 @@ int kvm_log_start(target_phys_addr_t phys_addr, target_phys_addr_t len) if (must_use_aliases_source(phys_addr)) return 0; #endif + +#ifndef TARGET_IA64 kvm_qemu_log_memory(phys_addr, len, 1); +#endif return 0; } @@ -1384,7 +1387,10 @@ int kvm_log_stop(target_phys_addr_t phys_addr, target_phys_addr_t len) if (must_use_aliases_source(phys_addr)) return 0; #endif + +#ifndef TARGET_IA64 kvm_qemu_log_memory(phys_addr, len, 0); +#endif return 0; } -- 1.6.0.rc1 0001-KVM-Qemu-Do-not-use-log-dirty-in-IA64.patch Description: 0001-KVM-Qemu-Do-not-use-log-dirty-in-IA64.patch
RFC: Add reserved bits check
Current KVM doesn't check reserved bits of guest page table, while may use
reserved bits to bypass guest #PF in VMX.
This patch add this check while leaving shadow pte un-constructed if guest
RSVD=1.
Comments?
Thx, eddie
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 55fd4c5..9370ff0 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -261,6 +261,8 @@ struct kvm_mmu {
union kvm_mmu_page_role base_role;
u64 *pae_root;
+ u64 rsvd_bits_mask[4];
+ u64 large_page_rsvd_mask;
};
struct kvm_vcpu_arch {
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 31ba3cb..7f55c4a 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -127,6 +127,7 @@ module_param(oos_shadow, bool, 0644);
#define PFERR_PRESENT_MASK (1U 0)
#define PFERR_WRITE_MASK (1U 1)
#define PFERR_USER_MASK (1U 2)
+#define PFERR_RSVD_MASK (1U 3)
#define PFERR_FETCH_MASK (1U 4)
#define PT_DIRECTORY_LEVEL 2
@@ -179,6 +180,13 @@ static u64 __read_mostly shadow_user_mask;
static u64 __read_mostly shadow_accessed_mask;
static u64 __read_mostly shadow_dirty_mask;
static u64 __read_mostly shadow_mt_mask;
+extern struct kvm_cpuid_entry2 *kvm_find_cpuid_entry(
+ struct kvm_vcpu *vcpu, u32 function, u32 index);
+
+static inline u64 rsvd_bits(int s, int e)
+{
+ return ((1ULL (e - s + 1)) - 1) s;
+}
void kvm_mmu_set_nonpresent_ptes(u64 trap_pte, u64 notrap_pte)
{
@@ -251,6 +259,18 @@ static int is_rmap_pte(u64 pte)
return is_shadow_present_pte(pte);
}
+static int cpuid_maxphyaddr(struct kvm_vcpu *vcpu)
+{
+ u32 function=0x8008;
+ struct kvm_cpuid_entry2 *best;
+
+ best = kvm_find_cpuid_entry(vcpu, function, 0);
+ if (best) {
+ return best-eax 0xff;
+ }
+ return 40;
+}
+
static pfn_t spte_to_pfn(u64 pte)
{
return (pte PT64_BASE_ADDR_MASK) PAGE_SHIFT;
@@ -2156,6 +2176,17 @@ static void paging_free(struct kvm_vcpu *vcpu)
nonpaging_free(vcpu);
}
+static int is_rsvd_bits_set(struct kvm_vcpu *vcpu, unsigned long pte, int
level)
+{
+ if (level == PT_DIRECTORY_LEVEL (pte PT_PAGE_SIZE_MASK)) {
+ /* large page */
+ return (pte vcpu-arch.mmu.large_page_rsvd_mask) != 0;
+ }
+ else
+ /* 4K page */
+ return (pte vcpu-arch.mmu.rsvd_bits_mask[level-1]) != 0;
+}
+
#define PTTYPE 64
#include paging_tmpl.h
#undef PTTYPE
@@ -2184,6 +2215,18 @@ static int paging64_init_context_common(struct kvm_vcpu
*vcpu, int level)
static int paging64_init_context(struct kvm_vcpu *vcpu)
{
+ struct kvm_mmu *context = vcpu-arch.mmu;
+ int maxphyaddr = cpuid_maxphyaddr(vcpu);
+
+ context-rsvd_bits_mask[3] =
+ rsvd_bits(maxphyaddr, 51) | rsvd_bits(7, 8);
+ context-rsvd_bits_mask[2] =
+ rsvd_bits(maxphyaddr, 51) | rsvd_bits(7, 8);
+ context-rsvd_bits_mask[1] =
+ rsvd_bits(maxphyaddr, 51) | rsvd_bits(7, 8);
+ context-rsvd_bits_mask[0] = rsvd_bits(maxphyaddr, 51);
+ context-large_page_rsvd_mask = /* 2MB PDE */
+ rsvd_bits(maxphyaddr, 51) | rsvd_bits(13, 20);
return paging64_init_context_common(vcpu, PT64_ROOT_LEVEL);
}
@@ -2191,6 +2234,15 @@ static int paging32_init_context(struct kvm_vcpu *vcpu)
{
struct kvm_mmu *context = vcpu-arch.mmu;
+ /* no rsvd bits for 2 level 4K page table entries */
+ context-rsvd_bits_mask[0] = 0;
+ context-rsvd_bits_mask[1] = 0;
+ if (is_cpuid_PSE36())
+ /* 36bits PSE 4MB page */
+ context-large_page_rsvd_mask = rsvd_bits(17, 21);
+ else
+ /* 32 bits PSE 4MB page */
+ context-large_page_rsvd_mask = rsvd_bits(13, 21);
context-new_cr3 = paging_new_cr3;
context-page_fault = paging32_page_fault;
context-gva_to_gpa = paging32_gva_to_gpa;
@@ -2206,6 +2258,18 @@ static int paging32_init_context(struct kvm_vcpu *vcpu)
static int paging32E_init_context(struct kvm_vcpu *vcpu)
{
+ struct kvm_mmu *context = vcpu-arch.mmu;
+ int maxphyaddr = cpuid_maxphyaddr(vcpu);
+
+ /* 3 levels */
+ context-rsvd_bits_mask[2] = rsvd_bits(maxphyaddr, 63) |
+ rsvd_bits(7, 8) | rsvd_bits(1,2); /* PDPTE */
+ context-rsvd_bits_mask[1] = rsvd_bits(maxphyaddr, 63); /* PDE */
+ context-rsvd_bits_mask[0] = /* PTE */
+ rsvd_bits(maxphyaddr, 63) | rsvd_bits(7, 8) | rsvd_bits(1, 2);
+ context-large_page_rsvd_mask = /* 2M page */
+ rsvd_bits(maxphyaddr, 63) | rsvd_bits(13, 20);
+
return paging64_init_context_common(vcpu, PT32E_ROOT_LEVEL);
}
diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
index 7314c09..844efe9 100644
--- a/arch/x86/kvm/paging_tmpl.h
+++ b/arch/x86/kvm/paging_tmpl.h
@@ -123,6 +123,7 @@ static int FNAME(walk_addr)(struct guest_walker *walker,
gfn_t table_gfn;
unsigned index, pt_access, pte_access;
gpa_t pte_gpa;
+ int rsvd_fault;
pgprintk(%s: addr %lx\n, __func__, addr);
walk:
@@ -153,10 +154,13 @@ walk:
walker-level - 1, table_gfn);
kvm_read_guest(vcpu-kvm, pte_gpa, pte, sizeof(pte));
+ rsvd_fault = is_rsvd_bits_set(vcpu, pte, walker-level);
if (!is_present_pte(pte))
goto not_present;
+ if (rsvd_fault)
+ goto access_error;
RE: KVM Port
Yes. At least, you need an application to launch VM. It's helpful to use qemu to emulate the I/O. But if your hardware support the technic like iommu, you can move the part into KVM for better performance. -Original Message- From: kvm port [mailto:kvmp...@gmail.com] Sent: Thursday, March 26, 2009 2:03 PM To: Liu Yu-B13201 Cc: k...@vger.kernel.org; kvm-ppc@vger.kernel.org Subject: Re: KVM Port do we have to port qemu as well? On Thu, Mar 26, 2009 at 7:22 AM, Liu Yu-B13201 yu@freescale.com wrote: IMHO, one thing you should keep in mind is how to isolate the guest space based on your hardware MMU. And then deal with the exceptions carefully, some may be directly send to guest and some should be handled by hypervisor. In powerpc BOOKE implementation, we have to hijack all exceptions, because BOOKE doesn't support technic like VT. -Original Message- From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of kvm port Sent: Wednesday, March 25, 2009 11:08 PM To: k...@vger.kernel.org; kvm-ppc@vger.kernel.org Subject: KVM Port Hi KVM Gurus, We have a EVB with a fpga based RISC processor with VT support. As a proof of concept i have to port KVM onto it. we have run linux as of now. can anyof u help with how should i begin -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM Port
AFAIK KVM userspace app creates a VM using /dev/kvm. Now if IO has a MMU managed by KVM arch module, do i still need qemu? On Thu, Mar 26, 2009 at 12:03 PM, Liu Yu-B13201 yu@freescale.com wrote: Yes. At least, you need an application to launch VM. It's helpful to use qemu to emulate the I/O. But if your hardware support the technic like iommu, you can move the part into KVM for better performance. -Original Message- From: kvm port [mailto:kvmp...@gmail.com] Sent: Thursday, March 26, 2009 2:03 PM To: Liu Yu-B13201 Cc: k...@vger.kernel.org; kvm-ppc@vger.kernel.org Subject: Re: KVM Port do we have to port qemu as well? On Thu, Mar 26, 2009 at 7:22 AM, Liu Yu-B13201 yu@freescale.com wrote: IMHO, one thing you should keep in mind is how to isolate the guest space based on your hardware MMU. And then deal with the exceptions carefully, some may be directly send to guest and some should be handled by hypervisor. In powerpc BOOKE implementation, we have to hijack all exceptions, because BOOKE doesn't support technic like VT. -Original Message- From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of kvm port Sent: Wednesday, March 25, 2009 11:08 PM To: k...@vger.kernel.org; kvm-ppc@vger.kernel.org Subject: KVM Port Hi KVM Gurus, We have a EVB with a fpga based RISC processor with VT support. As a proof of concept i have to port KVM onto it. we have run linux as of now. can anyof u help with how should i begin -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
