On Mon, Jan 31, 2011 at 03:48:36PM -0500, john cooper wrote:
Marcelo Tosatti wrote:
On Fri, Jan 21, 2011 at 12:21:00AM -0500, john cooper wrote:
[Resubmit of prior version which contained a wayward
patch hunk. Thanks Marcelo]
A correction to Intel cpu model CPUID data (patch queued)
On Mon, 2011-01-31 at 16:40 -0500, Rik van Riel wrote:
v8:
- some more changes and cleanups suggested by Peter
Did you, by accident, send out the -v7 patches again? I don't think I've
spotted a difference..
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a
This warning was once used for debugging QEMU user space. Though
uncommon, it is actually possible to send an INIT request to a running
VCPU. So better drop this warning before someone misuses it to flood
kernel logs this way.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
On 01/31/2011 10:39 PM, Anthony Liguori wrote:
On 01/31/2011 12:10 PM, Jan Kiszka wrote:
On 2011-01-31 11:02, Juan Quintela wrote:
Please send in any agenda items you are interested incovering.
o KVM upstream merge: status, plans, coordination
o QMP support status for 0.14. Luiz and I
Currently we have some ad-hoc code in x86.c to restrict #UD emulation to
expected instructions (that is, vendor specific instructions). This patchset
replaces the ad-hoc code with proper emulator support using decode tables.
Avi Kivity (3):
KVM: Drop bogus x86_decode_insn() error check
v2:
x86_decode_insn() doesn't return X86EMUL_* values, so the check
for X86EMUL_PROPOGATE_FAULT will always fail. There is a proper
check later on, so there is no need for a replacement for this
code.
Signed-off-by: Avi Kivity a...@redhat.com
---
arch/x86/kvm/x86.c |3 ---
1 files changed, 0
Mark some instructions as vendor specific, and allow the caller to request
emulation only of vendor specific instructions. This is useful in some
circumstances (responding to a #UD fault).
Signed-off-by: Avi Kivity a...@redhat.com
---
arch/x86/include/asm/kvm_emulate.h |1 +
Use the new support in the emulator, and drop the ad-hoc code in x86.c.
Signed-off-by: Avi Kivity a...@redhat.com
---
arch/x86/kvm/x86.c | 31 +++
1 files changed, 3 insertions(+), 28 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index
On Mon, 31 Jan 2011 15:39:22 -0600
Anthony Liguori anth...@codemonkey.ws wrote:
On 01/31/2011 12:10 PM, Jan Kiszka wrote:
On 2011-01-31 11:02, Juan Quintela wrote:
Please send in any agenda items you are interested incovering.
o KVM upstream merge: status, plans,
On Tue, 1 Feb 2011 10:53:21 -0200
Luiz Capitulino lcapitul...@redhat.com wrote:
On Mon, 31 Jan 2011 15:39:22 -0600
Anthony Liguori anth...@codemonkey.ws wrote:
On 01/31/2011 12:10 PM, Jan Kiszka wrote:
On 2011-01-31 11:02, Juan Quintela wrote:
Please send in any agenda items
On Tue, Feb 01, 2011 at 10:38:35AM -0200, Marcelo Tosatti wrote:
@@ -943,7 +951,11 @@ bool cpu_exec_all(void)
if (qemu_alarm_pending())
break;
if (cpu_can_run(env)) {
-if (qemu_cpu_exec(env) == EXCP_DEBUG) {
+r =
On Thu, Jan 27, 2011 at 02:09:56PM +0100, Jan Kiszka wrote:
Move qemu_kvm_eat_signals around and call it also when the IO-thread is
not used. Do not yet process SIGBUS, will be armed in a separate step.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
cpus.c | 88
On Thu, Jan 27, 2011 at 02:09:58PM +0100, Jan Kiszka wrote:
Found by Stefan Hajnoczi: There is a race in kvm_cpu_exec between
checking for exit_request on vcpu entry and timer signals arriving
before KVM starts to catch them. Plug it by blocking both timer related
signals also on
On Thu, Jan 27, 2011 at 02:10:00PM +0100, Jan Kiszka wrote:
Introduce qemu_cpu_kick_self to send SIG_IPI to the calling VCPU
context. First user will be kvm.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
cpus.c| 21 +
qemu-common.h |1 +
2 files
On 2011-02-01 13:38, Marcelo Tosatti wrote:
On Thu, Jan 27, 2011 at 02:09:56PM +0100, Jan Kiszka wrote:
Move qemu_kvm_eat_signals around and call it also when the IO-thread is
not used. Do not yet process SIGBUS, will be armed in a separate step.
Signed-off-by: Jan Kiszka
On Thu, 27 Jan 2011 16:20:27 +0800
Lai Jiangshan la...@cn.fujitsu.com wrote:
cpu-index which uses hyphen is better name.
Signed-off-by: Lai Jiangshan la...@cn.fujitsu.com
It looks ok from a quick pass, but I can't apply it on current master, what
commit HEAD did you?
Btw, please, do
On 2011-02-01 13:47, Marcelo Tosatti wrote:
On Thu, Jan 27, 2011 at 02:09:58PM +0100, Jan Kiszka wrote:
Found by Stefan Hajnoczi: There is a race in kvm_cpu_exec between
checking for exit_request on vcpu entry and timer signals arriving
before KVM starts to catch them. Plug it by blocking both
On 2011-02-01 14:14, Marcelo Tosatti wrote:
On Thu, Jan 27, 2011 at 02:10:00PM +0100, Jan Kiszka wrote:
Introduce qemu_cpu_kick_self to send SIG_IPI to the calling VCPU
context. First user will be kvm.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
cpus.c| 21
On Tue, Feb 01, 2011 at 02:32:38PM +0100, Jan Kiszka wrote:
On 2011-02-01 13:47, Marcelo Tosatti wrote:
On Thu, Jan 27, 2011 at 02:09:58PM +0100, Jan Kiszka wrote:
Found by Stefan Hajnoczi: There is a race in kvm_cpu_exec between
checking for exit_request on vcpu entry and timer signals
On Tue, Feb 01, 2011 at 02:33:45PM +0100, Jan Kiszka wrote:
+++ b/cpus.c
@@ -531,6 +531,17 @@ void qemu_cpu_kick(void *env)
return;
}
+void qemu_cpu_kick_self(void)
+{
+#ifndef _WIN32
+assert(cpu_single_env);
+
+raise(SIG_IPI);
+#else
+abort();
On 2011-02-01 14:48, Marcelo Tosatti wrote:
On Tue, Feb 01, 2011 at 02:32:38PM +0100, Jan Kiszka wrote:
On 2011-02-01 13:47, Marcelo Tosatti wrote:
On Thu, Jan 27, 2011 at 02:09:58PM +0100, Jan Kiszka wrote:
Found by Stefan Hajnoczi: There is a race in kvm_cpu_exec between
checking for
On 2011-02-01 14:50, Marcelo Tosatti wrote:
On Tue, Feb 01, 2011 at 02:33:45PM +0100, Jan Kiszka wrote:
+++ b/cpus.c
@@ -531,6 +531,17 @@ void qemu_cpu_kick(void *env)
return;
}
+void qemu_cpu_kick_self(void)
+{
+#ifndef _WIN32
+assert(cpu_single_env);
+
+
On Tue, Feb 01, 2011 at 02:58:02PM +0100, Jan Kiszka wrote:
On 2011-02-01 14:48, Marcelo Tosatti wrote:
On Tue, Feb 01, 2011 at 02:32:38PM +0100, Jan Kiszka wrote:
On 2011-02-01 13:47, Marcelo Tosatti wrote:
On Thu, Jan 27, 2011 at 02:09:58PM +0100, Jan Kiszka wrote:
Found by Stefan
On 2011-02-01 15:10, Marcelo Tosatti wrote:
On Tue, Feb 01, 2011 at 02:58:02PM +0100, Jan Kiszka wrote:
On 2011-02-01 14:48, Marcelo Tosatti wrote:
On Tue, Feb 01, 2011 at 02:32:38PM +0100, Jan Kiszka wrote:
On 2011-02-01 13:47, Marcelo Tosatti wrote:
On Thu, Jan 27, 2011 at 02:09:58PM +0100,
Mark some instructions as vendor specific, and allow the caller to request
emulation only of vendor specific instructions. This is useful in some
circumstances (responding to a #UD fault).
Signed-off-by: Avi Kivity a...@redhat.com
---
arch/x86/include/asm/kvm_emulate.h |1 +
x86_decode_insn() doesn't return X86EMUL_* values, so the check
for X86EMUL_PROPOGATE_FAULT will always fail. There is a proper
check later on, so there is no need for a replacement for this
code.
Signed-off-by: Avi Kivity a...@redhat.com
---
arch/x86/kvm/x86.c |3 ---
1 files changed, 0
Use the new support in the emulator, and drop the ad-hoc code in x86.c.
Signed-off-by: Avi Kivity a...@redhat.com
---
arch/x86/kvm/x86.c | 33 +
1 files changed, 5 insertions(+), 28 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index
On 02/01/2011 05:53 AM, Peter Zijlstra wrote:
On Mon, 2011-01-31 at 16:40 -0500, Rik van Riel wrote:
v8:
- some more changes and cleanups suggested by Peter
Did you, by accident, send out the -v7 patches again? I don't think I've
spotted a difference..
Arghhh. Yeah, I did :(
--
All
On 01.02.2011, at 13:56, Luiz Capitulino wrote:
On Tue, 1 Feb 2011 10:53:21 -0200
Luiz Capitulino lcapitul...@redhat.com wrote:
On Mon, 31 Jan 2011 15:39:22 -0600
Anthony Liguori anth...@codemonkey.ws wrote:
On 01/31/2011 12:10 PM, Jan Kiszka wrote:
On 2011-01-31 11:02, Juan Quintela
On 2011-02-01 15:21, Jan Kiszka wrote:
On 2011-02-01 15:10, Marcelo Tosatti wrote:
On Tue, Feb 01, 2011 at 02:58:02PM +0100, Jan Kiszka wrote:
On 2011-02-01 14:48, Marcelo Tosatti wrote:
On Tue, Feb 01, 2011 at 02:32:38PM +0100, Jan Kiszka wrote:
On 2011-02-01 13:47, Marcelo Tosatti wrote:
On 2011-02-01 15:37, Jan Kiszka wrote:
On 2011-02-01 15:21, Jan Kiszka wrote:
On 2011-02-01 15:10, Marcelo Tosatti wrote:
On Tue, Feb 01, 2011 at 02:58:02PM +0100, Jan Kiszka wrote:
On 2011-02-01 14:48, Marcelo Tosatti wrote:
On Tue, Feb 01, 2011 at 02:32:38PM +0100, Jan Kiszka wrote:
On
With CONFIG_FAIR_GROUP_SCHED, each task_group has its own cfs_rq.
Yielding to a task from another cfs_rq may be worthwhile, since
a process calling yield typically cannot use the CPU right now.
Therefor, we want to check the per-cpu nr_running, not the
cgroup local one.
Signed-off-by: Rik van
From: Mike Galbraith efa...@gmx.de
Currently only implemented for fair class tasks.
Add a yield_to_task method() to the fair scheduling class. allowing the
caller of yield_to() to accelerate another thread in it's thread group,
task group.
Implemented via a scheduler hint, using cfs_rq-next to
Export the symbols required for a race-free kvm_vcpu_on_spin.
Signed-off-by: Rik van Riel r...@redhat.com
diff --git a/kernel/fork.c b/kernel/fork.c
index 3b159c5..adc8f47 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -191,6 +191,7 @@ void __put_task_struct(struct task_struct *tsk)
When running SMP virtual machines, it is possible for one VCPU to be
spinning on a spinlock, while the VCPU that holds the spinlock is not
currently running, because the host scheduler preempted it to run
something else.
Both Intel and AMD CPUs have a feature that detects when a virtual
CPU is
The clear_buddies function does not seem to play well with the concept
of hierarchical runqueues. In the following tree, task groups are
represented by 'G', tasks by 'T', next by 'n' and last by 'l'.
(nl)
/\
G(nl) G
/ \ \
T(l) T(n) T
This situation can arise when a
Keep track of which task is running a KVM vcpu. This helps us
figure out later what task to wake up if we want to boost a
vcpu that got preempted.
Unfortunately there are no guarantees that the same task
always keeps the same vcpu, so we can only track the task
across a single run of the vcpu.
Instead of sleeping in kvm_vcpu_on_spin, which can cause gigantic
slowdowns of certain workloads, we instead use yield_to to get
another VCPU in the same KVM guest to run sooner.
This seems to give a 10-15% speedup in certain workloads.
Signed-off-by: Rik van Riel r...@redhat.com
Signed-off-by:
Use the buddy mechanism to implement yield_task_fair. This
allows us to skip onto the next highest priority se at every
level in the CFS tree, unless doing so would introduce gross
unfairness in CPU time distribution.
We order the buddy selection in pick_next_entity to check
yield first, then
On 02/01/2011 08:37 AM, Alexander Graf wrote:
o SeaBIOS update for 0.14 - I'd like to see an AHCI boot capable version there
I'll update to the latest release before I fork today.
Regards,
Anthony Liguori
Alex
--
To unsubscribe from this list: send the line unsubscribe kvm in
On 01.02.2011, at 16:05, Anthony Liguori wrote:
On 02/01/2011 08:37 AM, Alexander Graf wrote:
o SeaBIOS update for 0.14 - I'd like to see an AHCI boot capable version
there
I'll update to the latest release before I fork today.
Last time I checked, AHCI was disabled by default.
Please merge for 2.6.38. Not the most elegant fix,
but it does fix the noise in dmesg that interferes with
kvm debugging, and probably the best we can do for 2.6.38.
The following changes since commit fca540ab5f4718c6133f71f7be1793066008bf89:
enc28j60: Fix reading of transmit status vector
On Sun, 2011-01-30 at 15:13 +0200, Avi Kivity wrote:
On 01/28/2011 09:52 PM, Glauber Costa wrote:
To implement steal time, we need the hypervisor to pass the guest
information
about how much time was spent running other processes outside the VM.
This is per-vcpu, and using the kvmclock
On Tue, 2011-02-01 at 09:50 -0500, Rik van Riel wrote:
+/**
+ * yield_to - yield the current processor to another thread in
+ * your thread group, or accelerate that thread toward the
+ * processor it's on.
+ *
+ * It's the caller's job to ensure that the target task struct
+ * can't go
On Tue, 2011-02-01 at 09:51 -0500, Rik van Riel wrote:
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -375,13 +375,6 @@ static struct ctl_table kern_table[] = {
.mode = 0644,
.proc_handler = sched_rt_handler,
},
- {
-
OK, so thinking about it more, maybe the issue is this:
tx becomes full. We process one request and interrupt the guest,
then it adds one request and the queue is full again.
Maybe the following will help it stabilize? By default with it we will
only interrupt when we see an empty ring.
Which is
On Sun, 2011-01-30 at 15:16 +0200, Avi Kivity wrote:
On 01/28/2011 09:52 PM, Glauber Costa wrote:
Register steal time within KVM. Everytime we sample the steal time
information, we update a local variable that tells what was the
last time read. We then account the difference.
KVM upstream merge: status, plans, coordination
- Jan has a git tree, consolidating
- qemu-kvm io threading is still an issue
- Anthony wants to just merge
- concerns with non-x86 arch and merge
- concerns with big-bang patch merge and following stability
- post 0.14 conversion to glib
On Sun, 2011-01-30 at 15:19 +0200, Avi Kivity wrote:
On 01/28/2011 09:52 PM, Glauber Costa wrote:
This patch adds documentation about usage of the newly
introduced KVM_MSR_STEAL_TIME.
+
+MSR_KVM_STEAL_TIME: 0x4b564d03
+
+ data: 4-byte alignment physical address of a memory area
On Sun, 2011-01-30 at 16:04 +0200, Avi Kivity wrote:
On 01/28/2011 09:52 PM, Glauber Costa wrote:
This patch accounts steal time time in kernel/sched.
I kept it from last proposal, because I still see advantages
in it: Doing it here will give us easier access from scheduler
variables such
On Mon, 2011-01-31 at 00:45 +0800, lidong chen wrote:
I think we can use performance counter.
use unhalted core cycles event, in the nmi callback funcation, count
which process is running .
if the vm exit is caused by nmi,discard it.
the system time of qemu process is the time steal by kvm.
On Mon, 2011-01-31 at 12:25 +0100, Peter Zijlstra wrote:
On Fri, 2011-01-28 at 14:52 -0500, Glauber Costa wrote:
+#ifdef CONFIG_PARAVIRT_TIME_ACCOUNTING
+static DEFINE_PER_CPU(u64, cpu_steal_time);
+
+#ifndef CONFIG_64BIT
+static DEFINE_PER_CPU(seqcount_t, steal_time_seq);
+
On Sat, 2011-01-29 at 09:56 +0100, Jan Kiszka wrote:
On 2011-01-29 03:07, Glauber Costa wrote:
On Fri, 2011-01-28 at 22:09 +0100, Jan Kiszka wrote:
On 2011-01-28 20:48, Glauber Costa wrote:
Up to know, we were relying on guest cooperation to turn off kvmclock.
I just realized that even
On Tue, 2011-02-01 at 13:53 -0200, Glauber Costa wrote:
And since the granularity of the cpu accounting is too coarse, we end up
with much more steal time than we should, because things that are less
than 1 unity of cputime, are often rounded up to 1 unity of cputime.
See, that! is the
On Tue, 2011-02-01 at 13:59 -0200, Glauber Costa wrote:
Because that part is kvm-specific, and this is scheduler general.
It seemed cleaner to me to do it this way. But I can do it differently,
certainly.
Well, any steal time clock will be hypervisor specific, but if we agree
that anything
On 2011-02-01 16:54, Chris Wright wrote:
KVM upstream merge: status, plans, coordination
- Jan has a git tree, consolidating
- qemu-kvm io threading is still an issue
- Anthony wants to just merge
- concerns with non-x86 arch and merge
- concerns with big-bang patch merge and following
On Tue, 2011-02-01 at 17:19 +0100, Peter Zijlstra wrote:
On Tue, 2011-02-01 at 13:59 -0200, Glauber Costa wrote:
Because that part is kvm-specific, and this is scheduler general.
It seemed cleaner to me to do it this way. But I can do it differently,
certainly.
Well, any steal time
On 02/01/2011 10:36 AM, Jan Kiszka wrote:
On 2011-02-01 16:54, Chris Wright wrote:
KVM upstream merge: status, plans, coordination
- Jan has a git tree, consolidating
- qemu-kvm io threading is still an issue
- Anthony wants to just merge
- concerns with non-x86 arch and merge
-
NOTE: Resending the series with the Reviewed-by tags updated
The following series implements page cache control,
this is a split out version of patch 1 of version 3 of the
page cache optimization patches posted earlier at
Previous posting http://lwn.net/Articles/419564/
The previous few revision
This patch moves zone_reclaim and associated helpers
outside CONFIG_NUMA. This infrastructure is reused
in the patches for page cache control that follow.
Signed-off-by: Balbir Singh bal...@linux.vnet.ibm.com
Reviewed-by: Christoph Lameter c...@linux.com
---
include/linux/mmzone.h |4 ++--
Changelog v3
1. Renamed zone_reclaim_unmapped_pages to zone_reclaim_pages
Refactor zone_reclaim, move reusable functionality outside
of zone_reclaim. Make zone_reclaim_unmapped_pages modular
Signed-off-by: Balbir Singh bal...@linux.vnet.ibm.com
Reviewed-by: Christoph Lameter c...@linux.com
---
Changelog v4
1. Add max_unmapped_ratio and use that as the upper limit
to check when to shrink the unmapped page cache (Christoph
Lameter)
Changelog v2
1. Use a config option to enable the code (Andrew Morton)
2. Explain the magic tunables in the code or at-least attempt
to explain them
See, that! is the problem, don't round up like that.
Yeah, I was using usecs_to_cputime(), believing this was the standard
interface. By the way, one of the things that also led to better results
were just forcing it to 0 every time we had steal == 1 in the end. But
*that* was a real hack =)
On 2011-02-01 17:53, Anthony Liguori wrote:
On 02/01/2011 10:36 AM, Jan Kiszka wrote:
On 2011-02-01 16:54, Chris Wright wrote:
KVM upstream merge: status, plans, coordination
- Jan has a git tree, consolidating
- qemu-kvm io threading is still an issue
- Anthony wants to just merge
On Tue, 2011-02-01 at 15:00 -0200, Glauber Costa wrote:
What you can do is: steal_ticks = steal_time_clock() / TICK_NSEC, or
simply keep a steal time delta and every time it overflows
cputime_one_jiffy insert a steal-time tick.
What do you think about keeping accounting in msec/usec
On Tue, Feb 01, 2011 at 05:36:13PM +0100, Jan Kiszka wrote:
kvm_cpu_exec/kvm_run, and start wondering What needs to be done to
upstream so that qemu-kvm could use that implementation?. If they
differ, the reasons need to be understood and patched away, either by
fixing/enhancing upstream or
Hi,
testing my KVM patches, I noticed that none of the 64-bit Windows
versions I have around (early Win7 2003 server) boot in KVM mode when
using 2 or more VCPUs and the user space irqchip. This applies to both
upstream KVM and qemu-kvm, with our without any of my current patches. A
subtle
Paolo,
I refactored the savevm functions. Could you give me your
comments?
Thanks,
Yoshi
diff --git a/savevm.c b/savevm.c
index 5418280..90aae55 100644
--- a/savevm.c
+++ b/savevm.c
@@ -1602,29 +1602,68 @@ bool qemu_savevm_state_blocked(Monitor *mon)
return false;
}
-int
On Tue, 2011-02-01 at 14:22 -0200, Glauber Costa wrote:
Which tick accounting? In your other e-mail , you pointed that this only
runs in touch_steal_time, which is fine, will change.
That tick ;-), all the account_foo muck is per tick.
But all the rest
here, that is behind the
When a vcpu is reset, kvmclock page keeps being writen to this days.
This is wrong and inconsistent: a cpu reset should take it to its
initial state.
Signed-off-by: Glauber Costa glom...@redhat.com
CC: Jan Kiszka jan.kis...@siemens.com
---
arch/x86/kvm/x86.c | 20
1 files
If the machine is stopped, we should not record two different tsc values
upon a save operation. The same problem happens with kvmclock.
But kvmclock is taking a different diretion, being now seen as a separate
device. Since this is unlikely to happen with the tsc, I am taking the
approach here of
On Tue, 2011-02-01 at 19:59 +0100, Peter Zijlstra wrote:
On Tue, 2011-02-01 at 14:22 -0200, Glauber Costa wrote:
Which tick accounting? In your other e-mail , you pointed that this only
runs in touch_steal_time, which is fine, will change.
That tick ;-), all the account_foo muck is
On Tue, 2011-02-01 at 19:09 +0200, Avi Kivity wrote:
On 02/01/2011 05:48 PM, Glauber Costa wrote:
@@ -2106,6 +2120,25 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu,
int cpu)
kvm_migrate_timers(vcpu);
vcpu-cpu = cpu;
}
On Tue, 2011-02-01 at 17:55 -0200, Glauber Costa wrote:
update_rq_clock_task still have to keep track of what was the last steal
time value we saw, in the same way it does for irq.
Right, the CONFIG_SCHED_PARAVIRT patch I sent earlier adds a
prev_steal_time member to struct rq for this
When MSI is off, each interrupt needs to be bounced through the io
thread when it's set/cleared, so vhost-net causes more context switches and
higher CPU utilization than userspace virtio which handles networking in
the same thread.
We'll need to fix this by adding level irq support in kvm irqfd,
On Tue, Feb 1, 2011 at 9:44 AM, Peter Zijlstra pet...@infradead.org wrote:
On Tue, 2011-02-01 at 15:00 -0200, Glauber Costa wrote:
What you can do is: steal_ticks = steal_time_clock() / TICK_NSEC, or
simply keep a steal time delta and every time it overflows
cputime_one_jiffy insert a
On Tue, 2011-02-01 at 22:17 +0200, Michael S. Tsirkin wrote:
On Tue, Feb 01, 2011 at 12:09:03PM -0800, Shirley Ma wrote:
On Tue, 2011-02-01 at 19:23 +0200, Michael S. Tsirkin wrote:
On Thu, Jan 27, 2011 at 01:30:38PM -0800, Shirley Ma wrote:
On Thu, 2011-01-27 at 13:02 -0800, David
On 2011-02-01 20:17, Glauber Costa wrote:
If the machine is stopped, we should not record two different tsc values
upon a save operation. The same problem happens with kvmclock.
But kvmclock is taking a different diretion, being now seen as a separate
device. Since this is unlikely to happen
On 02/01/2011 11:34 AM, Jan Kiszka wrote:
On 2011-02-01 18:20, Anthony Liguori wrote:
On 02/01/2011 11:03 AM, Jan Kiszka wrote:
On 2011-02-01 17:53, Anthony Liguori wrote:
On 02/01/2011 10:36 AM, Jan Kiszka wrote:
On 2011-02-01 16:54, Chris Wright wrote:
On 2011-02-01 20:16, Glauber Costa wrote:
When a vcpu is reset, kvmclock page keeps being writen to this days.
This is wrong and inconsistent: a cpu reset should take it to its
initial state.
Signed-off-by: Glauber Costa glom...@redhat.com
CC: Jan Kiszka jan.kis...@siemens.com
---
On 02/01/2011 02:13 PM, Michael S. Tsirkin wrote:
When MSI is off, each interrupt needs to be bounced through the io
thread when it's set/cleared, so vhost-net causes more context switches and
higher CPU utilization than userspace virtio which handles networking in
the same thread.
We'll need
On Tue, 2011-02-01 at 22:13 +0200, Michael S. Tsirkin wrote:
When MSI is off, each interrupt needs to be bounced through the io
thread when it's set/cleared, so vhost-net causes more context switches and
higher CPU utilization than userspace virtio which handles networking in
the same thread.
From: Michael S. Tsirkin m...@redhat.com
Date: Tue, 1 Feb 2011 17:44:40 +0200
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost-net
Pulled, thanks Michael.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More
On Mon, 2011-01-31 at 17:30 -0800, Sridhar Samudrala wrote:
Yes. It definitely should be 'out'. 'in' should be 0 in the tx path.
I tried a simpler version of this patch without any tunables by
delaying the signaling until we come out of the for loop.
It definitely reduced the number of
From: Jan Kiszka jan.kis...@siemens.com
If there is any pending request that requires us to leave the inner loop
if main_loop, makes sure we do this as soon as possible by enforcing
non-blocking IO processing.
At this change, move variable definitions out of the inner loop to
improve
From: Jan Kiszka jan.kis...@siemens.com
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
cpus.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/cpus.c b/cpus.c
index 5dfc54e..312c7a2 100644
--- a/cpus.c
+++ b/cpus.c
@@ -607,8 +607,8 @@ static void
From: Jan Kiszka jan.kis...@siemens.com
Move {tcg,kvm}_init_ipi and block_io_signals to avoid prototypes, rename
the former two to clarify that they deal with more than SIG_IPI. No
functional changes - except for the tiny fixup of strerror usage.
The forward declaration of sigbus_handler is just
From: Jan Kiszka jan.kis...@siemens.com
Will be required for SIGBUS handling. For obvious reasons, this will
remain a nop on Windows hosts.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
---
Makefile.objs |2 +-
cpus.c| 117
From: Jan Kiszka jan.kis...@siemens.com
If some I/O operation ends up calling qemu_system_reset_request in VCPU
context, we record this and inform the io-thread, but we do not
terminate the VCPU loop. This can lead to fairly unexpected behavior if
the triggering reset operation is supposed to
From: Jan Kiszka jan.kis...@siemens.com
Do not ignore errors of kvm_init_vcpu, they are fatal.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
cpus.c | 19 +++
1 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/cpus.c b/cpus.c
index 312c7a2..8475757 100644
From: Jan Kiszka jan.kis...@siemens.com
Except for timer events, we currently do not leave the loop over all
VCPUs if an IO event was filed. That may cause unexpected IO latencies
under !CONFIG_IOTHREAD in SMP scenarios. Fix it by setting the global
exit_request which breaks the loop.
From: Jan Kiszka jan.kis...@siemens.com
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
kvm-all.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index 9976762..1a55a10 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -219,6 +219,7 @@ int
From: Jan Kiszka jan.kis...@siemens.com
No functional changes.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
cpus.c | 97 ++-
1 files changed, 58 insertions(+), 39 deletions(-)
diff --git a/cpus.c b/cpus.c
index
From: Jan Kiszka jan.kis...@siemens.com
The reset we issue on KVM_EXIT_SHUTDOWN implies that we should also
leave the VCPU loop. As we now check for exit_request which is set by
qemu_system_reset_request, this bug is no longer critical. Still it's an
unneeded extra turn.
Signed-off-by: Jan
From: Jan Kiszka jan.kis...@siemens.com
Improve the readability of the exit dispatcher by moving the static
return value of kvm_handle_io to its caller.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
kvm-all.c | 17 -
1 files changed, 8 insertions(+), 9 deletions(-)
From: Jan Kiszka jan.kis...@siemens.com
Block SIG_IPI, unblock it during KVM_RUN, just like in io-thread mode.
It's unused so far, but this infrastructure will be required for
self-IPIs and to process SIGBUS plus, in KVM mode, SIGIO and SIGALRM. As
Windows doesn't support signal services, we need
From: Jan Kiszka jan.kis...@siemens.com
First of all, vm_can_run is a misnomer, it actually means no request
pending. Moreover, there is no need to check all pending requests
twice, the first time via the inner loop check and then again when
actually processing the requests. We can simply remove
Version 2 of part II. Changes:
- Fixed Unconditionally reenter kernel after IO exits to take
self-INIT into account
- Fixed misplaced hunk in Fix race between timer signals and vcpu
entry under !IOTHREAD (rebase artifact)
- Factor out block_synchronous_signals (analogue to
From: Jan Kiszka jan.kis...@siemens.com
If we call qemu_cpu_kick more than once before the target was able to
process the signal, pthread_kill will fail, and qemu will abort. Prevent
this by avoiding the redundant signal.
This logic can be found in qemu-kvm as well.
Signed-off-by: Jan Kiszka
From: Jan Kiszka jan.kis...@siemens.com
Move qemu_kvm_eat_signals around and call it also when the IO-thread is
not used. Do not yet process SIGBUS, will be armed in a separate step.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
cpus.c | 90
1 - 100 of 131 matches
Mail list logo
