Re: Implement generic double fault generation mechanism

On Mon, May 11, 2009 at 09:04:52AM +0800, Dong, Eddie wrote: There is not point referring to current code. Current code does not handle serial exceptions properly. So fix it in your patch otherwise I propose to use my patch that fixes current code

Re: Implement generic double fault generation mechanism

Dong, Eddie wrote: There is not point referring to current code. Current code does not handle serial exceptions properly. So fix it in your patch otherwise I propose to use my patch that fixes current code (http://patchwork.kernel.org/patch/21829/). I would like Avi to decide. I would

RE: [PATCH 2/2] Intel-IOMMU, intr-remap: source-id checking

Siddha, Suresh B wrote: On Wed, 2009-05-06 at 23:16 -0700, Han, Weidong wrote: @@ -634,6 +694,44 @@ static int ir_parse_ioapic_scope(struct acpi_dmar_header *header, 0x%Lx\n, scope-enumeration_id, drhd-address); +

[PATCH] kvm: fix kvm_check_extension() error handling

If the KVM_CHECK_EXTENSION ioctl returns an error, it indicates a serious error, not that the extension is not supported. Fix kvm_check_extension() to report the error in this case. Signed-off-by: Avi Kivity a...@redhat.com --- kvm-all.c |3 ++- 1 files changed, 2 insertions(+), 1

[PATCH] make vmx-debug.c to compile again

Add TPR value checking. Signed-off-by: Gleb Natapov g...@redhat.com diff --git a/x86/vmx-debug.c b/x86/vmx-debug.c index 29316a0..d466f03 100644 --- a/x86/vmx-debug.c +++ b/x86/vmx-debug.c @@ -17,17 +17,14 @@ #include linux/highmem.h #include linux/kvm_host.h +#include asm/vmx.h +#include

Re: [PATCH] make vmx-debug.c to compile again

Gleb Natapov wrote: Add TPR value checking. 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

Re: [PATCH] make migration work again

Avi Kivity wrote: Glauber Costa wrote: Due to a small messup in version checking, migration was not working. fix it. I think you want to remove the first line as well? Only accept version_id == 9? And keep the comment. Meanwhile I've reverted the offending patch, 7b2e5aba. -- error

[PATCH] virtio_blk: don't blindly derefence req-rq_disk

request-rq_disk is only set for FS requests or BLOCK_PC requests originating from the generic block layer scsi ioctls. It's not set for requests origination from other soures or internal cache flush commands implemented by the patch I'll send after this. So instead of using it to get at the

[PATCH, RFC] virtio_blk: add cache flush command

Currently virtio-blk does support barriers for ordering requests which is enough to guarantee filesystem metadata integrity with write back caches, but it does not support any way to flush that writeback cache, to guarantee that data is stable on disk on a fsync. This patch implements a new

[PATCH -v3] KVM: MCE: Add MCE support to KVM

The related MSRs are emulated. MCE capability is exported via extension KVM_CAP_MCE and ioctl KVM_X86_GET_MCE_CAP_SUPPORTED. A new vcpu ioctl command KVM_X86_SETUP_MCE is used to setup MCE emulation such as the mcg_cap. MCE is injected via vcpu ioctl command KVM_X86_SET_MCE. Extended

[PATCH -v4 1/2] QEMU-KVM: MCE: Add MCE simulation to qemu/tcg

Add savevm/loadvm support in this version. But it seems that the savevm/loadvm support in qemu-kvm.git is broken. So it is not tested. Best Regards, Huang Ying - - MCE features are initialized when VCPU is intialized according to CPUID.

[PATCH -v4 2/2] QEMU-KVM: MCE: Add MCE simulation support to qemu/kvm

KVM ioctls are used to initialize MCE simulation and inject MCE. The real MCE simulation is implemented in Linux kernel. ChangeLog: v3: - Re-based on qemu/tcg MCE support patch v2: - Use new kernel MCE capability exportion interface. Signed-off-by: Huang Ying ying.hu...@intel.com ---

Re: [PATCH -v3] KVM: MCE: Add MCE support to KVM

On Mon, 2009-05-11 at 16:48 +0800, Huang Ying wrote: +int kvm_get_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 *pdata) +{ + u64 data; + + switch (msr) { + case 0xc0010010: /* SYSCFG */ + case 0xc0010015: /* HWCR */ You can replace this with : + case MSR_K8_SYSCFG:

Re: [PATCH -v3] KVM: MCE: Add MCE support to KVM

On Mon, 2009-05-11 at 17:05 +0800, Jaswinder Singh Rajput wrote: On Mon, 2009-05-11 at 16:48 +0800, Huang Ying wrote: +int kvm_get_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 *pdata) +{ + u64 data; + + switch (msr) { + case 0xc0010010: /* SYSCFG */ + case 0xc0010015: /*

Re: boot=on option fails on win 2k/xp double boot

Gleb Natapov, il 10/05/2009 10:51, ha scritto: other info: libvirt version is 0.4.6-10 and kvm is 72. these are what is currenntly available with debian lenny Can you please try non ancient version of KVM? kvm-85? unfortunately no, since that's the current stable version available with

Re: boot=on option fails on win 2k/xp double boot

On Mon, May 11, 2009 at 11:20:21AM +0200, Federico Fissore wrote: Gleb Natapov, il 10/05/2009 10:51, ha scritto: other info: libvirt version is 0.4.6-10 and kvm is 72. these are what is currenntly available with debian lenny Can you please try non ancient version of KVM? kvm-85?

Re: kvm hardlocks on hp dv9010us

Piotr Jaroszyński wrote: Hello, kvm-85 with vanilla kernel 2.6.29.3 (kvm modules from kernel) hard locks for me: - sometimes at the very beginning, just after the QEMU window opens, but nothing is displayed before the hardlock. - sometimes during runtime with various guests: e.g. Windows XP

Re: [PATCH -tip v5 1/7] x86: instruction decorder API

On Fri, May 08, 2009 at 08:48:42PM -0400, Masami Hiramatsu wrote: Add x86 instruction decoder to arch-specific libraries. This decoder can decode x86 instructions used in kernel into prefix, opcode, modrm, sib, displacement and immediates. This can also show the length of instructions. Could

Re: [PATCH -tip v5 5/7] x86: fix kernel_trap_sp()

On Fri, May 08, 2009 at 08:49:04PM -0400, Masami Hiramatsu wrote: Use regs-sp instead of regs for getting the top of stack in kernel mode. (on x86-64, regs-sp always points the top of stack) Shouldn't this patch be sent for inclusion ASAP instead of sitting in this series? -- To unsubscribe

RE: [PATCH 04/04] qemu-kvm: other archs should maintain memory mapping also.

Any conclusion on this thread ? Xiantao Zhang, Xiantao wrote: From d184d9b0a91ca674961000ed3d35b7fc25d29e03 Mon Sep 17 00:00:00 2001 From: Xiantao Zhang xiantao.zh...@intel.com Date: Tue, 28 Apr 2009 16:59:36 +0800 Subject: [PATCH] qemu-kvm: other archs should maintain memory mapping also.

[PATCH] qemu-kvm: Flush icache after dma operations for ia64

Avi This is the new patch for icache flush after DMA emualtion for ia64, and it should address Hollis's comments. Xiantao From 60a27e2ea9758c97e974aa5bb1925ad4ed045c5f Mon Sep 17 00:00:00 2001 From: Xiantao Zhang xiantao.zh...@intel.com Date: Mon, 11 May 2009 18:04:15 +0800 Subject:

[PATCH 02/10] Do not allow interrupt injection from userspace if there is a pending event.

Signed-off-by: Gleb Natapov g...@redhat.com --- arch/x86/kvm/x86.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index c6d3ff3..fe447e7 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -3093,8 +3093,9 @@ static

[PATCH 04/10] [SVM] skip_emulated_instruction() decode an instruction if size is not known

Signed-off-by: Gleb Natapov g...@redhat.com --- arch/x86/kvm/svm.c | 11 +-- 1 files changed, 5 insertions(+), 6 deletions(-) diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c index 153aa32..5022de0 100644 --- a/arch/x86/kvm/svm.c +++ b/arch/x86/kvm/svm.c @@ -207,7 +207,9 @@ static

[PATCH 05/10] [VMX] Do not re-execute INTn instruction.

Re-inject event instead. This is what Intel suggest. Also use correct instruction length when re-injecting soft fault/interrupt. Signed-off-by: Gleb Natapov g...@redhat.com --- arch/x86/include/asm/kvm_host.h |5 - arch/x86/kvm/svm.c |8 arch/x86/kvm/vmx.c

[PATCH 10/10] Move exit due to NMI handling into vmx_complete_interrupts()

To save us one reading of VM_EXIT_INTR_INFO. Signed-off-by: Gleb Natapov g...@redhat.com --- arch/x86/kvm/vmx.c | 20 ++-- 1 files changed, 10 insertions(+), 10 deletions(-) diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index 211a787..af80006 100644 ---

[PATCH 01/10] Unprotect a page if #PF happens during NMI injection.

It is done for exception and interrupt already. Signed-off-by: Gleb Natapov g...@redhat.com --- arch/x86/kvm/svm.c |3 +-- arch/x86/kvm/vmx.c |2 +- arch/x86/kvm/x86.h |6 ++ 3 files changed, 8 insertions(+), 3 deletions(-) diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c

[PATCH 03/10] Remove irq_pending bitmap

Only one interrupt vector can be injected from userspace irqchip at any given time so no need to store it in a bitmap. Put it into interrupt queue directly. Signed-off-by: Gleb Natapov g...@redhat.com --- arch/x86/include/asm/kvm_host.h |2 -- arch/x86/kvm/irq.c |4 ++--

[PATCH 06/10] IRQ/NMI window should always be requested.

Currently they are not requested if there is pending exception. Signed-off-by: Gleb Natapov g...@redhat.com --- arch/x86/kvm/x86.c | 30 -- 1 files changed, 12 insertions(+), 18 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index

[PATCH 08/10] Do not migrate pending software interrupts.

INTn will be re-executed after migration. If we wanted to migrate pending software interrupt we would need to migrate interrupt type and instruction length too, but we do not have all required info on SVM, so SVM-VMX migration would need to re-execute INTn anyway. To make it simple never migrate

[PATCH 07/10] [SVM] inject NMI after IRET from a previous NMI, not before.

If NMI is received during handling of another NMI it should be injected immediately after IRET from previous NMI handler, but SVM intercept IRET before instruction execution so we can't inject pending NMI at this point and there is not way to request exit when NMI window opens. This patch fix SVM

[PATCH 09/10] Disable CR8 intercept if tpr patching is active.

Signed-off-by: Gleb Natapov g...@redhat.com --- arch/x86/kvm/x86.c | 11 ++- 1 files changed, 6 insertions(+), 5 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 2729c4b..04236b2 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -3130,7 +3130,10 @@

Re: [KVM-AUTOTEST][PATCH] timedrift support

Hello. I have modified my script according Marcelo's suggestion. and resubmit my script to you all. :) Marcelo, Seems except you, no one care my script. I still want to say any suggestion on my script would be greatly appreciated. Thanks. Bear Marcelo Tosatti wrote: Bear, Some

Re: kvm hardlocks on hp dv9010us

Are you updated to the latest BIOS revision? Yes, updated yesterday to F.42 which is dated 03-2009 [1]. [1] - http://h10025.www1.hp.com/ewfrf/wc/softwareList?product=3253950os=2100dlc=enlc=encc=us -- Best Regards, Piotr Jaroszyński -- To unsubscribe from this list: send the line unsubscribe

Re: [PATCH -tip v5 4/7] tracing: add kprobe-based event tracer

* Christoph Hellwig h...@infradead.org wrote: On Fri, May 08, 2009 at 08:48:59PM -0400, Masami Hiramatsu wrote: Add kprobes based event tracer on ftrace. This tracer is similar to the events tracer which is based on Tracepoint infrastructure. Instead of Tracepoint, this tracer is

Re: kvm hardlocks on hp dv9010us

Piotr Jaroszyński wrote: Are you updated to the latest BIOS revision? Yes, updated yesterday to F.42 which is dated 03-2009 [1]. [1] - http://h10025.www1.hp.com/ewfrf/wc/softwareList?product=3253950os=2100dlc=enlc=encc=us Please post your .config. -- error compiling committee.c:

Re: [KVM-AUTOTEST][PATCH] timedrift support

On 5/11/2009 1:40 PM, Bear Yang wrote: Hello. I have modified my script according Marcelo's suggestion. and resubmit my script to you all. :) Marcelo, Seems except you, no one care my script. I still want to say any suggestion on my script would be greatly appreciated. Thanks. Bear

Re: [PATCH] qemu-kvm: Flush icache after dma operations for ia64

Zhang, Xiantao wrote: Avi This is the new patch for icache flush after DMA emualtion for ia64, and it should address Hollis's comments. Xiantao From 60a27e2ea9758c97e974aa5bb1925ad4ed045c5f Mon Sep 17 00:00:00 2001 From: Xiantao Zhang xiantao.zh...@intel.com Date: Mon, 11 May 2009

Re: [PATCH 04/04] qemu-kvm: other archs should maintain memory mapping also.

Zhang, Xiantao wrote: Any conclusion on this thread ? Xiantao Hi Xiantao, Not that I am aware of, I suspect it's still pending in Avi's tree. Cheers, Jes Zhang, Xiantao wrote: From d184d9b0a91ca674961000ed3d35b7fc25d29e03 Mon Sep 17 00:00:00 2001 From: Xiantao Zhang

Re: kvm hardlocks on hp dv9010us

Piotr Jaroszyński wrote: I have a hp dv9010us laptop (one of those that hard locked before CONFIG_IO_DELAY_* options were introduced in kernel - not sure if it may be related at all). I skipped this bit, and it's crucial. kvm passes port 80 to go from guest to host as an optimization, and

Re: [PATCH] kvm: Use a bitmap for tracking used GSIs

On Friday 08 May 2009 06:22:20 Alex Williamson wrote: We're currently using a counter to track the most recent GSI we've handed out. This quickly hits KVM_MAX_IRQ_ROUTES when using device assignment with a driver that regularly toggles the MSI enable bit. This can mean only a few minutes of

[patch] today's qemu-kvm build fix

Hi, This one is a bit strange, somehow we ended up with a kvm_get_supported_cpuid() in qemu-kvm.c, where it should never have been given it's in target-i386/kvm.c and called only from libkvm-x86.c With this I can build again. Cheers, Jes kvm_arch_get_supported_cpuid() is already defined in

Re: [patch] today's qemu-kvm build fix

Jes Sorensen wrote: Hi, This one is a bit strange, somehow we ended up with a kvm_get_supported_cpuid() in qemu-kvm.c, where it should never have been given it's in target-i386/kvm.c and called only from libkvm-x86.c kvm.c is not (yet) built in qemu-kvm.git. Please move the function to

Re: [patch] today's qemu-kvm build fix

Avi Kivity wrote: kvm.c is not (yet) built in qemu-kvm.git. Please move the function to qemu-kvm-x86.c instead. Ok, Grossness is now in qemu-kvm-x86.c. Jes kvm_arch_get_supported_cpuid() doesn't belong in qemu-kvm.c as it is just an x86 specific build workaround. Signed-off-by: Jes

Re: [patch] today's qemu-kvm build fix

Jes Sorensen wrote: Avi Kivity wrote: kvm.c is not (yet) built in qemu-kvm.git. Please move the function to qemu-kvm-x86.c instead. Ok, Grossness is now in qemu-kvm-x86.c. Thanks, applied. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this

Re: [PATCH 4/6] kvm-s390: Unlink vcpu on destroy

Avi Kivity wrote: ehrha...@linux.vnet.ibm.com wrote: From: Carsten Otte co...@de.ibm.com This patch makes sure we do unlink a vcpu's sie control block from the system control area in kvm_arch_vcpu_destroy. This prevents illegal accesses to the sie control block from other virtual cpus after

Re: [PATCH 1/6] kvm-s390: Fix memory slot versus run

Avi Kivity wrote: ehrha...@linux.vnet.ibm.com wrote: From: Carsten Otte co...@de.ibm.com This patch fixes an incorrectness in the kvm backend for s390. In case virtual cpus are being created before the corresponding memory slot is being registered, we need to update the sie control blocks for

Re: [RFC PATCH 0/3] generic hypercall support

On Saturday 09 May 2009, Benjamin Herrenschmidt wrote: This was shot down by a vast majority of people, with the outcome being an agreement that for IORESOURCE_MEM, pci_iomap and friends must return something that is strictly interchangeable with what ioremap would have returned. That means

Re: [RFC PATCH 0/3] generic hypercall support

Arnd Bergmann wrote: On Saturday 09 May 2009, Benjamin Herrenschmidt wrote: This was shot down by a vast majority of people, with the outcome being an agreement that for IORESOURCE_MEM, pci_iomap and friends must return something that is strictly interchangeable with what ioremap would

Re: [KVM-AUTOTEST][PATCH] timedrift support

On Mon, 2009-05-11 at 18:40 +0800, Bear Yang wrote: Hello. I have modified my script according Marcelo's suggestion. and resubmit my script to you all. :) Marcelo, Seems except you, no one care my script. I still want to say any suggestion on my script would be greatly appreciated.

Re: [RFC PATCH 0/3] generic hypercall support

Anthony Liguori wrote: Gregory Haskins wrote: Anthony Liguori wrote: I'm surprised so much effort is going into this, is there any indication that this is even close to a bottleneck in any circumstance? Yes. Each 1us of overhead is a 4% regression in something as trivial as a

Re: [PATCH 1/6] kvm-s390: Fix memory slot versus run

Christian Ehrhardt wrote: On x86, we use slots_lock to protect memory slots. When we change the global memory configuration, we set a bit in vcpu-requests, and send an IPI to all cpus that are currently in guest mode for our guest. This forces the cpu back to host mode. On the next entry,

Re: [PATCH 1/6] kvm-s390: Fix memory slot versus run

Avi Kivity wrote: Christian Ehrhardt wrote: On x86, we use slots_lock to protect memory slots. When we change the global memory configuration, we set a bit in vcpu-requests, and send an IPI to all cpus that are currently in guest mode for our guest. This forces the cpu back to host mode.

Re: [PATCH][KVM-AUTOTEST] Add custom install option for kvm_install

Hi, Excerpts from Michael Burns's message of Fri May 08 15:55:30 -0300 2009: --- a/client/tests/kvm_runtest_2/kvm_install.py +++ b/client/tests/kvm_runtest_2/kvm_install.py @@ -77,6 +77,17 @@ def run_kvm_install(test, params, env): elif install_mode == localsrc:

Re: [PATCH 1/6] kvm-s390: Fix memory slot versus run

Christian Ehrhardt wrote: I thought about implementing it with slots_lock, vcpu-request, etc but it really looks like overkill for s390. We could make (some of) it common code, so it won't look so bad. There's value in having all kvm ports do things similarly; though of course we shouldn't

Re: [PATCH -tip v5 2/7] kprobes: checks probe address is instruction boudary on x86

On Fri, 8 May 2009, Masami Hiramatsu wrote: Ensure safeness of inserting kprobes by checking whether the specified address is at the first byte of a instruction on x86. This is done by decoding probed function from its head to the probe point. Signed-off-by: Masami Hiramatsu

Re: [PATCH][KVM][retry 1] Add support for Pause Filtering to AMD SVM

Ingo Molnar wrote: +static int pause_interception(struct vcpu_svm *svm, struct kvm_run *kvm_run) +{ + /* Simple yield */ + vcpu_put(svm-vcpu); + schedule(); + vcpu_load(svm-vcpu); + return 1; + Ingo, will this do anything under CFS, or will CFS note that

Re: [PATCH][KVM][retry 1] Add support for Pause Filtering to AMD SVM

* Avi Kivity a...@redhat.com wrote: I.e. this is a somewhat poor solution as far as scheduling goes. But i'm wondering what the CPU side does. Can REP-NOP really take thousands of cycles? If yes, under what circumstances? The guest is running rep-nop in a loop while trying to acquire a

Re: [PATCH -tip v5 1/7] x86: instruction decorder API

Christoph Hellwig wrote: On Fri, May 08, 2009 at 08:48:42PM -0400, Masami Hiramatsu wrote: Add x86 instruction decoder to arch-specific libraries. This decoder can decode x86 instructions used in kernel into prefix, opcode, modrm, sib, displacement and immediates. This can also show the length

Re: [PATCH -tip v5 7/7] tracing: add arguments support on kprobe-based event tracer

On Fri, 8 May 2009, Masami Hiramatsu wrote: Support following probe arguments and add fetch functions on kprobe-based event tracer. %REG : Fetch register REG sN: Fetch Nth entry of stack (N = 0) @ADDR : Fetch memory at ADDR (ADDR should be in kernel) @SYM[+|-offs] : Fetch

Re: [PATCH -tip v5 0/7] tracing: kprobe-based event tracer and x86 instruction decoder

Ingo Molnar wrote: * Masami Hiramatsu mhira...@redhat.com wrote: Hi, Here are the patches of kprobe-based event tracer for x86, version 5, which allows you to probe various kernel events through ftrace interface. This version supports only x86(-32/-64) (but porting it on other arch

Re: [RFC PATCH v3 00/17] virtual-bus

Nikola Ciprich wrote: Hi Gregory, I'd like to try Your vbus patches, but compiling 2.6.30-rc2 (or 2.6.30-rc5) fails with following error: drivers/vbus/proxy/kvm-guest-vbus: struct pci_device_id is 32 bytes. The last of 1 is: 0xda 0x11 0x00 0x00 0x00 0x20 0x00 0x00 0xff 0xff 0xff 0xff

Re: [PATCH 1/6] kvm-s390: Fix memory slot versus run

Avi Kivity wrote: Christian Ehrhardt wrote: I thought about implementing it with slots_lock, vcpu-request, etc but it really looks like overkill for s390. We could make (some of) it common code, so it won't look so bad. There's value in having all kvm ports do things similarly; though of

Re: [PATCH][KVM][retry 1] Add support for Pause Filtering to AMD SVM

Ingo Molnar wrote: * Avi Kivity a...@redhat.com wrote: I.e. this is a somewhat poor solution as far as scheduling goes. But i'm wondering what the CPU side does. Can REP-NOP really take thousands of cycles? If yes, under what circumstances? The guest is running rep-nop in a loop

Re: [PATCH, RFC] virtio_blk: add cache flush command

Christoph Hellwig wrote: Currently virtio-blk does support barriers for ordering requests which is enough to guarantee filesystem metadata integrity with write back caches, but it does not support any way to flush that writeback cache, to guarantee that data is stable on disk on a fsync. This

Re: [PATCH -tip v5 0/7] tracing: kprobe-based event tracer and x86 instruction decoder

On Mon, 11 May 2009, Masami Hiramatsu wrote: Two high-level comments: - There's no self-test - would it be possible to add one? See trace_selftest* in kernel/trace/ I'm not so sure. Currently, it seems that those self-tests are only for tracers which define new event-entry on

Re: [PATCH][KVM][retry 1] Add support for Pause Filtering to AMD SVM

On Mon, 2009-05-11 at 17:24 +0300, Avi Kivity wrote: I.e. this is a somewhat poor solution as far as scheduling goes. But i'm wondering what the CPU side does. Can REP-NOP really take thousands of cycles? If yes, under what circumstances? The guest is running rep-nop in a loop

Re: [PATCH -tip v5 2/7] kprobes: checks probe address is instruction boudary on x86

Steven Rostedt wrote: On Fri, 8 May 2009, Masami Hiramatsu wrote: Ensure safeness of inserting kprobes by checking whether the specified address is at the first byte of a instruction on x86. This is done by decoding probed function from its head to the probe point. Signed-off-by: Masami

Re: [PATCH][KVM][retry 1] Add support for Pause Filtering to AMD SVM

On Mon, 2009-05-11 at 17:51 +0300, Avi Kivity wrote: Ingo Molnar wrote: * Avi Kivity a...@redhat.com wrote: I.e. this is a somewhat poor solution as far as scheduling goes. But i'm wondering what the CPU side does. Can REP-NOP really take thousands of cycles? If yes, under what

Re: [PATCH][KVM][retry 1] Add support for Pause Filtering to AMD SVM

Peter Zijlstra wrote: On Mon, 2009-05-11 at 17:24 +0300, Avi Kivity wrote: I.e. this is a somewhat poor solution as far as scheduling goes. But i'm wondering what the CPU side does. Can REP-NOP really take thousands of cycles? If yes, under what circumstances? The guest is

Re: [PATCH][KVM-AUTOTEST] Add custom install option for kvm_install

Eduardo Habkost wrote: Hi, Excerpts from Michael Burns's message of Fri May 08 15:55:30 -0300 2009: --- a/client/tests/kvm_runtest_2/kvm_install.py +++ b/client/tests/kvm_runtest_2/kvm_install.py @@ -77,6 +77,17 @@ def run_kvm_install(test, params, env): elif install_mode == localsrc:

Re: [PATCH][KVM][retry 1] Add support for Pause Filtering to AMD SVM

Peter Zijlstra wrote: This really needs a new kernel-internal scheduler API though, which does a lot of fancy things to do: se-vruntime += 100; i.e. add 1 msec worth of nanoseconds to the task's timeline. (first remove it from the rbtree, then add it back, and nice-weight it as

Re: [PATCH][KVM][retry 1] Add support for Pause Filtering to AMD SVM

Ingo Molnar wrote: * Avi Kivity a...@redhat.com wrote: And only do it if there's other tasks running on this CPU or so. What would happen if there weren't? I'd guess the task would continue running (but with a warped vruntime)? We dont want that warping to occur - we just

Re: [PATCH -tip v5 2/7] kprobes: checks probe address is instruction boudary on x86

Masami Hiramatsu wrote: + if (!kallsyms_lookup(paddr, NULL, offset, NULL, __dummy_buf)) + return 0; + + /* Decode instructions */ + addr = paddr - offset; + while (addr paddr) { + insn_init_kernel(insn, (void *)addr); + insn_get_opcode(insn); +

Re: [PATCH][KVM][retry 1] Add support for Pause Filtering to AMD SVM

* Avi Kivity a...@redhat.com wrote: I.e. the 3000 cycles value itself could be eliminated as well. (with just a common-sense max of say 100,000 cycles enforced) Yeah, though that has a much smaller effect as it's only responsible for a few microseconds of spinning. 3000 cycles would be

Re: [PATCH -tip v5 2/7] kprobes: checks probe address is instruction boudary on x86

On Mon, 11 May 2009, Masami Hiramatsu wrote: + * by fix_riprel(). + */ + memcpy(buf, kp-addr, MAX_INSN_SIZE * sizeof(kprobe_opcode_t)); + buf[0] = kp-opcode; Why is it OK to copy addr to buf and then rewrite the first character of buf? Does it have something to do with

Re: [PATCH][KVM][retry 1] Add support for Pause Filtering to AMD SVM

Ingo Molnar wrote: * Avi Kivity a...@redhat.com wrote: I.e. the 3000 cycles value itself could be eliminated as well. (with just a common-sense max of say 100,000 cycles enforced) Yeah, though that has a much smaller effect as it's only responsible for a few microseconds of

Re: [PATCH 1/6] kvm-s390: Fix memory slot versus run

Christian Ehrhardt wrote: The bad thing on vcpu-request in that case is that I don't want the async behaviour of vcpu-requests in that case, I want the memory slot updated in all vcpu's when the ioctl is returning. You mean, the hardware can access the vcpu control block even when the vcpu

RE: [PATCH][KVM][retry 1] Add support for Pause Filtering to AMD SVM

Ingo Molnar wrote: * Avi Kivity a...@redhat.com wrote: I.e. the 3000 cycles value itself could be eliminated as well. (with just a common-sense max of say 100,000 cycles enforced) Yeah, though that has a much smaller effect as it's only responsible for a few

[PATCH] kmod: Adjust MSR helper availability

native_read_msr_safe() and macros already materialized in 2.6.25, only rdmsrl_safe is required for that kernel. Signed-off-by: Jan Kiszka jan.kis...@siemens.com --- x86/external-module-compat.h |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git

[PATCH] kmod: Adjust kvm_smp_send_reschedule availability

Also x86_64 before 2.6.26 requires kvm_smp_send_reschedule. Signed-off-by: Jan Kiszka jan.kis...@siemens.com --- external-module-compat-comm.h |6 -- external-module-compat.c |6 -- 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/external-module-compat-comm.h

Re: [PATCH, RFC] virtio_blk: add cache flush command

On Mon, May 11, 2009 at 09:51:40AM -0500, Anthony Liguori wrote: What typically triggers a flush operation? fsync. I would assume an fsync would, but would a flush happen after every O_DIRECT write? Right now it doesn't, but it probably should. If the backend implementation of T_FLUSH is

Re: [PATCH][KVM][retry 1] Add support for Pause Filtering to AMD SVM

Langsdorf, Mark wrote: The Linux spinlock is 1:\t cmpl %0, %2\n\t je 2f\n\t rep ; nop\n\t movzwl %1, %2\n\t /* don't need lfence here, because loads are in-order */ jmp 1b\n 5 instructions, maybe 2-3

Re: [PATCH, RFC] virtio_blk: add cache flush command

Christoph Hellwig wrote: If the backend implementation of T_FLUSH is fsync, I would think that this would result in rather poor performance for O_DIRECT operations in the guest. Right now it's fsync. By the time I'll submit the backend change it will still be fsync, but at least called

Re: [PATCH -tip v5 4/7] tracing: add kprobe-based event tracer

Christoph Hellwig h...@infradead.org writes: [...] But as with so many tracing bits in the kernel it's just lowlevel bits without a good user interface. We'd really need some high-level way for sysadmins/developers to use it. E.g. a version of the systemtap compiler that doesn't build a

[PATCH][KVM-AUTOTEST] Add custom install option for kvm_install

From: Michael Burns mbu...@redhat.com Signed-off-by: Michael Burns mbu...@redhat.com --- client/tests/kvm_runtest_2/control| 17 - client/tests/kvm_runtest_2/kvm_install.py | 13 + 2 files changed, 29 insertions(+), 1 deletions(-) diff --git

RE: [PATCH][KVM][retry 1] Add support for Pause Filtering to AMDSVM

Please dont even think about using yield for this though - Oops. I'm glad I waited to get some benchmark results before submitting that version. A gradual and linear back-off from the current timeline is more of a fair negotiation process between vcpus and results in more or less

Re: [PATCH, RFC] virtio_blk: add cache flush command

On Mon, May 11, 2009 at 06:45:50PM +0300, Avi Kivity wrote: Right now it's fsync. By the time I'll submit the backend change it will still be fsync, but at least called from the posix-aio-compat thread pool. I think if we have cache=writeback we should ignore this. It's only needed for

[PATCH -next] kvm: fix build error: add missing semi-colon

-20090511.orig/arch/x86/kvm/x86.c +++ linux-next-20090511/arch/x86/kvm/x86.c @@ -1252,7 +1252,7 @@ static void do_cpuid_ent(struct kvm_cpui #ifdef CONFIG_X86_64 unsigned f_lm = F(LM); #else - unsigned f_lm = 0 + unsigned f_lm = 0; #endif /* cpuid 1.edx */ -- ~Randy

Re: [RFC PATCH 0/3] generic hypercall support

On Mon, 2009-05-11 at 09:14 -0400, Gregory Haskins wrote: for request-response, this is generally for *every* packet since you cannot exploit buffering/deferring. Can you back up your claim that PPC has no difference in performance with an MMIO exit and a hypercall (yes, I understand

Re: [RFC PATCH 0/3] generic hypercall support

Anthony Liguori wrote: Yes, I misunderstood that they actually emulated it like that. However, ia64 has no paravirtualization support today so surely, we aren't going to be justifying this via ia64, right? Someone is actively putting a pvops infrastructure into the ia64 port, along with a

Re: [PATCH, RFC] virtio_blk: add cache flush command

Christoph Hellwig wrote: On Mon, May 11, 2009 at 09:51:40AM -0500, Anthony Liguori wrote: What typically triggers a flush operation? fsync. I would assume an fsync would, but would a flush happen after every O_DIRECT write? Right now it doesn't, but it probably should.

Re: [RFC PATCH 0/3] generic hypercall support

On Sun, 2009-05-10 at 13:38 -0500, Anthony Liguori wrote: Gregory Haskins wrote: Can you back up your claim that PPC has no difference in performance with an MMIO exit and a hypercall (yes, I understand PPC has no VT like instructions, but clearly there are ways to cause a trap, so

Re: [PATCH, RFC] virtio_blk: add cache flush command

Christoph Hellwig wrote: On Mon, May 11, 2009 at 06:45:50PM +0300, Avi Kivity wrote: Right now it's fsync. By the time I'll submit the backend change it will still be fsync, but at least called from the posix-aio-compat thread pool. I think if we have cache=writeback we should

Re: [RFC PATCH 0/3] generic hypercall support

Hollis Blanchard wrote: I haven't been following this conversation at all. With that in mind... AFAICS, a hypercall is clearly the higher-performing option, since you don't need the additional memory load (which could even cause a page fault in some circumstances) and instruction decode. That

Re: [PATCH, RFC] virtio_blk: add cache flush command

Avi Kivity wrote: Christoph Hellwig wrote: On Mon, May 11, 2009 at 06:45:50PM +0300, Avi Kivity wrote: Right now it's fsync. By the time I'll submit the backend change it will still be fsync, but at least called from the posix-aio-compat thread pool. I think if we have

Re: [PATCH][KVM-AUTOTEST] Add custom install option for kvm_install

Michael Goldish wrote: - Mike Burns mbu...@redhat.com wrote: Eduardo Habkost wrote: Hi, Excerpts from Michael Burns's message of Fri May 08 15:55:30 -0300 2009: --- a/client/tests/kvm_runtest_2/kvm_install.py +++ b/client/tests/kvm_runtest_2/kvm_install.py

Re: [RFC PATCH 0/3] generic hypercall support

Hollis Blanchard wrote: On Sun, 2009-05-10 at 13:38 -0500, Anthony Liguori wrote: Gregory Haskins wrote: Can you back up your claim that PPC has no difference in performance with an MMIO exit and a hypercall (yes, I understand PPC has no VT like instructions, but clearly there are ways

Re: [RFC PATCH 0/3] generic hypercall support

Gregory Haskins wrote: Avi Kivity wrote: Hollis Blanchard wrote: I haven't been following this conversation at all. With that in mind... AFAICS, a hypercall is clearly the higher-performing option, since you don't need the additional memory load (which could even cause a page fault in

Re: Linux x86 guest panics in skb_copy_bits

On Wed, May 6, 2009 at 5:16 PM, Marcelo Tosatti mtosa...@redhat.com wrote: Justin, [snip] OK, so you're original report contains a different bug. You can disable CONFIG_KVM_GUEST in the meantime as a workaround, until the bug is fixed. Disabling CONFIG_KVM_GUEST gives me a new panic. I'm

Is there some vmadditions like vmware tools for kvm ?

_ Vous voulez savoir ce que vous pouvez faire avec le nouveau Windows Live ? Lancez-vous ! http://www.microsoft.com/windows/windowslive/default.aspx-- To unsubscribe from this list: send the line unsubscribe kvm in the body of a

  1   2   >