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
---
kvm-all.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git
Add TPR value checking.
Signed-off-by: Gleb Natapov
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
#include
+#include
+#include
+#include "mmu.h"
+#include "lapic.h"
#include "debug.h"
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 http://vger.kernel.or
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
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 priv
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 VIRTIO
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 machine-check
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.
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
---
kvm/kernel/arch/x86/incl
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_SY
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 0x
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
deb
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?
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 64bi
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.
Cou
On Fri, May 08, 2009 at 08:49:04PM -0400, Masami Hiramatsu wrote:
> Use ®s->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 f
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 based on kprobes(kprobe
> and kretprobe). It probes any
Any conclusion on this thread ?
Xiantao
Zhang, Xiantao wrote:
> From d184d9b0a91ca674961000ed3d35b7fc25d29e03 Mon Sep 17 00:00:00 2001
> From: Xiantao Zhang
> Date: Tue, 28 Apr 2009 16:59:36 +0800
> Subject: [PATCH] qemu-kvm: other archs should maintain memory mapping
> also.
>
> Currently, us
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
Date: Mon, 11 May 2009 18:04:15 +0800
Subject: [PATCH] qemu-kvm: Flush icac
Signed-off-by: Gleb Natapov
---
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 void post_kvm_run_s
Signed-off-by: Gleb Natapov
---
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 void skip_emula
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
---
arch/x86/include/asm/kvm_host.h |5 -
arch/x86/kvm/svm.c |8
arch/x86/kvm/vmx.c | 32 +
To save us one reading of VM_EXIT_INTR_INFO.
Signed-off-by: Gleb Natapov
---
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
--- a/arch/x86/kvm/vmx.c
+++ b/arch/
It is done for exception and interrupt already.
Signed-off-by: Gleb Natapov
---
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
index 27d5b74..153
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
---
arch/x86/include/asm/kvm_host.h |2 --
arch/x86/kvm/irq.c |4 ++--
arch/x86/kvm/x86.c
Currently they are not requested if there is pending exception.
Signed-off-by: Gleb Natapov
---
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 48d8bc4..f0655ef 100644
--- a/a
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 p
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 c
Signed-off-by: Gleb Natapov
---
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 @@ static void update_
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 comments
> 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=3253950&os=2100&dlc=en&lc=en&cc=us
--
Best Regards,
Piotr Jaroszyński
--
To unsubscribe from this list: send the line "unsubsc
* Christoph Hellwig 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
> > based on
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=3253950&os=2100&dlc=en&lc=en&cc=us
Please post your .config.
--
error compiling committee.
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
Marc
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
Date: Mon, 11 May 2009 18:04:15 +0800
Subject: [PATC
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
Date: Tue, 28 Apr 200
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
2009/5/11 Avi Kivity :
> 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 gu
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 o
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 0xff 0xff 0xff 0xff
0x00 0x00 0
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 targ
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
qemu
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 Soren
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 list:
Avi Kivity wrote:
ehrha...@linux.vnet.ibm.com wrote:
From: Carsten Otte
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 free.
Reported-by:
Avi Kivity wrote:
ehrha...@linux.vnet.ibm.com wrote:
From: Carsten Otte
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 the virtual cpus.
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
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 wo
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.
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
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,
* Han, Weidong wrote:
> 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,
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.
Christoph Hellwig wrote:
> On Fri, May 08, 2009 at 08:49:04PM -0400, Masami Hiramatsu wrote:
>> Use ®s->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
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":
> __install
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
* Avi Kivity 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 CF
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
> Cc: Ana
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 t
* 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 while trying to acquire a
> spinloc
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
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] : F
Ingo Molnar wrote:
> * Masami Hiramatsu 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 jus
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
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
c
Ingo Molnar wrote:
* 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 while trying to acq
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 pa
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 ev
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
* Avi Kivity 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 want to go back and
burn CPU time in VM conte
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
On Mon, 2009-05-11 at 17:51 +0300, Avi Kivity wrote:
> Ingo Molnar wrote:
> > * 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 wha
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 running
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":
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
Ingo Molnar wrote:
* Avi Kivity 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 want to go back an
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_
* Avi Kivity 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 1-2 usecs.
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 h
Ingo Molnar wrote:
* Avi Kivity 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 cy
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
vcp
> Ingo Molnar wrote:
> > * Avi Kivity 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
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
---
x86/external-module-compat.h |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/x86/external-module-compat.h b/x86/external-mo
Also x86_64 before 2.6.26 requires kvm_smp_send_reschedule.
Signed-off-by: Jan Kiszka
---
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 b/external-module-comp
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
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, ma
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 f
Christoph Hellwig 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 kernel module but
From: Michael Burns
Signed-off-by: Michael Burns
---
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 a/client/tests/kvm_runtest_2/control
b/client/
> >> 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 o
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 n
From: Randy Dunlap
Add missing ; to fix build error:
arch/x86/kvm/x86.c:1259: error: expected',' or ';' before 'const'
Signed-off-by: Randy Dunlap
---
arch/x86/kvm/x86.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20090511.orig/arc
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"
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
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.
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 tra
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 igno
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 sa
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 cache=writeb
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 some circumstances) and instruct
1 - 100 of 148 matches
Mail list logo
