On 06/11/2010 06:15 PM, Yang, Sheng wrote:
On Saturday 12 June 2010 01:35:23 Marcelo Tosatti wrote:
On Thu, Jun 10, 2010 at 04:44:05PM -0400, Chris Lalancette wrote:
We really want to "kvm_set_irq" during the hrtimer callback,
but that is risky because that is during interrupt context
Ensure the save struct gets 16-byte alignment.
>From e08c7f6ec354b9605f6dba9771eb76aadd5a71f8 Mon Sep 17 00:00:00 2001
From: Zachary Amsden
Date: Fri, 11 Jun 2010 14:43:21 -1000
Subject: [PATCH] Align FPU save struct to 16-bytes
Otherwise, we get a #GP
Signed-off-by: Zachary Amsden
---
Running kvm_kmod with upstream module on 2.6.33.5-112.local.fc13.x86_64,
I'm getting this exception, looks like the FPU init is still a bit broken.
I'll see if I can debug it a bit and post a patch.
[437469.742812] general protection fault: [#1] SMP
[437469.742821] last sysfs file: /sys/de
On 06/09/2010 11:24 PM, Avi Kivity wrote:
On 06/10/2010 12:17 AM, Zachary Amsden wrote:
On 06/09/2010 03:23 AM, Marcelo Tosatti wrote:
On Tue, Jun 08, 2010 at 04:36:16PM -1000, Zachary Amsden wrote:
+pt->timer.function = pit_timer_fn;
I am happy to see this. I thought kvm_timer_fn
On 06/09/2010 03:23 AM, Marcelo Tosatti wrote:
On Tue, Jun 08, 2010 at 04:36:16PM -1000, Zachary Amsden wrote:
+ pt->timer.function = pit_timer_fn;
I am happy to see this. I thought kvm_timer_fn was a step
backwards; it was too general of a function to justify the savi
On 06/08/2010 07:55 AM, Chris Lalancette wrote:
We really want to "kvm_set_irq" during the hrtimer callback,
but that is risky because that is during interrupt context.
Instead, offload the work to a workqueue, which is a bit safer
and should provide most of the same functionality.
Signed-off-by
On 05/27/2010 02:10 PM, Glauber Costa wrote:
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 05/27/2010 12:12 PM, Bernhard Schmidt wrote:
On 27.05.2010 23:53, Zachary Amsden wrote:
Hello Zachary,
I have server side fixes for this kvm-clock which seem to give me a
stable clock on this machine, but for true SMP stability, you will need
Glauber's guest side changes to kvmclo
On 05/27/2010 12:12 PM, Bernhard Schmidt wrote:
On 27.05.2010 23:53, Zachary Amsden wrote:
Hello Zachary,
I have server side fixes for this kvm-clock which seem to give me a
stable clock on this machine, but for true SMP stability, you will need
Glauber's guest side changes to kvmclo
jumping several hours ahead.
Situation has stabilized after setting clocksource hpet in the guest
immediately after boot. So it seems kvm-clock has some issues here.
I've seen a preliminary patch floating around on the ML by Zachary
Amsden, but I haven't tried it yet. It talks of backward
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 09:04 PM, Glauber Costa wrote:
This
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 good. A few comments:
+
+Custom MSR list
. This was masked by the set in
set_efer until 7657fd5ace88e8092f5f3a84117e093d7b893f26 broke that.
Fix is simply to set the VCPU register before stripping bits.
Signed-off-by: Zachary Amsden
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 100bd4b..a05b63f 100644
--- a/arch/x86/kvm/svm.c
On 05/25/2010 09:40 PM, Jan Kiszka wrote:
Zachary Amsden wrote:
On 05/25/2010 05:36 PM, Zachary Amsden wrote:
Not for the faint of heart, this patch subverts the code by
reassigning a local variable from a macro.
This time, with patch.
From
On 05/25/2010 09:33 PM, Jan Kiszka wrote:
Zachary Amsden wrote:
The FPU interface changed to dynamic allocation; redefine the missing
struct fpu to be a static structure and add back the old macros.
The FPU interface changed to dynamic allocation; redefine the missing struct
fpu to be a
On 05/25/2010 05:28 PM, Zachary Amsden wrote:
I found some issues with kvm-kmod from recently pulled tree on F13
(2.6.33) kernel. I am not 100% sure the version numbers are right in
all of these fixes, but at least it compiles and seems to run VMs again.
The FPU change and the iommu change
On 05/25/2010 05:36 PM, Zachary Amsden wrote:
Not for the faint of heart, this patch subverts the code by
reassigning a local variable from a macro.
This time, with patch.
>From 97b9230f699aba1c5f47972032b2d4d935a83054 Mon Sep 17 00:00:00 2001
From: Zachary Amsden
Date: Tue, 25 May 2010 17
Not for the faint of heart, this patch subverts the code by reassigning
a local variable from a macro.
--
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
>From abbb464f0c2dd9681c4380598a1ac098d024b576 Mon Sep 17 00:00:00 2001
From: Zachary Amsden
Date: Tue, 25 May 2010 16:33:47 -1000
Subject: [PATCH 3/5] Fix AMD module build failure because of undefined MSR
Signed-off-by: Zachary Amsden
---
x86/external-module-compat.h |4
1 fi
The FPU interface changed to dynamic allocation; redefine the missing
struct fpu to be a static structure and add back the old macros.
>From 95be2b1ac41a40f2f3d581f0674b25ca4b70a025 Mon Sep 17 00:00:00 2001
From: Zachary Amsden
Date: Tue, 25 May 2010 16:32:14 -1000
Subject: [PATCH 2/5] Ext
>From 614d5fa8bba5f98fd3cb1d66d63b0b70ca98fe51 Mon Sep 17 00:00:00 2001
From: Zachary Amsden
Date: Fri, 14 May 2010 12:25:14 -1000
Subject: [PATCH 1/5] Fix tboot_enabled macro; was present in 2.6.33
Signed-off-by: Zachary Amsden
---
x86/external-module-compat.h |2 +-
1 files changed
I found some issues with kvm-kmod from recently pulled tree on F13
(2.6.33) kernel. I am not 100% sure the version numbers are right in
all of these fixes, but at least it compiles and seems to run VMs again.
The FPU change and the iommu change are, well, rather scary. They could
use some ey
On 05/18/2010 04:08 AM, Glauber Costa wrote:
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
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 easy to
produce.
You mean this is the case for
s,
Zach
commit 24e1f31a4cdb43a8e5cab6cfb95d710c7c7bf18a
Author: Zachary Amsden
Date: Fri Feb 26 15:13:31 2010 -1000
Fix a possible backwards warp of kvmclock
Kernel time, which advances in discrete steps may progress much slower
than TSC. As a result, when kvmclock is adjuste
ons(+), 23 deletions(-)
create mode 100644 Documentation/kvm/cpuid.txt
Acked-by: Zachary Amsden
--
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
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, and the memory where kvmclock is
located in the first kernel, will be s
es changed, 125 insertions(+), 23 deletions(-)
Acked-by: Zachary Amsden
I'll rebase on top of these if they get pulled.
And obviously, there is no point in checking for warp if Chuck Norris
has perished. I happen to have a special place in my heart for nunchaku
masters despite the
):
replace set_msr_entry with kvm_msr_entry
turn off kvmclock when resetting cpu
qemu-kvm-x86.c| 58 -
target-i386/kvm.c |3 ++
2 files changed, 38 insertions(+), 23 deletions(-)
Acked-by: Zachary Amsden
--
To unsubscribe from
On 04/26/2010 07:46 AM, Glauber Costa wrote:
Hi,
This is the last series I've sent, with comments from you merged.
The first 5 patches are the same, only with the suggested fixes.
I am leaving documentation out, since the basics won't change, and
we're still discussing the details.
Patch 6 is n
On 04/23/2010 11:35 AM, Jeremy Fitzhardinge wrote:
On 04/23/2010 02:31 PM, Zachary Amsden wrote:
Does lfence / mfence actually serialize? I thought there was some
great confusion about that not being the case on all AMD processors,
and possibly not at all on Intel.
A trap, however is a
On 04/23/2010 10:39 AM, Brian Jackson wrote:
On Friday 23 April 2010 12:08:22 David S. Ahern wrote:
After a few days of debugging I think kvmclock is the source of lockups
for a RHEL5.5-based VM. The VM works fine on one host, but repeatedly
locks up on another.
Server 1 - VM locks up repea
On 04/22/2010 11:34 PM, Avi Kivity wrote:
On 04/23/2010 04:44 AM, Zachary Amsden wrote:
Or apply this patch.
time-warp.patch
diff -rup a/time-warp-test.c b/time-warp-test.c
--- a/time-warp-test.c2010-04-15 16:30:13.955981607 -1000
+++ b/time-warp-test.c2010-04-15 16:35:37.777982377
On 04/22/2010 03:11 AM, Glauber Costa wrote:
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 wan
On 04/20/2010 09:42 AM, 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?
On 04/19/2010 11:39 PM, Avi Kivity wrote:
On 04/19/2010 09:35 PM, Zachary Amsden wrote:
Sockets and boards too? (IOW, how reliable is TSC_RELIABLE)?
Not sure, IIRC we clear that when the TSC sync test fails, eg when we
mark the tsc clocksource unusable.
Worrying. By the time we detect this
On 04/19/2010 11:35 PM, 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 and
forget it,
(wh
On 04/19/2010 12:54 AM, Avi Kivity wrote:
On 04/19/2010 01:51 PM, Peter Zijlstra wrote:
Right, so on x86 we have:
X86_FEATURE_CONSTANT_TSC, which only states that TSC is frequency
independent, not that it doesn't stop in C states and similar fun
stuff.
X86_FEATURE_TSC_RELIABLE, which IIRC
On 04/16/2010 10:36 AM, 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 warps a minute in som
On 03/30/10 07:04, Beinicke, Thomas wrote:
> On Tuesday 30 March 2010 10:08:28 Sebastian Hetze wrote:
>
>> On Mon, Mar 29, 2010 at 11:31:13AM +0100, Athanasius wrote:
>>
>>> On Sun, Mar 28, 2010 at 01:46:35PM +0200, Sebastian Hetze wrote:
>>>
this message appeared in the KVM gue
On 03/26/10 23:14, Blue Swirl wrote:
> On 3/26/10, Zachary Amsden wrote:
>
>> For some reason, this uses CONFIG_TARGET_I386 instead of TARGET_I386, so
>> the code is dead.
>>
> The code is also broken: it references undefined variable 'buf'
> inst
For some reason, this uses CONFIG_TARGET_I386 instead of TARGET_I386, so
the code is dead.
CONFIG_TARGET_XXX is wrong
Signed-off-by: Zachary Amsden
diff --git a/vl.c b/vl.c
index 6e35cc6..9720619 100644
--- a/vl.c
+++ b/vl.c
@@ -1565,7 +1565,7 @@ static void configure_rtc(QemuOpts *opts
es it only applies to
i386 and i'm running debian amd64.
TARGET_I386 is also true for amd64. However, the code appears broken
upstream.
CONFIG_TARGET_XXX is wrong
Signed-off-by: Zachary Amsden
diff --git a/vl.c b/vl.c
index 6e35cc6..9720619 100644
--- a/vl.c
+++ b/vl.c
@@
On 03/18/2010 11:15 AM, Ingo Molnar wrote:
* Zachary Amsden wrote:
On 03/18/2010 12:50 AM, Ingo Molnar wrote:
* Avi Kivity wrote:
The moment any change (be it as trivial as fixing a GUI detail or as
complex as a new feature) involves two or more packages, development
On 03/18/2010 12:50 AM, Ingo Molnar wrote:
* Avi Kivity wrote:
The moment any change (be it as trivial as fixing a GUI detail or as
complex as a new feature) involves two or more packages, development speed
slows down to a crawl - while the complexity of the change might be very
low!
On 03/17/2010 07:41 PM, Sheng Yang wrote:
On Thursday 18 March 2010 13:22:28 Sheng Yang wrote:
On Thursday 18 March 2010 12:50:58 Zachary Amsden wrote:
On 03/17/2010 03:19 PM, Sheng Yang wrote:
On Thursday 18 March 2010 05:14:52 Zachary Amsden wrote:
On 03/16/2010
On 03/17/2010 03:19 PM, Sheng Yang wrote:
On Thursday 18 March 2010 05:14:52 Zachary Amsden wrote:
On 03/16/2010 11:28 PM, Sheng Yang wrote:
On Wednesday 17 March 2010 10:34:33 Zhang, Yanmin wrote:
On Tue, 2010-03-16 at 11:32 +0200, Avi Kivity wrote:
On 03/16/2010
On 03/17/2010 12:17 PM, Thomas Løcke wrote:
On Wed, Mar 17, 2010 at 8:33 PM, Zachary Amsden wrote:
What's your host CPU load get up to. You only have a single core?
Dual core.
If I only run a single Windows VM, the host load is pretty low. Sure
it goes up a bit when for ex
On 03/16/2010 11:28 PM, Sheng Yang wrote:
On Wednesday 17 March 2010 10:34:33 Zhang, Yanmin wrote:
On Tue, 2010-03-16 at 11:32 +0200, Avi Kivity wrote:
On 03/16/2010 09:48 AM, Zhang, Yanmin wrote:
Right, but there is a scope between kvm_guest_enter and really running
in guest
On 03/17/2010 09:22 AM, Thomas Løcke wrote:
Hey all,
I'm working on moving from a mixture of physical servers and
virtualized servers running on Virtualbox, to a pure KVM setup. But
I'm having some problems with my Windows XP guests in my test-setup.
This is the host I'm testing on:
CPU: Intel
On 03/05/2010 07:05 AM, Daniel P. Berrange wrote:
On Fri, Mar 05, 2010 at 06:50:47AM -1000, Zachary Amsden wrote:
On 03/05/2010 04:27 AM, Daniel P. Berrange wrote:
* HPET
Multiple timers with periodic interrupts
Can replace PIT/RTC timers
They all generally suck in real
On 03/05/2010 04:27 AM, Daniel P. Berrange wrote:
This mail describes how I'm suggesting libvirt addresses Dor's RFE to
timers/tick policies in libvirt
https://bugzilla.redhat.com/show_bug.cgi?id=557285
Thanks to those who've answered my previous mail / irc questions. Please
point out any mi
On 03/04/2010 10:00 AM, Lucas Meneghel Rodrigues wrote:
On Tue, 2010-03-02 at 11:11 +0100, Peter Zijlstra wrote:
On Mon, 2010-03-01 at 09:14 -0600, Anthony Liguori wrote:
The real
question to ask is, why are you using qemu directly instead of using
virt-manager?
Because I sus
On 03/03/2010 11:43 PM, Gilles PIETRI wrote:
Hi,
I have a host running a 2.6.32.7 kernel, and I'm using qemu-kvm
0.12.2. I have multiple guests, and one of them is running Windows XP.
If I stare at the clock, I see that every now & then (~5s), it slows
down a bit, and then try to cope with it
On 03/01/2010 11:45 AM, Anthony Liguori wrote:
On 03/01/2010 02:56 PM, Ingo Molnar wrote:
- Code distribution is easy: it comes with the kernel. This spreads
the code
far and wide. It's easy for kernel developers to jump in and help
out, the
latest devel code is always there, a singl
On 02/26/2010 05:55 AM, Peter Zijlstra wrote:
On Fri, 2010-02-26 at 17:11 +0200, Avi Kivity wrote:
On 02/26/2010 05:08 PM, Peter Zijlstra wrote:
That's 7 more than what we support now, and 7 more than what we can
guarantee without it.
Again, what windows software uses only
On 02/26/2010 03:37 AM, Jes Sorensen wrote:
On 02/26/10 14:31, Ingo Molnar wrote:
You are missing two big things wrt. compatibility here:
1) The first upgrade overhead a one time overhead only.
2) Once a Linux guest has upgraded, it will work in the future,
with _any_
future CPU - _
On 03/01/2010 07:41 AM, Arnaldo Carvalho de Melo wrote:
Em Mon, Mar 01, 2010 at 06:48:07AM -1000, Zachary Amsden escreveu:
On 02/27/2010 07:25 AM, Ingo Molnar wrote:
I'm not talking about moving it into a kernel _module_ - albeit that
alone is a worthwile thing to do fo
On 02/26/2010 01:42 AM, Ingo Molnar wrote:
* Jes Sorensen wrote:
On 02/26/10 11:44, Ingo Molnar wrote:
Direct access to counters is not something that is a big issue. [ Given that i
sometimes can see KVM redraw the screen of a guest OS real-time i doubt this
is the biggest of perfor
On 02/27/2010 07:25 AM, Ingo Molnar wrote:
* Zachary Amsden wrote:
[...]
Second, it's not over-modularized. The modules are the individual
components of the architecture. How would you propose to put it
differently. They really can't naturally combine. And with the
code
On 02/27/2010 12:56 AM, Ingo Molnar wrote:
* Avi Kivity wrote:
On 02/26/2010 01:17 PM, Ingo Molnar wrote:
Nobody is really 'in charge' of how KVM gets delivered to the user. You
isolated the fun kernel part for you and pushed out the boring bits to
user-space. So if mundane things l
On 02/26/2010 06:31 AM, Zachary Amsden wrote:
On 02/26/2010 01:18 AM, Avi Kivity wrote:
On 02/26/2010 06:57 AM, Zachary Amsden wrote:
Anyone seeing list_add corruption running qemu-kvm with -smp 2 on
Intel hardware?
Debugging some local changes, which don't appear related. Running
m
On 02/26/2010 01:18 AM, Avi Kivity wrote:
On 02/26/2010 06:57 AM, Zachary Amsden wrote:
Anyone seeing list_add corruption running qemu-kvm with -smp 2 on
Intel hardware?
Debugging some local changes, which don't appear related. Running
module from latest git on F12.
Can you post a
Anyone seeing list_add corruption running qemu-kvm with -smp 2 on Intel
hardware?
Debugging some local changes, which don't appear related. Running
module from latest git on F12.
Zach
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger
On 02/24/2010 05:23 AM, Joerg Roedel wrote:
On Sun, Feb 21, 2010 at 02:09:15PM +0100, Joerg Roedel wrote:
On Sun, Feb 21, 2010 at 02:54:01PM +0200, Avi Kivity wrote:
So, if some other cpu (or the guest itself, with appropriate
permissions) modifies the msr permission bitmap, svm will
On 02/22/2010 07:11 AM, Avi Kivity wrote:
On 02/22/2010 07:07 PM, Zachary Amsden wrote:
On 02/22/2010 07:02 AM, Avi Kivity wrote:
On 02/22/2010 07:00 PM, Zachary Amsden wrote:
The force vmexit would generate an INTR #vmexit even if the INTR
intercept was disabled and even if no INTR is
On 02/22/2010 07:02 AM, Avi Kivity wrote:
On 02/22/2010 07:00 PM, Zachary Amsden wrote:
The force vmexit would generate an INTR #vmexit even if the INTR
intercept was disabled and even if no INTR is pending. However this
was shot down since there was no equivalent vmx exit reason that we
can
On 02/22/2010 06:44 AM, Avi Kivity wrote:
On 02/22/2010 06:42 PM, Zachary Amsden wrote:
On 02/21/2010 02:24 AM, Avi Kivity wrote:
On 02/21/2010 02:10 PM, Joerg Roedel wrote:
It is doable but I still think its
complicated to get this right. The simplest approach would be to
disallow migration
On 02/21/2010 05:56 AM, Joerg Roedel wrote:
On Sun, Feb 21, 2010 at 05:07:45PM +0200, Avi Kivity wrote:
On 02/21/2010 04:43 PM, Joerg Roedel wrote:
Difficult. We could use an instruction intercept which has no side
effect on guest state (invlpg for example).
Especially as the
On 02/21/2010 04:43 AM, Joerg Roedel wrote:
On Sun, Feb 21, 2010 at 03:40:55PM +0200, Avi Kivity wrote:
On 02/21/2010 03:14 PM, Avi Kivity wrote:
(Either synthetic msrs, or an new state ioctl). The state would
contain a bit that says whether the guest is in guest or host mode.
Howev
On 02/21/2010 03:09 AM, Joerg Roedel wrote:
On Sun, Feb 21, 2010 at 02:54:01PM +0200, Avi Kivity wrote:
So, if some other cpu (or the guest itself, with appropriate
permissions) modifies the msr permission bitmap, svm will not notice
this? svm loads the bitmap during entry?
Yes.
On 02/21/2010 02:24 AM, Avi Kivity wrote:
On 02/21/2010 02:10 PM, Joerg Roedel wrote:
It is doable but I still think its
complicated to get this right. The simplest approach would be to
disallow migration when the vcpu is running in guest mode.
Agree, though I dislike the need to introduce a
On 02/21/2010 02:10 AM, Joerg Roedel wrote:
On Sat, Feb 20, 2010 at 01:26:49PM -1000, Zachary Amsden wrote:
The infrastructure is already there to import / export and migrate MSR
settings. MSRs are also 64-bit, and hold "model-specific" settings, so
if you don't mind thinkin
On Sat, Feb 20, 2010 at 09:14:06AM -1000, Zachary Amsden wrote:
Perhaps I am misunderstanding, but I don't see how nested SVM instances
can be properly migrated. How does one extract and rebuild the nested
hsave control block?
Migrating guests which run in nested mode could n
Perhaps I am misunderstanding, but I don't see how nested SVM instances
can be properly migrated. How does one extract and rebuild the nested
hsave control block?
If it isn't done already, one possible way to add it as an extension
might be to represent the data as additional MSRs which are s
Hi,
The CR3 caching was never implemented in QEMU and is obsoleted by
NPT/EPT. This patch removes the unused references to it from
target-i386/kvm.c.
This feature was broken by design. Glad to see it go.
Zach
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a
Hi,
The CR3 caching was never implemented in QEMU and is obsoleted by
NPT/EPT. This patch removes the unused references to it from
target-i386/kvm.c.
This feature was broken by design. Glad to see it go.
Zach
On 02/16/2010 02:39 PM, Marcelo Tosatti wrote:
On Mon, Feb 15, 2010 at 10:45:42AM +0100, Jan Kiszka wrote:
The interrupt shadow created by STI or MOV-SS-like operations is part of
the VCPU state and must be preserved across migration. Transfer it in
the spare padding field of kvm_vcpu_events
On 12/19/2009 11:59 PM, Avi Kivity wrote:
On 12/15/2009 05:38 AM, Zachary Amsden wrote:
On 12/14/2009 01:22 AM, Joerg Roedel wrote:
The tsc_offset adjustment in svm_vcpu_load is executed
unconditionally even if Linux considers the host tsc as
stable. This causes a Linux guest detecting an
On 12/15/2009 08:21 AM, Marcelo Tosatti wrote:
On Mon, Dec 14, 2009 at 06:08:42PM -1000, Zachary Amsden wrote:
+ atomic_set(&per_cpu(cpu_tsc_synchronized, freq->cpu),
0);
+ spin_lock(&kvm_lock);
+ list_for_each_entry(kvm,&v
run first and figure out the CPU speed.
Signed-off-by: Zachary Amsden
---
arch/x86/kvm/x86.c | 38 --
1 files changed, 28 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 1cc51ca..faa467d 100644
--- a/arch/x86/kvm
workaround, which is disabling C1 clock
ramping.
Signed-off-by: Zachary Amsden
---
arch/x86/kvm/x86.c | 45 +
1 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index a599c78..4c4d2e0 100644
--- a
frequency change by allowing single CPUs to
initiate their own synchronization.
During initial setup, cpufreq callbacks can set the cpu_tsc_khz
concurrently with the update, so we fix this by protecting under the
kvm_tsc_lock.
Signed-off-by: Zachary Amsden
---
arch/x86/kvm/x86.c | 163
Add a dumb version of RDTSC trapping for SVM which just passes
through the hardware counter.
Signed-off-by: Zachary Amsden
---
arch/x86/kvm/emulate.c |2 +-
arch/x86/kvm/svm.c | 15 +++
2 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/emulate.c
KVM now maintains a reference TSC, which can be exported to the
individual backends for private use.
Signed-off-by: Zachary Amsden
---
arch/x86/kvm/x86.c | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
Use per-cpu delta counters and statistically eliminate outliers which
might happen due to platform anomalies such as NMI.
Signed-off-by: Zachary Amsden
---
arch/x86/kvm/x86.c | 100 +---
1 files changed, 71 insertions(+), 29 deletions(-)
diff
The loop is written to only work when one master and one slave
enter simultaneously, so properly protect it, and call it when
adding new CPUs.
Signed-off-by: Zachary Amsden
---
arch/x86/kvm/x86.c | 43 ---
1 files changed, 32 insertions(+), 11 deletions
Signed-off-by: Zachary Amsden
---
arch/x86/kvm/x86.c | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index c66dede..8bd362b 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -914,6 +914,7 @@ static void
Add the framework for a preliminary way to cope with CPUs which have
different TSC offsets from each other. The TSC delta is measured
(in cross-cache-directions for highest accuracy) and stored.
Signed-off-by: Zachary Amsden
---
arch/x86/kvm/x86.c | 202
If CPU frequency governors can change the TSC frequency, use
the highest possible frequency as the reference.
Signed-off-by: Zachary Amsden
---
arch/x86/kvm/x86.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index
Resync all CPUs to measure TSC skew periodically. Use the measured skew
to adjust the resync time (not done yet - heuristic needed)
Signed-off-by: Zachary Amsden
---
arch/x86/kvm/x86.c | 93 ++--
1 files changed, 90 insertions(+), 3 deletions
Turns out it wasn't very precise; it needs to work on 64-bit values.
Signed-off-by: Zachary Amsden
---
arch/x86/kvm/x86.c | 18 +++---
1 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 7e2ba3e..792c895 100644
--- a
Add ioctl's to get and set TSC rate per-VM. The TSC rate is set at
creation to the reference tsc rate.
Signed-off-by: Zachary Amsden
---
arch/x86/include/asm/kvm_host.h |4 +++
arch/x86/kvm/kvm_timer.h| 14 +-
arch/x86/kvm/x86.c |
uency.
If the hardware frequency exceeds the VM frequency, intercept mode
is used instead.
Signed-off-by: Zachary Amsden
---
arch/x86/include/asm/kvm_host.h |1 +
arch/x86/kvm/x86.c | 21 -
include/linux/kvm.h | 17 ++---
3 files ch
Quick and dirty hack to get passthrough TSC back in SVM.
Signed-off-by: Zachary Amsden
---
arch/x86/kvm/svm.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 91eb263..91107a4 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86
in their own tree, singing in
unison while the lead vocalist jumps from tree to tree, and meanwhile,
an unseen conductor keeps changing the tempo the piece is played at.
Thankfully, there are no key changes, however, occasionally new trees
sprout up at random and live ones fall over.
Signed-off-by: Zac
There's enough of these floating around randomly to justify using a
structure for keeping them in one place.
Signed-off-by: Zachary Amsden
---
arch/x86/kvm/x86.c | 110 ++--
1 files changed, 64 insertions(+), 46 deletions(-)
diff --git a
Signed-off-by: Zachary Amsden
---
arch/x86/include/asm/kvm_host.h |1 +
arch/x86/kvm/kvm_timer.h| 19
arch/x86/kvm/svm.c | 45 +--
arch/x86/kvm/x86.c |2 +-
4 files changed, 36 insertions(+), 31
Signed-off-by: Zachary Amsden
---
arch/x86/include/asm/kvm_host.h |4
arch/x86/kvm/svm.c |1 +
arch/x86/kvm/x86.c |3 +++
include/linux/kvm_host.h| 12
virt/kvm/kvm_main.c | 18 --
5 files changed, 36
both VMX and SVM and also for allowing
non-real time based TSCs.
Signed-off-by: Zachary Amsden
---
arch/x86/kvm/vmx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index b923f2a..75aa1d5 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch
301 - 400 of 1203 matches
Mail list logo
