On Mon, Mar 22, 2010 at 10:55:18AM +0100, Alexander Graf wrote:
On 22.03.2010, at 10:15, Dor Laor wrote:
On 03/21/2010 01:29 PM, Thomas Løcke wrote:
Hey,
What is considered best practice when running a KVM host with a
mixture of Linux and Windows guests?
Currently I have ntpd
userspace untouched.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/kvm/x86.c |6 ++
include/linux/kvm.h |1 +
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 714aae2..74f0dc3 100644
--- a/arch/x86/kvm/x86.c
+++ b
adds documentation about kvmclock, which to date, we lacked.
Glauber Costa (5):
Add a global synchronization point for pvclock
change msr numbers for kvmclock
Try using new kvm clock msrs
export new cpuid KVM_CAP
add documentation about kvmclock
Documentation/kvm/kvmclock.txt | 138
Avi pointed out a while ago that those MSRs falls into the pentium
PMU range. So the idea here is to add new ones, and after a while,
deprecate the old ones.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/include/asm/kvm_para.h |8 ++--
arch/x86/kvm/x86.c
source guaranteed to be stable wrt time warps.
After this patch is applied, I don't see a single warp in time during 5 days
of execution, in any of the machines I saw them before.
Signed-off-by: Glauber Costa glom...@redhat.com
CC: Jeremy Fitzhardinge jer...@goop.org
CC: Avi Kivity
This patch adds a new file, kvm/kvmclock.txt, describing
the mechanism we use in kvmclock.
Signed-off-by: Glauber Costa glom...@redhat.com
---
Documentation/kvm/kvmclock.txt | 138
1 files changed, 138 insertions(+), 0 deletions(-)
create mode 100644
-existant MSR, we raise a lethal #GP, since our
idt handlers are not in place yet.
So this patch tests for a cpuid feature exported by the host to
decide which set of msrs are supported.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/include/asm/kvm_para.h |4 ++
arch/x86/kernel
On Thu, Apr 15, 2010 at 12:28:36PM -0700, Randy Dunlap wrote:
On Thu, 15 Apr 2010 14:37:28 -0400 Glauber Costa wrote:
Thanks Randy,
All coments relevant. I'll update the document to cover them.
As for your question: Both bit 3 and 0 are used, yes. But they
tell the guest to use a different
On Mon, Apr 19, 2010 at 02:10:54PM +0300, Avi Kivity wrote:
On 04/19/2010 02:05 PM, Peter Zijlstra wrote:
ACCESS_ONCE() is your friend.
I think it's implied with atomic64_read().
Yes it would be. I was merely trying to point out that
last = ACCESS_ONCE(last_value);
Is a narrower
On Fri, Apr 16, 2010 at 01:36:34PM -0700, Jeremy Fitzhardinge wrote:
On 04/15/2010 11:37 AM, Glauber Costa wrote:
In recent stress tests, it was found that pvclock-based systems
could seriously warp in smp systems. Using ingo's time-warp-test.c,
I could trigger a scenario as bad as 1.5mi
On Mon, Apr 19, 2010 at 01:19:43PM +0200, Peter Zijlstra wrote:
On Mon, 2010-04-19 at 14:13 +0300, Avi Kivity wrote:
On 04/19/2010 01:56 PM, Peter Zijlstra wrote:
Right, do bear in mind that the x86 implementation of atomic64_read() is
terrifyingly expensive, it is better to not
On Mon, Apr 19, 2010 at 09:19:38AM -0700, Jeremy Fitzhardinge wrote:
On 04/19/2010 07:26 AM, Glauber Costa wrote:
Is the problem that the tscs are starting out of sync, or that they're
drifting relative to each other over time? Do the problems become worse
the longer the uptime? How large
On Tue, Apr 20, 2010 at 12:35:19PM +0300, Avi Kivity wrote:
On 04/20/2010 04:57 AM, Marcelo Tosatti wrote:
Marcelo can probably confirm it, but he has a nehalem with an appearently
very good tsc source. Even this machine warps.
It stops warping if we only write pvclock data structure once
On Tue, Apr 20, 2010 at 12:42:17PM -0700, Jeremy Fitzhardinge wrote:
On 04/20/2010 11:54 AM, Avi Kivity wrote:
On 04/20/2010 09:23 PM, Jeremy Fitzhardinge wrote:
On 04/20/2010 02:31 AM, Avi Kivity wrote:
btw, do you want this code in pvclock.c, or shall we keep it kvmclock
specific?
should be taken into consideration. Which flags are valid
are usually devised via HV negotiation.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/include/asm/pvclock-abi.h |3 ++-
arch/x86/include/asm/pvclock.h |1 +
arch/x86/kernel/pvclock.c |9 +
3
updates
avi asked for. I haven't yet done any HV work on this
(specially because I am not convinced exactly where it is safe to
do).
Let me know what you think.
Thanks
Glauber Costa (6):
Enable pvclock flags in vcpu_time_info structure
Add a global synchronization point for pvclock
change msr
source guaranteed to be stable wrt time warps.
After this patch is applied, I don't see a single warp in time during 5 days
of execution, in any of the machines I saw them before.
Signed-off-by: Glauber Costa glom...@redhat.com
CC: Jeremy Fitzhardinge jer...@goop.org
CC: Avi Kivity
should be taken into consideration. Which flags are valid
are usually devised via HV negotiation.
Signed-off-by: Glauber Costa glom...@redhat.com
CC: Jeremy Fitzhardinge jer...@goop.org
---
arch/x86/include/asm/pvclock-abi.h |3 ++-
arch/x86/include/asm/pvclock.h |1 +
arch/x86/kernel
If the HV told us we can fully trust the TSC, skip any
correction
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/include/asm/kvm_para.h|5 +
arch/x86/include/asm/pvclock-abi.h |1 +
arch/x86/kernel/kvmclock.c |3 +++
arch/x86/kernel/pvclock.c
-existant MSR, we raise a lethal #GP, since our
idt handlers are not in place yet.
So this patch tests for a cpuid feature exported by the host to
decide which set of msrs are supported.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/kernel/kvmclock.c | 56
userspace untouched.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/include/asm/kvm_para.h |4
arch/x86/kvm/x86.c |6 ++
include/linux/kvm.h |1 +
3 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/x86/include/asm
Avi pointed out a while ago that those MSRs falls into the pentium
PMU range. So the idea here is to add new ones, and after a while,
deprecate the old ones.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/include/asm/kvm_para.h |4
arch/x86/kvm/x86.c |7
On Mon, Apr 26, 2010 at 11:11:57AM -0700, Jeremy Fitzhardinge wrote:
On 04/26/2010 10:46 AM, Glauber Costa wrote:
This patch removes one padding byte and transform it into a flags
field. New versions of guests using pvclock will query these flags
upon each read.
Is this necessary
On Tue, Apr 27, 2010 at 10:30:48AM -0300, Marcelo Tosatti wrote:
On Mon, Apr 26, 2010 at 01:46:26PM -0400, Glauber Costa wrote:
Since we're changing the msrs kvmclock uses, we have to communicate
that to the guest, through cpuid. We can add a new KVM_CAP to the
hypervisor, and then patch
On Tue, Apr 27, 2010 at 10:40:13AM -0300, Marcelo Tosatti wrote:
On Mon, Apr 26, 2010 at 01:46:28PM -0400, Glauber Costa wrote:
If the HV told us we can fully trust the TSC, skip any
correction
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/include/asm/kvm_para.h
On Tue, Apr 27, 2010 at 10:30:48AM -0300, Marcelo Tosatti wrote:
On Mon, Apr 26, 2010 at 01:46:26PM -0400, Glauber Costa wrote:
Since we're changing the msrs kvmclock uses, we have to communicate
that to the guest, through cpuid. We can add a new KVM_CAP to the
hypervisor, and then patch
On Tue, Apr 27, 2010 at 09:03:55PM +0300, Avi Kivity wrote:
On 04/27/2010 04:40 PM, Marcelo Tosatti wrote:
On Mon, Apr 26, 2010 at 01:46:28PM -0400, Glauber Costa wrote:
If the HV told us we can fully trust the TSC, skip any
correction
Please drop this. Its not certain what is the best
On Tue, Apr 27, 2010 at 09:12:47PM +0300, Avi Kivity wrote:
On 04/26/2010 08:46 PM, Glauber Costa wrote:
Since we're changing the msrs kvmclock uses, we have to communicate
that to the guest, through cpuid. We can add a new KVM_CAP to the
hypervisor, and then patch userspace to recognize
On Tue, Apr 27, 2010 at 09:07:18PM +0300, Avi Kivity wrote:
On 04/26/2010 08:46 PM, Glauber Costa wrote:
This patch removes one padding byte and transform it into a flags
field. New versions of guests using pvclock will query these flags
upon each read.
Flags, however, will only
), and starting
to use the flag that indicates possible tsc stability (patch 7/7), although
it is still off by default.
Glauber Costa (7):
Enable pvclock flags in vcpu_time_info structure
Add a global synchronization point for pvclock
change msr numbers for kvmclock
export paravirtual cpuid flags
in KVM_GET_SUPPORTED_CPUID.
This makes userspace automatically aware of what we provide. And if we
ever add a new cpuid bit in the future, we have to do that again,
which create some complexity and delay in feature adoption.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/include/asm/kvm_para.h
This patch puts up the flag that tells the guest that we'll warn it
about the tsc being trustworthy or not. By now, we also say
it is not.
---
arch/x86/kvm/x86.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index
If the HV told us we can fully trust the TSC, skip any
correction
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/include/asm/kvm_para.h|5 +
arch/x86/include/asm/pvclock-abi.h |1 +
arch/x86/kernel/kvmclock.c |3 +++
arch/x86/kernel/pvclock.c
-existant MSR, we raise a lethal #GP, since our
idt handlers are not in place yet.
So this patch tests for a cpuid feature exported by the host to
decide which set of msrs are supported.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/kernel/kvmclock.c | 53
Avi pointed out a while ago that those MSRs falls into the pentium
PMU range. So the idea here is to add new ones, and after a while,
deprecate the old ones.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/include/asm/kvm_para.h |4
arch/x86/kvm/x86.c |7
source guaranteed to be stable wrt time warps.
After this patch is applied, I don't see a single warp in time during 5 days
of execution, in any of the machines I saw them before.
Signed-off-by: Glauber Costa glom...@redhat.com
CC: Jeremy Fitzhardinge jer...@goop.org
CC: Avi Kivity
should be taken into consideration. Which flags are valid
are usually devised via HV negotiation.
Signed-off-by: Glauber Costa glom...@redhat.com
CC: Jeremy Fitzhardinge jer...@goop.org
---
arch/x86/include/asm/pvclock-abi.h |3 ++-
arch/x86/include/asm/pvclock.h |1 +
arch/x86/kernel
On Tue, May 04, 2010 at 03:02:24PM +0300, Avi Kivity wrote:
Wallclock writing uses an unprotected global variable to hold the version;
this can cause one guest to interfere with another if both write their
wallclock at the same time.
makes sense to me.
ACK.
--
To unsubscribe from this
This patch series fixes I bug I just found with kvmclock,
when I booted into a kernel without kvmclock enabled.
Since I am setting msrs, I took the oportunity to
use yet another function from upstream qemu (patch 1).
Enjoy
Glauber Costa (2):
replace set_msr_entry with kvm_msr_entry
turn off
this is yet another function that upstream qemu implements,
so we can just use its implementation.
Signed-off-by: Glauber Costa glom...@redhat.com
---
qemu-kvm-x86.c| 39 ---
target-i386/kvm.c |3 +++
2 files changed, 19 insertions(+), 23 deletions
belongs in qemu, since it is the entity
more prepared to detect all kinds of reboots (by means of a cpu_reset),
not to mention the presence of misbehaving guests, that can forget
to turn kvmclock off.
This patch fixes the issue for me.
Signed-off-by: Glauber Costa glom...@redhat.com
---
qemu-kvm-x86.c
On Wed, May 05, 2010 at 10:26:43AM +0300, Avi Kivity wrote:
+msr_data.info.nmsrs = n;
+
+return kvm_vcpu_ioctl(env, KVM_SET_MSRS,msr_data);
+}
+
+
How about a different approach? Query the supported MSRs
(KVM_GET_MSR_LIST or thereabout) and reset them (with special cases
for
On Wed, May 05, 2010 at 06:34:22PM +0300, Avi Kivity wrote:
On 05/05/2010 06:24 PM, Glauber Costa wrote:
On Wed, May 05, 2010 at 10:26:43AM +0300, Avi Kivity wrote:
+msr_data.info.nmsrs = n;
+
+return kvm_vcpu_ioctl(env, KVM_SET_MSRS,msr_data);
+}
+
+
How about a different
Hi,
Avi, in this patch, I am resetting all msrs upon CPU reset.
Hope it is better. Patch 1 is yet another cleanup.
Glauber Costa (2):
change header for kvm_get_msr_list
turn off kvmclock when resetting cpu
qemu-kvm-x86.c | 27 +--
qemu-kvm.h |1 -
2 files
MSR list.
This patch fixes the issue for me.
Signed-off-by: Glauber Costa glom...@redhat.com
---
qemu-kvm-x86.c | 23 +++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/qemu-kvm-x86.c b/qemu-kvm-x86.c
index 5a2b552..bd74316 100644
--- a/qemu-kvm-x86.c
+++ b
On Wed, May 05, 2010 at 10:33:52AM -1000, Zachary Amsden wrote:
On 05/05/2010 09:19 AM, Glauber Costa wrote:
Currently, in the linux kernel, we reset kvmclock if we are rebooting
into a crash kernel through kexec. The rationale, is that a new kernel
won't follow the same memory addresses
Hello,
Avi, this version fixes the issues you raised in the last
review. Hopte it is better now.
A cpuid.txt wil follow as soon as we're set on everything, so
I am not including it yet.
Glauber Costa (8):
Enable pvclock flags in vcpu_time_info structure
Add a global synchronization point
source guaranteed to be stable wrt time warps.
After this patch is applied, I don't see a single warp in time during 5 days
of execution, in any of the machines I saw them before.
Signed-off-by: Glauber Costa glom...@redhat.com
CC: Jeremy Fitzhardinge jer...@goop.org
CC: Avi Kivity
Avi pointed out a while ago that those MSRs falls into the pentium
PMU range. So the idea here is to add new ones, and after a while,
deprecate the old ones.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/include/asm/kvm_para.h |4
arch/x86/kvm/x86.c |7
should be taken into consideration. Which flags are valid
are usually devised via HV negotiation.
Signed-off-by: Glauber Costa glom...@redhat.com
CC: Jeremy Fitzhardinge jer...@goop.org
---
arch/x86/include/asm/pvclock-abi.h |3 ++-
arch/x86/include/asm/pvclock.h |1 +
arch/x86/kernel
This patch puts up the flag that tells the guest that we'll warn it
about the tsc being trustworthy or not. By now, we also say
it is not.
---
arch/x86/kvm/x86.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index
If the HV told us we can fully trust the TSC, skip any
correction
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/include/asm/kvm_para.h|5 +
arch/x86/include/asm/pvclock-abi.h |1 +
arch/x86/kernel/kvmclock.c |3 +++
arch/x86/kernel/pvclock.c
-existant MSR, we raise a lethal #GP, since our
idt handlers are not in place yet.
So this patch tests for a cpuid feature exported by the host to
decide which set of msrs are supported.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/kernel/kvmclock.c | 53
This cpuid, KVM_CPUID_CLOCKSOURCE2, will indicate to the guest
that kvmclock is available through a new set of MSRs. The old ones
are deprecated.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/include/asm/kvm_para.h |4
1 files changed, 4 insertions(+), 0 deletions
This is the fourth version ov kvmclock fixes.
Just two minor changes in patch 5, per avi request, and
the addition of cpuid.txt file, documenting all cpuid flags
we use.
As a side effect, this patch removes the time-travel feature
in kvm guests.
Glauber Costa (9):
Enable pvclock flags
should be taken into consideration. Which flags are valid
are usually devised via HV negotiation.
Signed-off-by: Glauber Costa glom...@redhat.com
CC: Jeremy Fitzhardinge jer...@goop.org
---
arch/x86/include/asm/pvclock-abi.h |3 ++-
arch/x86/include/asm/pvclock.h |1 +
arch/x86/kernel
in KVM_GET_SUPPORTED_CPUID.
This makes userspace automatically aware of what we provide. And if we
ever add a new cpuid bit in the future, we have to do that again,
which create some complexity and delay in feature adoption.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/kvm/x86.c | 34
-existant MSR, we raise a lethal #GP, since our
idt handlers are not in place yet.
So this patch tests for a cpuid feature exported by the host to
decide which set of msrs are supported.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/kernel/kvmclock.c | 53
This file documents cpuid bits used by KVM.
Signed-off-by: Glauber Costa glom...@redhat.com
---
Documentation/kvm/cpuid.txt | 44 +++
1 files changed, 44 insertions(+), 0 deletions(-)
create mode 100644 Documentation/kvm/cpuid.txt
diff --git
This patch puts up the flag that tells the guest that we'll warn it
about the tsc being trustworthy or not. By now, we also say
it is not.
---
arch/x86/kvm/x86.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index
If the HV told us we can fully trust the TSC, skip any
correction
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/include/asm/kvm_para.h|5 +
arch/x86/include/asm/pvclock-abi.h |1 +
arch/x86/kernel/kvmclock.c |3 +++
arch/x86/kernel/pvclock.c
This cpuid, KVM_CPUID_CLOCKSOURCE2, will indicate to the guest
that kvmclock is available through a new set of MSRs. The old ones
are deprecated.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/include/asm/kvm_para.h |4
1 files changed, 4 insertions(+), 0 deletions
Avi pointed out a while ago that those MSRs falls into the pentium
PMU range. So the idea here is to add new ones, and after a while,
deprecate the old ones.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/include/asm/kvm_para.h |4
arch/x86/kvm/x86.c |7
source guaranteed to be stable wrt time warps.
After this patch is applied, I don't see a single warp in time during 5 days
of execution, in any of the machines I saw them before.
Signed-off-by: Glauber Costa glom...@redhat.com
CC: Jeremy Fitzhardinge jer...@goop.org
CC: Avi Kivity
On Wed, May 12, 2010 at 07:47:39AM +0200, Alexander Graf wrote:
On 12.05.2010, at 05:33, Zachary Amsden wrote:
On 05/11/2010 06:17 AM, Glauber Costa wrote:
This is the fourth version ov kvmclock fixes.
Just two minor changes in patch 5, per avi request, and
the addition
On Fri, May 14, 2010 at 04:07:43PM -1000, Zachary Amsden wrote:
I believe this fixes the root cause of the kvmclock warp. It's
quite a plausible phenomenon, and explains why it was so easy to
produce.
You mean this is the case for both SMP and UP, or just UP as we talked
before?
I don't get
On Mon, May 17, 2010 at 09:38:30AM -1000, Zachary Amsden wrote:
On 05/17/2010 05:36 AM, Glauber Costa wrote:
On Fri, May 14, 2010 at 04:07:43PM -1000, Zachary Amsden wrote:
I believe this fixes the root cause of the kvmclock warp. It's
quite a plausible phenomenon, and explains why it was so
This patch adds a file that documents the usage of KVM-specific
MSRs.
Signed-off-by: Glauber Costa glom...@redhat.com
---
Documentation/kvm/msr.txt | 115 +
1 files changed, 115 insertions(+), 0 deletions(-)
create mode 100644 Documentation/kvm
On Wed, May 26, 2010 at 11:35:03AM -0700, Randy Dunlap wrote:
On Wed, 26 May 2010 14:04:48 -0400 Glauber Costa wrote:
Thanks Randy.
Update version will follow.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo
This patch adds a file that documents the usage of KVM-specific
MSRs.
[ v2: added comments from Randy ]
Signed-off-by: Glauber Costa glom...@redhat.com
---
Documentation/kvm/msr.txt | 117 +
1 files changed, 117 insertions(+), 0 deletions(-)
create
On Thu, May 27, 2010 at 11:15:43AM +0300, Avi Kivity wrote:
On 05/26/2010 09:04 PM, Glauber Costa wrote:
This patch adds a file that documents the usage of KVM-specific
MSRs.
Looks good. A few comments:
+
+Custom MSR list
+
+
+The current supported Custom MSR list
This patch adds a file that documents the usage of KVM-specific
MSRs.
[ v2: added comments from Randy ]
[ v2: added comments from Avi ]
Signed-off-by: Glauber Costa glom...@redhat.com
---
Documentation/kvm/msr.txt | 152 +
1 files changed, 152
On Thu, May 27, 2010 at 10:13:12AM -1000, Zachary Amsden wrote:
On 05/27/2010 06:02 AM, Glauber Costa wrote:
On Thu, May 27, 2010 at 11:15:43AM +0300, Avi Kivity wrote:
On 05/26/2010 09:04 PM, Glauber Costa wrote:
This patch adds a file that documents the usage of KVM-specific
MSRs.
Looks
On Thu, May 27, 2010 at 11:02:35AM -1000, Zachary Amsden wrote:
On 05/27/2010 10:36 AM, Glauber Costa wrote:
On Thu, May 27, 2010 at 10:13:12AM -1000, Zachary Amsden wrote:
On 05/27/2010 06:02 AM, Glauber Costa wrote:
On Thu, May 27, 2010 at 11:15:43AM +0300, Avi Kivity wrote:
On 05/26/2010
On Sun, May 30, 2010 at 12:14:21PM +0300, Avi Kivity wrote:
On 05/27/2010 07:02 PM, Glauber Costa wrote:
+
+Custom MSR list
+
+
+The current supported Custom MSR list is:
+
+MSR_KVM_WALL_CLOCK: 0x11
+
+ data: physical address of a memory area.
Which must be in guest RAM (i.e
This patch adds a file that documents the usage of KVM-specific
MSRs.
[ v2: added comments from Randy ]
[ v3: added comments from Avi ]
[ v4: added information about wallclock alignment ]
Signed-off-by: Glauber Costa glom...@redhat.com
Reviewed-by: Randy Dunlap randy.dun...@oracle.com
On Tue, Jun 01, 2010 at 03:33:43PM +0300, Avi Kivity wrote:
Accept a CPUState parameter instead of a kvm_context_t.
Signed-off-by: Avi Kivity a...@redhat.com
Acked-by: Glauber Costa glom...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message
On Tue, Jun 01, 2010 at 03:33:44PM +0300, Avi Kivity wrote:
Signed-off-by: Avi Kivity a...@redhat.com
Acked-by: Glauber Costa glom...@redhat.com
--
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
On Tue, Jun 01, 2010 at 03:33:45PM +0300, Avi Kivity wrote:
Be more similar to upstream.
Signed-off-by: Avi Kivity a...@redhat.com
Acked-by: Glauber Costa glom...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
On Tue, Jun 01, 2010 at 03:33:46PM +0300, Avi Kivity wrote:
Currently all content from qemu-kvm's kvm_arch_init_vcpu().
Signed-off-by: Avi Kivity a...@redhat.com
Acked-by: Glauber Costa glom...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message
On Tue, Jun 01, 2010 at 03:33:47PM +0300, Avi Kivity wrote:
Signed-off-by: Avi Kivity a...@redhat.com
Acked-by: Glauber Costa glom...@redhat.com
--
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
This patch adds initial support for the -machine option, that allows
command line specification of machine attributes.
Besides its value per-se, it is the saner way we found to
allow for enabling/disabling of kvm's in-kernel irqchip.
machine-related options like kernel, initrd, etc, are now
On Tue, Sep 29, 2009 at 10:39:57AM -0500, Anthony Liguori wrote:
Dietmar Maurer wrote:
this patch solves the problem by calculation an average bandwidth.
Can you take a look Glauber?
Regards,
Anthony Liguori
- Dietmar
-Original Message-
From: kvm-ow...@vger.kernel.org
On Tue, Sep 29, 2009 at 06:36:57PM +0200, Dietmar Maurer wrote:
Also, if this is really the case (buffered), then the bandwidth capping
part
of migration is also wrong.
Have you compared the reported bandwidth to your actual bandwith ? I
suspect
the source of the problem can be that
that is not reasonable?
- Dietmar
-Original Message-
From: Glauber Costa [mailto:glom...@redhat.com]
Sent: Mittwoch, 30. September 2009 06:49
To: Dietmar Maurer
Cc: Anthony Liguori; kvm
Subject: Re: migrate_set_downtime bug
On Tue, Sep 29, 2009 at 06:36:57PM +0200, Dietmar Maurer
On Wed, Sep 30, 2009 at 08:24:18AM +0200, Avi Kivity wrote:
On 09/29/2009 10:45 PM, Mark McLoughlin wrote:
On Tue, 2009-05-05 at 09:56 +0100, Mark McLoughlin wrote:
This commit:
commit 559a8f45f34cc50d1a60b4f67a06614d506b2e01
Subject: Remove stray GSO code from virtio_net (Mark
On Wed, Sep 30, 2009 at 04:11:32PM +0200, Dietmar Maurer wrote:
On Wed, Sep 30, 2009 at 10:55:24AM +0200, Dietmar Maurer wrote:
Another problem occur when max_downtime is too short. This can
results in never ending migration task.
To reproduce just play a video inside a VM and set
On Mon, Oct 05, 2009 at 02:17:30PM +0200, Avi Kivity wrote:
On 09/30/2009 08:41 PM, Dietmar Maurer wrote:
I just think of common scenarios like 'maintanace mode', where all VM should
migrate to another host. A endless migrate task can make that fail.
For me, it is totally unclear what value
On Mon, Oct 05, 2009 at 04:09:43PM +0200, Dietmar Maurer wrote:
Heuristics like number of pages, maybe. But since we don't export
iteration information, we can't expect management tools to stop the
guest if migration doesn't converge.
I suppose it could issue a 'stop' after some amount
.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/kvm/x86.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 11a6f2f..747e566 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -503,16 +503,19
, never goes backwards.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/include/asm/kvm_host.h |1 +
arch/x86/kvm/x86.c | 19 ++-
include/linux/kvm.h |1 +
3 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/arch/x86/include
On Tue, Oct 06, 2009 at 10:30:14AM +0200, Dietmar Maurer wrote:
'bandwidth' is something that changes dynamically (or by user
settings), so why don't we simply abort after some amount of
transferred memory (constant * memory size). This can be implemented by
the management application
On Wed, Oct 07, 2009 at 06:42:48AM +0200, Dietmar Maurer wrote:
The default downtime is set to 30ms. This value triggers the
convergence problem quite often. Maybe a longer default is more
reasonable.
What do you feel about 100 ms?
What is the reasoning behind such short downtimes? Are
On Thu, Oct 08, 2009 at 04:09:27PM +0200, Avi Kivity wrote:
On 10/08/2009 03:55 PM, Anthony Liguori wrote:
Glauber Costa wrote:
This patch provides kvm with an in-kernel apic. We are currently not
enabling it.
The code is heavily based on what's in qemu-kvm.git.
Signed-off-by: Glauber
On Thu, Oct 08, 2009 at 04:31:57PM +0200, Avi Kivity wrote:
On 10/08/2009 04:26 PM, Anthony Liguori wrote:
Avi Kivity wrote:
On 10/08/2009 03:55 PM, Anthony Liguori wrote:
You should probably just setup VMState such that it directly saves
kvm_lapic_state and then have the pre/post
On Thu, Oct 08, 2009 at 09:39:13AM -0500, Anthony Liguori wrote:
The sync stuff is really ugly too. It would be much cleaner to have a
separate state for the in-kernel device models that saved the structures
from the kernel directly instead of having to translate between formats.
More
abort() needs it. Build with kvm disabled breaks without it.
Signed-off-by: Glauber Costa glom...@redhat.com
---
qemu-kvm.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/qemu-kvm.h b/qemu-kvm.h
index 4a86d19..98fbbdf 100644
--- a/qemu-kvm.h
+++ b/qemu-kvm.h
@@ -13,6
On Fri, Oct 09, 2009 at 11:06:41AM +0100, Jamie Lokier wrote:
Glauber Costa wrote:
It ensures the two models are compatible. Since they're the same device
from the point of view of the guest, there's no reason for them to have
different representations or to be incompatible
On Thu, Oct 08, 2009 at 06:22:48PM +0200, Gleb Natapov wrote:
On Thu, Oct 08, 2009 at 06:17:57PM +0200, Avi Kivity wrote:
On 10/08/2009 06:07 PM, Jamie Lokier wrote:
Haven't we already confirmed that it *isn't* just an ioapic accelerator
because you can't migrate between in-kernel iopic and
This series aims at cleanin up vcpu_context structure. I am not removing yet
the fd field, because it is used in the ioctls, and I want to do it separadedly.
But after this series, this structure exists only as a way to hold the file
descriptor,
and is, much cleaner, and much closer to upstream
1 - 100 of 951 matches
Mail list logo
