From: Jes Sorensen j...@sgi.com
Signed-off-by: Jes Sorensen j...@sgi.com
Signed-off-by: Avi Kivity a...@redhat.com
diff --git a/target-ia64/exec.h b/target-ia64/exec.h
index 37b64f7..060d9c3 100644
--- a/target-ia64/exec.h
+++ b/target-ia64/exec.h
@@ -53,4 +53,9 @@ static inline int
From: Avi Kivity a...@redhat.com
Obsolete.
Signed-off-by: Avi Kivity a...@redhat.com
diff --git a/vl.c b/vl.c
index 0420634..6b4b7d2 100644
--- a/vl.c
+++ b/vl.c
@@ -4930,24 +4930,6 @@ static void *alloc_mem_area(size_t memory, unsigned long
*len, const char *path)
}
#endif
-static void
From: Jes Sorensen j...@sgi.com
[avi: make it build on x86]
Signed-off-by: Jes Sorensen j...@sgi.com
Signed-off-by: Avi Kivity a...@redhat.com
diff --git a/Makefile b/Makefile
index 8e4906f..72653c3 100644
--- a/Makefile
+++ b/Makefile
@@ -419,7 +419,12 @@ tarbin:
.PHONY: kvm/extboot
-all:
On Thu, 7 May 2009 11:40:39 pm Michael S. Tsirkin wrote:
This replaces find_vq/del_vq with find_vqs/del_vqs virtio operations,
and updates all drivers. This is needed for MSI support, because MSI
needs to know the total number of vectors upfront.
Hmm, I have a similar need for a dev to vq
On Thu, May 07, 2009 at 05:55:12PM -0300, mtosa...@redhat.com wrote:
KVM uses a function call IPI to cause the exit of a guest running on a
physical cpu. For virtual interrupt notification there is no need to
wait on IPI receival, or to execute any function.
This is exactly what the
On Fri, May 08, 2009 at 02:25:11AM -0300, Glauber Costa wrote:
On Wed, May 06, 2009 at 01:51:04PM +0300, Avi Kivity wrote:
Gleb Natapov wrote:
On Tue, May 05, 2009 at 02:40:11PM -0400, Glauber Costa wrote:
diff --git a/arch/x86/include/asm/kvm_host.h
Marcelo Tosatti wrote:
Also it would be interesting to see the MMIO comparison with EPT/NPT,
it probably sucks much less than what you're seeing.
Why would NPT improve mmio? If anything, it would be worse, since the
processor has to do the nested walk.
Of course, these are newer
Gregory Haskins wrote:
Anthony Liguori wrote:
Gregory Haskins wrote:
Today, there is no equivelent of a platform agnostic iowrite32() for
hypercalls so the driver would look like the pseudocode above except
substitute with kvm_hypercall(), lguest_hypercall(), etc. The proposal
is to
Davide Libenzi wrote:
On Thu, 7 May 2009, Avi Kivity wrote:
What's your take on adding irq context safe callbacks to irqfd?
To give some background here, we would like to use eventfd as a generic
connector between components, so the components do not know about each other.
So far eventfd
Dong, Eddie wrote:
Move Double-Fault generation logic out of page fault
exception generating function to cover more generic case.
Signed-off-by: Eddie Dong eddie.d...@intel.com
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index ab1fdac..51a8dad 100644
---
Gregory Haskins wrote:
Ack. I hope when its all said and done I can convince you that the
framework to code up those virtio backends in the kernel is vbus ;)
If vbus doesn't bring significant performance advantages, I'll prefer
virtio because of existing investment.
Just to
Dong, Eddie wrote:
No content (except for quoted message)?
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
--
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
Marcelo Tosatti wrote:
I think comparison is not entirely fair. You're using
KVM_HC_VAPIC_POLL_IRQ (null hypercall) and the compiler optimizes that
(on Intel) to only one register read:
nr = kvm_register_read(vcpu, VCPU_REGS_RAX);
Whereas in a real hypercall for (say) PIO you would
Gleb Natapov wrote:
+
+static int exception_class(int vector)
+{
+if (vector == 14)
+return EXCPT_PF;
+else if (vector == 0 || (vector = 10 vector = 13)) +
return
EXCPT_CONTRIBUTORY; +else
+return EXCPT_BENIGN;
+}
+
This makes
On Friday 08 May 2009 01:16:53 Alex Williamson wrote:
On Thu, 2009-05-07 at 11:09 -0600, Alex Williamson wrote:
Fix the index at which we return -ENOSPC since the kernel side will
reject a GSI = KVM_MAX_IRQ_ROUTES. Also, mask as a signed int before
testing for error.
Even with this,
On Fri, May 08, 2009 at 04:27:28PM +0800, Dong, Eddie wrote:
Gleb Natapov wrote:
+
+static int exception_class(int vector)
+{
+ if (vector == 14)
+ return EXCPT_PF;
+ else if (vector == 0 || (vector = 10 vector = 13)) +
return
EXCPT_CONTRIBUTORY; +
ction will be re-executed.
Do you want it to be covered for now? For exception, it is easy but
for IRQ, it needs to be pushed back.
Yes I want it to be covered now otherwise any serial exception
generates flood of Exception happens serially messages. This
function does not handle IRQ so
Dong, Eddie wrote:
ction will be re-executed.
Do you want it to be covered for now? For exception, it is easy but
for IRQ, it needs to be pushed back.
Yes I want it to be covered now otherwise any serial exception
generates flood of Exception happens serially messages. This
function does
Avi Kivity wrote:
Marcelo Tosatti wrote:
I think comparison is not entirely fair. You're using
KVM_HC_VAPIC_POLL_IRQ (null hypercall) and the compiler optimizes that
(on Intel) to only one register read:
nr = kvm_register_read(vcpu, VCPU_REGS_RAX);
Whereas in a real hypercall for
Avi Kivity wrote:
Gregory Haskins wrote:
Ack. I hope when its all said and done I can convince you that the
framework to code up those virtio backends in the kernel is vbus ;)
If vbus doesn't bring significant performance advantages, I'll prefer
virtio because of existing
Marcelo Tosatti wrote:
Also it would be interesting to see the MMIO comparison with EPT/NPT,
it probably sucks much less than what you're seeing.
Why would NPT improve mmio? If anything, it would be worse, since the
processor has to do the nested walk.
I suppose the hardware
On Fri, May 08, 2009 at 06:39:06PM +0800, Dong, Eddie wrote:
ction will be re-executed.
Do you want it to be covered for now? For exception, it is easy but
for IRQ, it needs to be pushed back.
Yes I want it to be covered now otherwise any serial exception
generates flood of
On Fri, May 08, 2009 at 06:46:14PM +0800, Dong, Eddie wrote:
Dong, Eddie wrote:
ction will be re-executed.
Do you want it to be covered for now? For exception, it is easy but
for IRQ, it needs to be pushed back.
Yes I want it to be covered now otherwise any serial exception
Marcelo Tosatti wrote:
On Fri, May 08, 2009 at 10:59:00AM +0300, Avi Kivity wrote:
Marcelo Tosatti wrote:
I think comparison is not entirely fair. You're using
KVM_HC_VAPIC_POLL_IRQ (null hypercall) and the compiler optimizes that
(on Intel) to only one register read:
nr =
On Fri, May 08, 2009 at 04:37:06PM +0930, Rusty Russell wrote:
On Thu, 7 May 2009 11:40:39 pm Michael S. Tsirkin wrote:
This replaces find_vq/del_vq with find_vqs/del_vqs virtio operations,
and updates all drivers. This is needed for MSI support, because MSI
needs to know the total number
On Fri, May 08, 2009 at 10:18:14AM +0300, Gleb Natapov wrote:
On Fri, May 08, 2009 at 02:25:11AM -0300, Glauber Costa wrote:
On Wed, May 06, 2009 at 01:51:04PM +0300, Avi Kivity wrote:
Gleb Natapov wrote:
On Tue, May 05, 2009 at 02:40:11PM -0400, Glauber Costa wrote:
diff --git
Marcelo Tosatti wrote:
On Thu, May 07, 2009 at 01:03:45PM -0400, Gregory Haskins wrote:
Chris Wright wrote:
* Gregory Haskins (ghask...@novell.com) wrote:
Chris Wright wrote:
VF drivers can also have this issue (and typically use mmio).
I at least have a
On Fri, May 08, 2009 at 10:55:37AM +0300, Avi Kivity wrote:
Marcelo Tosatti wrote:
Also it would be interesting to see the MMIO comparison with EPT/NPT,
it probably sucks much less than what you're seeing.
Why would NPT improve mmio? If anything, it would be worse, since the
processor
Marcelo Tosatti wrote:
On Fri, May 08, 2009 at 10:55:37AM +0300, Avi Kivity wrote:
Marcelo Tosatti wrote:
Also it would be interesting to see the MMIO comparison with EPT/NPT,
it probably sucks much less than what you're seeing.
Why would NPT improve mmio? If anything,
Gregory Haskins wrote:
Greg,
I think comparison is not entirely fair.
snip
FYI: I've update the test/wiki to (hopefully) address your concerns.
http://developer.novell.com/wiki/index.php/WhyHypercalls
And we're now getting close to the point where the difference is
virtually
On Fri, May 08, 2009 at 10:45:52AM -0400, Gregory Haskins wrote:
Marcelo Tosatti wrote:
On Fri, May 08, 2009 at 10:55:37AM +0300, Avi Kivity wrote:
Marcelo Tosatti wrote:
Also it would be interesting to see the MMIO comparison with EPT/NPT,
it probably sucks much less than
On Fri, May 08, 2009 at 08:43:40AM -0400, Gregory Haskins wrote:
Marcelo Tosatti wrote:
On Fri, May 08, 2009 at 10:59:00AM +0300, Avi Kivity wrote:
Marcelo Tosatti wrote:
I think comparison is not entirely fair. You're using
KVM_HC_VAPIC_POLL_IRQ (null hypercall) and the
Gregory Haskins wrote:
Consider nested virtualization where the host (H) runs a guest (G1)
which is itself a hypervisor, running a guest (G2). The host exposes
a set of virtio (V1..Vn) devices for guest G1. Guest G1, rather than
creating a new virtio devices and bridging it to one of V1..Vn,
From 01813db8627e74018c8cec90df7e345839351f23 Mon Sep 17 00:00:00 2001
From: Mark Langsdorf mark.langsd...@amd.com
Date: Thu, 7 May 2009 09:44:10 -0500
Subject: [PATCH] Add support for Pause Filtering to AMD SVM
This feature creates a new field in the VMCB called Pause
Filter Count. If Pause
On Fri, May 08, 2009 at 11:00:51PM +0800, Dong, Eddie wrote:
Gleb Natapov wrote:
On Fri, May 08, 2009 at 06:46:14PM +0800, Dong, Eddie wrote:
Dong, Eddie wrote:
ction will be re-executed.
Do you want it to be covered for now? For exception, it is easy
but for IRQ, it needs to be
Mark Langsdorf wrote:
From 01813db8627e74018c8cec90df7e345839351f23 Mon Sep 17 00:00:00 2001
From: Mark Langsdorf mark.langsd...@amd.com
Date: Thu, 7 May 2009 09:44:10 -0500
Subject: [PATCH] Add support for Pause Filtering to AMD SVM
What's the differences wrt retry 1?
This feature
Anthony Liguori wrote:
And we're now getting close to the point where the difference is
virtually meaningless.
At .14us, in order to see 1% CPU overhead added from PIO vs HC, you
need 71429 exits.
If I read things correctly, you want the difference between PIO and
PIOoHC, which is
From: Michael Burns mbu...@redhat.com
Signed-off-by: Michael Burns mbu...@redhat.com
---
client/tests/kvm_runtest_2/control| 14 +-
client/tests/kvm_runtest_2/kvm_install.py | 11 +++
2 files changed, 24 insertions(+), 1 deletions(-)
diff --git
Avi Kivity wrote:
Anthony Liguori wrote:
And we're now getting close to the point where the difference is
virtually meaningless.
At .14us, in order to see 1% CPU overhead added from PIO vs HC, you
need 71429 exits.
If I read things correctly, you want the difference between PIO and
What's the differences wrt retry 1?
I'm using git format-patch as you requested.
This feature creates a new field in the VMCB called Pause
Filter Count. If Pause Filter Count is greater than 0 and
intercepting PAUSEs is enabled, the processor will increment
an internal counter when a
Marcelo Tosatti wrote:
On Fri, May 08, 2009 at 08:43:40AM -0400, Gregory Haskins wrote:
The problem is the exit time in of itself isnt all that interesting to
me. What I am interested in measuring is how long it takes KVM to
process the request and realize that I want to execute function X.
Gregory Haskins wrote:
Its more of an issue of execution latency (which translates to IO
latency, since execution is usually for the specific goal of doing
some IO). In fact, per my own design claims, I try to avoid exits like
the plague and generally succeed at making very few of them. ;)
So
Anthony Liguori wrote:
ia64 uses mmio to emulate pio, so the cost may be different. I agree
on x86 it's almost negligible.
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
Gregory Haskins wrote:
And likewise, in both cases, G1 would (should?) know what to do with
that address as it relates to G2, just as it would need to know what
the PIO address is for. Typically this would result in some kind of
translation of that address, but I suppose even this is completely
Hi folks, it's a pleasure to join the team!
One of our goals with autotest kvm is to get all the work done so far
back to the autotest upstream project. I looked at the code, and have
sketched a plan to do it. Some considerations first:
1 Currently several parts of the code don't follow the
Paul E. McKenney wrote:
On Fri, May 08, 2009 at 08:43:40AM -0400, Gregory Haskins wrote:
Marcelo Tosatti wrote:
On Fri, May 08, 2009 at 10:59:00AM +0300, Avi Kivity wrote:
Marcelo Tosatti wrote:
I think comparison is not entirely fair. You're using
Marcelo Tosatti wrote:
On Fri, May 08, 2009 at 10:45:52AM -0400, Gregory Haskins wrote:
Marcelo Tosatti wrote:
On Fri, May 08, 2009 at 10:55:37AM +0300, Avi Kivity wrote:
Marcelo Tosatti wrote:
Also it would be interesting to see the MMIO comparison with EPT/NPT,
it probably
Avi Kivity wrote:
Gregory Haskins wrote:
And likewise, in both cases, G1 would (should?) know what to do with
that address as it relates to G2, just as it would need to know what
the PIO address is for. Typically this would result in some kind of
translation of that address, but I suppose
David S. Ahern wrote:
Marcelo Tosatti wrote:
On Fri, May 08, 2009 at 10:45:52AM -0400, Gregory Haskins wrote:
Marcelo Tosatti wrote:
On Fri, May 08, 2009 at 10:55:37AM +0300, Avi Kivity wrote:
Marcelo Tosatti wrote:
Also it would be
Due to a small messup in version checking, migration was not working.
fix it.
Signed-off-by: Glauber Costa glom...@redhat.com
---
migration-tcp.c |1 +
savevm.c |1 +
target-i386/helper.c |1 +
target-i386/machine.c |8
4 files changed, 7
Hi,
This is the same patch you're all used to by now, but split in two per
Avi request.
--
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
we currently unblock shadow interrupt state when we skip an instruction,
but failing to do so when we actually emulate one. This blocks interrupts
in key instruction blocks, in particular sti; hlt; sequences
If the instruction emulated is an sti, we have to block shadow interrupts.
The same goes
This patch replaces drop_interrupt_shadow with the more
general set_interrupt_shadow, that can either drop or raise
it, depending on its parameter.
Signed-off-by: Glauber Costa glom...@redhat.com
CC: H. Peter Anvin h...@zytor.com
CC: Avi Kivity a...@redhat.com
CC: Gleb Natapov g...@redhat.com
---
Avi Kivity wrote:
kvm does not support all cpu features; add support for dunamically querying
the supported feature set.
Signed-off-by: Avi Kivity a...@redhat.com
---
kvm.h |3 ++
target-i386/kvm.c | 80 +
2 files changed,
Huang Ying wrote:
- MCE features are initialized when VCPU is intialized according to CPUID.
- A monitor command mce is added to inject a MCE.
- A new interrupt mask: CPU_INTERRUPT_MCE is added to inject the MCE.
Signed-off-by: Huang Ying ying.hu...@intel.com
---
cpu-all.h |
Hi Sheng,
I think I'm running into the following deadlock in the kvm kernel module
when trying to use device assignment:
CPU A CPU B
kvm_vm_ioctl_deassign_dev_irq()
mutex_lock(kvm-lock); worker_thread()
- kvm_deassign_irq() -
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 usable run time. Instead, track
used GSIs in a bitmap.
On Fri, 2009-05-08 at 00:11 +0200, Arnd Bergmann wrote:
On Thursday 07 May 2009, Chris Wright wrote:
Chris, is that issue with the non ioread/iowrite access of a mangled
pointer still an issue here? I would think so, but I am a bit fuzzy on
whether there is still an issue of
Gregory Haskins wrote:
David S. Ahern wrote:
Marcelo Tosatti wrote:
On Fri, May 08, 2009 at 10:45:52AM -0400, Gregory Haskins wrote:
Marcelo Tosatti wrote:
On Fri, May 08, 2009 at 10:55:37AM +0300, Avi Kivity wrote:
Marcelo Tosatti wrote:
In message 49d396ab.6090...@redhat.com, you write:
Via engineers have contacted me and confirmed that this is a problem in
the processor.
Is there a known-fixed CPU revision?
Is there a way to identify working vs. non-working chips, either from IC
stamp or from /proc/cpuinfo? (Bonus: is it
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 mhira...@redhat.com
Cc: Ananth N Mavinakayanahalli
Cleanup fix_riprel() in arch/x86/kernel/kprobes.c by using x86 instruction
decoder.
Signed-off-by: Masami Hiramatsu mhira...@redhat.com
Cc: Ananth N Mavinakayanahalli ana...@in.ibm.com
Cc: Jim Keniston jkeni...@us.ibm.com
Cc: Ingo Molnar mi...@elte.hu
---
arch/x86/kernel/kprobes.c | 128
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 anywhere where kprobes can probe(this means, all
functions body except for
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.
This version introduces instruction attributes for decoding instructions.
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)
[ impact: Oprofile decodes only stack for backtracing on i386 ]
Signed-off-by: Masami Hiramatsu mhira...@redhat.com
Cc: Harvey Harrison harvey.harri...@gmail.com
Cc: Ingo
Add following APIs for accessing registers and stack entries from pt_regs.
- query_register_offset(const char *name)
Query the offset of name register.
- query_register_name(unsigned offset)
Query the name of register by its offset.
- get_register(struct pt_regs *regs, unsigned offset)
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
just needs kprobes/kretprobes and register and stack access APIs).
This
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 memory at SYM +|- offs (SYM should be a data symbol)
68 matches
Mail list logo
