the mmio cache since
even direct_map (e.g. tdp) hosts use it.
Signed-off-by: David Matlack dmatl...@google.com
---
arch/x86/kvm/mmu.c | 3 ++-
arch/x86/kvm/x86.c | 5 +
arch/x86/kvm/x86.h | 8 +---
include/linux/kvm_host.h | 2 ++
virt/kvm/kvm_main.c | 10
On Mon, Aug 4, 2014 at 5:44 AM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 02/08/2014 06:15, Xiao Guangrong ha scritto:
I prefer to also caching the spte’s generation number, then check the number
in quickly_check_mmio_pf().
I agree, thanks Xiao for the review and David for the report!
I
it to
validate mmio cache lookups.
- Extend vcpu_clear_mmio_info to clear mmio_gfn in addition to
mmio_gva, since both can be used to fast path mmio faults.
- In mmu_sync_roots, unconditionally clear the mmio cache since
even direct_map (e.g. tdp) hosts use it.
Signed-off-by: David Matlack dmatl
On Mon, Aug 4, 2014 at 5:31 PM, Wanpeng Li wanpeng...@linux.intel.com wrote:
Hi David,
On Mon, Aug 04, 2014 at 02:10:20PM -0700, David Matlack wrote:
The following events can lead to an incorrect KVM_EXIT_MMIO bubbling
up to userspace:
(1) Guest accesses gpa X without a memory slot. The gfn
On Mon, Aug 4, 2014 at 8:36 PM, Xiao Guangrong
xiaoguangr...@linux.vnet.ibm.com wrote:
On 08/05/2014 05:10 AM, David Matlack wrote:
This patch fixes the issue by doing the following:
- Tag the mmio cache with the memslot generation and use it to
validate mmio cache lookups.
- Extend
On Tue, Aug 5, 2014 at 8:26 PM, Xiao Guangrong
xiaoguangr...@linux.vnet.ibm.com wrote:
On 08/06/2014 06:39 AM, David Matlack wrote:
On Mon, Aug 4, 2014 at 8:36 PM, Xiao Guangrong
xiaoguangr...@linux.vnet.ibm.com wrote:
The memory barrier can't help us, consider this scenario:
CPU 0
of this but we fast
path mmio faults through quickly_check_mmio_pf(), which only checks
the per-vcpu mmio cache. Since we hit the cache, KVM passes a
KVM_EXIT_MMIO up to userspace.
This patch fixes the issue by using the memslot generation number
to validate the mmio cache.
Signed-off-by: David Matlack
On Thu, Aug 7, 2014 at 6:36 PM, Xiao Guangrong
xiaoguangr...@linux.vnet.ibm.com wrote:
On 08/08/2014 02:32 AM, David Matlack wrote:
The following events can lead to an incorrect KVM_EXIT_MMIO bubbling
up to userspace:
(1) Guest accesses gpa X without a memory slot. The gfn is cached
On Mon, Aug 11, 2014 at 10:02 PM, Xiao Guangrong
xiaoguangr...@linux.vnet.ibm.com wrote:
@@ -722,9 +719,10 @@ static struct kvm_memslots *install_new_memslots(struct
kvm *kvm,
{
struct kvm_memslots *old_memslots = kvm-memslots;
I think you want
slots-generation =
On Thu, Aug 14, 2014 at 12:01 AM, Xiao Guangrong
xiaoguangr...@linux.vnet.ibm.com wrote:
From: David Matlack dmatl...@google.com
The following events can lead to an incorrect KVM_EXIT_MMIO bubbling
up to userspace:
(1) Guest accesses gpa X without a memory slot. The gfn is cached in
struct
On Mon, Aug 18, 2014 at 9:35 AM, Xiao Guangrong
xiaoguangrong.e...@gmail.com wrote:
Hi Paolo,
Thank you to review the patch!
On Aug 18, 2014, at 9:57 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 14/08/2014 09:01, Xiao Guangrong ha scritto:
-update_memslots(slots, new,
On Mon, Aug 18, 2014 at 12:56 PM, Xiao Guangrong
xiaoguangrong.e...@gmail.com wrote:
@@ -287,9 +293,15 @@ static bool set_mmio_spte(struct kvm *kvm, u64 *sptep,
gfn_t gfn,
static bool check_mmio_spte(struct kvm *kvm, u64 spte)
{
+ struct kvm_memslots *slots = kvm_memslots(kvm);
On Mon, Aug 18, 2014 at 2:24 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 18/08/2014 23:15, David Matlack ha scritto:
I just realized how simple Paolo's idea is. I think it can be a one line
patch (without comments):
[...]
update_memslots(slots, new, kvm-memslots-generation
) will very soon
become invalid.
Cc: sta...@vger.kernel.org
Cc: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
Signed-off-by: David Matlack dmatl...@google.com
---
virt/kvm/kvm_main.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm
the code to make it simpler for stable-tree fix. ]
Cc: sta...@vger.kernel.org
Signed-off-by: David Matlack dmatl...@google.com
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/include/asm/kvm_host.h | 1 +
arch/x86/kvm/mmu.c | 4 ++--
arch/x86/kvm/mmu.h
On Mon, Aug 18, 2014 at 8:50 PM, Xiao Guangrong
xiaoguangr...@linux.vnet.ibm.com wrote:
On 08/19/2014 05:15 AM, David Matlack wrote:
On Mon, Aug 18, 2014 at 12:56 PM, Xiao Guangrong
xiaoguangrong.e...@gmail.com wrote:
@@ -287,9 +293,15 @@ static bool set_mmio_spte(struct kvm *kvm, u64 *sptep
On Mon, Aug 18, 2014 at 9:41 PM, Xiao Guangrong
xiaoguangr...@linux.vnet.ibm.com wrote:
On 08/19/2014 12:31 PM, David Matlack wrote:
But it looks like you basically said the same thing earlier, so I think
we're on the same page.
Yes, that is what i try to explain in previous mails. :(
I'm
On Mon, Aug 18, 2014 at 10:19 PM, Xiao Guangrong
xiaoguangr...@linux.vnet.ibm.com wrote:
On 08/19/2014 01:00 PM, David Matlack wrote:
On Mon, Aug 18, 2014 at 9:41 PM, Xiao Guangrong
xiaoguangr...@linux.vnet.ibm.com wrote:
On 08/19/2014 12:31 PM, David Matlack wrote:
The single line patch I
On Tue, Aug 19, 2014 at 5:29 PM, Xiao Guangrong
xiaoguangr...@linux.vnet.ibm.com wrote:
On 08/19/2014 05:03 PM, Paolo Bonzini wrote:
Il 19/08/2014 10:50, Xiao Guangrong ha scritto:
Okay, what confused me it that it seems that the single line patch
is ok to you. :)
No, it was late and I was
On Mon, Aug 18, 2014 at 3:46 PM, David Matlack dmatl...@google.com wrote:
The following events can lead to an incorrect KVM_EXIT_MMIO bubbling
up to userspace:
(1) Guest accesses gpa X without a memory slot. The gfn is cached in
struct kvm_vcpu_arch (mmio_gfn). On Intel EPT-enabled hosts, KVM
On Fri, Aug 29, 2014 at 12:58 AM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 28/08/2014 23:10, David Matlack ha scritto:
Paolo,
It seems like this patch ([PATCH 2/2] kvm: x86: fix stale mmio cache)
is ready to go. Is there anything blocking it from being merged?
(It should be fine to merge
On Fri, Aug 29, 2014 at 3:31 AM, Paolo Bonzini pbonz...@redhat.com wrote:
From: David Matlack dmatl...@google.com
vcpu exits and memslot mutations can run concurrently as long as the
vcpu does not aquire the slots mutex. Thus it is theoretically possible
for memslots to change underneath
On Tue, Sep 2, 2014 at 8:42 AM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 29/08/2014 12:31, Paolo Bonzini ha scritto:
David and Xiao, here's my take on the MMIO generation patches. Now
with documentation, too. :) Please review!
David Matlack (2):
kvm: fix potentially corrupt mmio cache
On Tue, Sep 2, 2014 at 9:49 AM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 02/09/2014 18:44, David Matlack ha scritto:
-#define MMIO_GEN_SHIFT 19
-#define MMIO_GEN_LOW_SHIFT 9
-#define MMIO_GEN_LOW_MASK ((1 MMIO_GEN_LOW_SHIFT) - 1)
+#define
On Tue, Sep 2, 2014 at 9:50 AM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 02/09/2014 18:47, David Matlack ha scritto:
Ping?
Sorry for the delay. I think the patches look good. And patch 3/3 still
fixes the bug I was originally seeing, so I'm happy :). I just had one
small comment (see my
vcpu ioctls can hang the calling thread if issued while a vcpu is
running. If we know ioctl is going to be rejected as invalid anyway,
we can fail before trying to take the vcpu mutex.
This patch does not change functionality, it just makes invalid ioctls
fail faster.
Signed-off-by: David
On 09/22, Paolo Bonzini wrote:
Il 22/09/2014 15:45, Christian Borntraeger ha scritto:
We now have an extra condition check for every valid ioctl, to make an
error case go faster.
I know, the extra check is just a 1 or 2 cycles if branch prediction is
right, but still.
I applied the
On 09/22, Christian Borntraeger wrote:
On 09/22/2014 04:31 PM, Paolo Bonzini wrote:
Il 22/09/2014 15:45, Christian Borntraeger ha scritto:
We now have an extra condition check for every valid ioctl, to make an
error case go faster.
I know, the extra check is just a 1 or 2 cycles if
On 09/22, Marcelo Tosatti wrote:
On Fri, Sep 19, 2014 at 04:03:25PM -0700, David Matlack wrote:
vcpu ioctls can hang the calling thread if issued while a vcpu is
running.
There is a mutex per-vcpu, so thats expected, OK...
If we know ioctl is going to be rejected as invalid anyway
The new trace event records:
* the id of vcpu being updated
* the pvclock_vcpu_time_info struct being written to guest memory
This is useful for debugging pvclock bugs, such as the bug fixed by
[PATCH] kvm: x86: Fix kvm clock versioning..
Signed-off-by: David Matlack dmatl...@google.com
On 11/10 11:18 PM, Marcelo Tosatti wrote:
On Wed, Nov 05, 2014 at 11:46:42AM -0800, David Matlack wrote:
The new trace event records:
* the id of vcpu being updated
* the pvclock_vcpu_time_info struct being written to guest memory
This is useful for debugging pvclock bugs
On Mon, Dec 22, 2014 at 4:39 PM, Andy Lutomirski l...@amacapital.net wrote:
The pvclock vdso code was too abstracted to understand easily and
excessively paranoid. Simplify it for a huge speedup.
This opens the door for additional simplifications, as the vdso no
longer accesses the pvti for
...@redhat.com
---
Looks good, thanks for making those changes. I ran this patch on my
benchmarks (loopback TCP_RR and memcache) using halt_poll_ns=7 and
saw performance go from 40% to 60-65% of bare-metal.
Tested-by: David Matlack dmatl...@google.com
Reviewed-by: David Matlack dmatl
...@redhat.com
---
Reviewed-by: David Matlack dmatl...@google.com
arch/x86/kvm/x86.c | 67
+-
1 file changed, 36 insertions(+), 31 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index bd7a70be41b3..0b8dd13676ef 100644
of the timer is around 8000-1 clock
cycles compared to 2-12 without setting halt_poll. For the TSC
deadline timer, thus, the effect is both a smaller average latency and
a smaller variance.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
Reviewed-by: David Matlack dmatl
On Sat, May 30, 2015 at 3:59 AM, Xiao Guangrong
guangrong.x...@linux.intel.com wrote:
It walks all MTRRs and gets all the memory cache type setting for the
specified range also it checks if the range is fully covered by MTRRs
Signed-off-by: Xiao Guangrong guangrong.x...@linux.intel.com
---
On Sat, May 30, 2015 at 3:59 AM, Xiao Guangrong
guangrong.x...@linux.intel.com wrote:
Use union definition to avoid the decode/code workload and drop all the
hard code
Thank you for doing this cleanup. The new code is much clearer!
Signed-off-by: Xiao Guangrong guangrong.x...@linux.intel.com
On Sat, May 30, 2015 at 3:59 AM, Xiao Guangrong
guangrong.x...@linux.intel.com wrote:
It gets the range for the specified variable MTRR
Signed-off-by: Xiao Guangrong guangrong.x...@linux.intel.com
---
arch/x86/kvm/mtrr.c | 19 +--
1 file changed, 13 insertions(+), 6
On Thu, Jun 18, 2015 at 1:25 AM, Hansa for...@logic-q.nl wrote:
Hi,
I have a LAMP server as guest in KVM. Whenever the server is idle for some
time it takes about 30 seconds to load a Wordpress site.
If the server is not idle the site shows up in max 5 seconds. I've already
turned of power
On Mon, Aug 24, 2015 at 5:53 AM, Wanpeng Li wanpeng...@hotmail.com wrote:
Change halt_poll_ns into per-VCPU variable, seeded from module parameter,
to allow greater flexibility.
You should also change kvm_vcpu_block to read halt_poll_ns from
the vcpu instead of the module parameter.
On Mon, Aug 24, 2015 at 5:53 AM, Wanpeng Li wanpeng...@hotmail.com wrote:
There are two new kernel parameters for changing the halt_poll_ns:
halt_poll_ns_grow and halt_poll_ns_shrink. halt_poll_ns_grow affects
halt_poll_ns when an interrupt arrives and halt_poll_ns_shrink
does it when idle
(adding back the kvm mailing list)
On Tue, Jul 14, 2015 at 1:12 AM, C. Bröcker
c.broc...@intercollect.com wrote:
On 14-7-2015 10:04, Hansa wrote:
On 13-7-2015 20:57, David Matlack wrote:
On Thu, Jun 18, 2015 at 10:26 AM, David Matlack dmatl...@google.com
wrote:
On Thu, Jun 18, 2015 at 1
Thanks for writing v2, Wanpeng.
On Mon, Aug 24, 2015 at 11:35 PM, Wanpeng Li wanpeng...@hotmail.com wrote:
There is a downside of halt_poll_ns since poll is still happen for idle
VCPU which can waste cpu usage. This patch adds the ability to adjust
halt_poll_ns dynamically.
What testing have
_SET_MSRS.
>
> Which can cause an overflow later (when subtracting from vcpu threads
> sched_info.run_delay).
>
> To avoid that, move steal time accumulation to vcpu entry time,
> before copying steal time data to guest.
>
> Signed-off-by: Marcelo Tosatti <mtosa...@redhat.co
Hi Feng.
On Fri, Sep 18, 2015 at 7:29 AM, Feng Wu wrote:
> This patch updates the Posted-Interrupts Descriptor when vCPU
> is blocked.
>
> pre-block:
> - Add the vCPU to the blocked per-CPU list
> - Set 'NV' to POSTED_INTR_WAKEUP_VECTOR
>
> post-block:
> - Remove the vCPU from
On Wed, Oct 14, 2015 at 6:33 PM, Wu, Feng <feng...@intel.com> wrote:
>
>> -Original Message-
>> From: David Matlack [mailto:dmatl...@google.com]
>> Sent: Thursday, October 15, 2015 7:41 AM
>> To: Wu, Feng <feng...@intel.com>
>> Cc: Paol
On Mon, Oct 5, 2015 at 12:53 PM, Radim Krčmář wrote:
> 2015-09-28 13:38+0800, Haozhong Zhang:
>> Both VMX and SVM propagate virtual_tsc_khz in the same way, so this
>> patch removes the call-back set_tsc_khz() and replaces it with a common
>> function.
>>
>> Signed-off-by:
Have you tried perf kvm stat? e.g.
perf kvm stat record -a sleep 10 # record all vmexits for 10 seconds
perf kvm stat report --event=vmexit
This gives per-exit counts and min/max/avg latencies.
Alternatively you can record the raw events kvm:kvm_exit and kvm:kvm_entry and
process the data
On Thu, Aug 27, 2015 at 2:59 AM, Wanpeng Li wanpeng...@hotmail.com wrote:
Hi David,
On 8/26/15 1:19 AM, David Matlack wrote:
Thanks for writing v2, Wanpeng.
On Mon, Aug 24, 2015 at 11:35 PM, Wanpeng Li wanpeng...@hotmail.com
wrote:
There is a downside of halt_poll_ns since poll is still
On Tue, Sep 1, 2015 at 5:29 PM, Wanpeng Li <wanpeng...@hotmail.com> wrote:
> On 9/2/15 7:24 AM, David Matlack wrote:
>>
>> On Tue, Sep 1, 2015 at 3:58 PM, Wanpeng Li <wanpeng...@hotmail.com> wrote:
>>>
>>> Why this can happen?
>>
>> Ah, pro
On Thu, Aug 27, 2015 at 2:47 AM, Wanpeng Li wrote:
> v3 -> v4:
> * bring back grow vcpu->halt_poll_ns when interrupt arrives and shrinks
>when idle VCPU is detected
>
> v2 -> v3:
> * grow/shrink vcpu->halt_poll_ns by *halt_poll_ns_grow or
> /halt_poll_ns_shrink
> *
On Tue, Sep 1, 2015 at 3:58 PM, Wanpeng Li <wanpeng...@hotmail.com> wrote:
> On 9/2/15 6:34 AM, David Matlack wrote:
>>
>> On Tue, Sep 1, 2015 at 3:30 PM, Wanpeng Li <wanpeng...@hotmail.com> wrote:
>>>
>>> On 9/2/15 5:45 AM, David Matlack wrote:
>&
ld however keep halt_poll_ns below 1 ms since that is the tick
frequency used by windows.
David Matlack (1):
kvm: adaptive halt-polling toggle
Wanpeng Li (1):
KVM: make halt_poll_ns per-VCPU
include/linux/kvm_host.h | 1 +
include/trace/events/kvm.h | 23 ++
virt/kvm/
On Tue, Sep 1, 2015 at 3:30 PM, Wanpeng Li <wanpeng...@hotmail.com> wrote:
> On 9/2/15 5:45 AM, David Matlack wrote:
>>
>> On Thu, Aug 27, 2015 at 2:47 AM, Wanpeng Li <wanpeng...@hotmail.com>
>> wrote:
>>>
>>> v3 -> v4:
>>> * bring
her frequency ticks.
Signed-off-by: David Matlack <dmatl...@google.com>
---
include/trace/events/kvm.h | 23 ++
virt/kvm/kvm_main.c| 110 ++---
2 files changed, 97 insertions(+), 36 deletions(-)
diff --git a/include/trace/events/kvm.h b/incl
From: Wanpeng Li
Change halt_poll_ns into per-VCPU variable, seeded from module parameter,
to allow greater flexibility.
Signed-off-by: Wanpeng Li
---
include/linux/kvm_host.h | 1 +
virt/kvm/kvm_main.c | 5 +++--
2 files changed, 4
On Thu, Sep 3, 2015 at 2:23 AM, Wanpeng Li wrote:
>
> How about something like:
>
> @@ -1941,10 +1976,14 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu)
> */
> if (kvm_vcpu_check_block(vcpu) < 0) {
>
On Wed, Sep 2, 2015 at 12:29 AM, Wanpeng Li wrote:
> v5 -> v6:
> * fix wait_ns and poll_ns
Thanks for bearing with me through all the reviews. I think it's on the
verge of being done :). There are just few small things to fix.
>
> v4 -> v5:
> * set base case 10us and
we save 3.4%~12.8% CPUs/second and get close
> to no-polling overhead levels by using the dynamic-poll. The savings
> should be even higher for higher frequency ticks.
>
> Suggested-by: David Matlack <dmatl...@google.com>
> Signed-off-by: Wanpeng Li <wanpeng...@hotmail.com&g
On Wed, Sep 2, 2015 at 12:42 AM, Wanpeng Li wrote:
> Tracepoint for dynamic halt_pool_ns, fired on every potential change.
>
> Signed-off-by: Wanpeng Li
> ---
> include/trace/events/kvm.h | 30 ++
> virt/kvm/kvm_main.c
On Wed, Sep 2, 2015 at 12:12 PM, Paolo Bonzini <pbonz...@redhat.com> wrote:
>
>
> On 02/09/2015 20:09, David Matlack wrote:
>> On Wed, Sep 2, 2015 at 12:29 AM, Wanpeng Li <wanpeng...@hotmail.com> wrote:
>>> There is a downside of always-poll since poll is sti
On Tue, Sep 15, 2015 at 12:04 AM, Oliver Yang wrote:
> Hi Guys,
>
> I found below patch for KVM TSC trapping / migration support,
>
> https://lkml.org/lkml/2011/1/6/90
>
> It seemed the patch were not merged in Linux mainline.
>
> So I have 3 questions here,
>
> 1. Can
show as an abnormally high number of
> attempted polling compared to the successful polls.
Reviewed-by: David Matlack <dmatl...@google.com>
>
> Cc: Christian Borntraeger <borntrae...@de.ibm.com<
> Cc: David Matlack <dmatl...@google.com>
> Signed-off-by: Paolo Bonzini <
On Wed, Sep 23, 2015 at 5:55 PM, yangoliver <yang_oli...@hotmail.com> wrote:
>
> David,
>
> Sorry for late reply. See my inline comments.
>
>
> On Tue, 15 Sep 2015, David Matlack wrote:
>
>> On Tue, Sep 15, 2015 at 12:04 AM, Oliver Yang <yang_oli.
, so that the compiler always
inlines them.
Signed-off-by: David Matlack <dmatl...@google.com>
---
lib/libcflat.h | 4
lib/x86/processor.h | 2 +-
x86/vmx.c | 4 ++--
3 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/lib/libcflat.h b/lib/libcflat.h
index 9
On Tue, Dec 15, 2015 at 2:25 AM, Paolo Bonzini wrote:
> Test functions know whether an exception was generated simply by checking
> the last value returned by set_exception_jmpbuf. The exception number is
> passed to set_exception_jmpbuf so that it can set up the exception
On Wed, Dec 9, 2015 at 7:02 AM, Paolo Bonzini <pbonz...@redhat.com> wrote:
> On 07/12/2015 21:36, David Matlack wrote:
>> set_exception_return forces exceptions handlers to return to a specific
>> address instead of returning to the instruction address pushed by t
On Mon, Dec 28, 2015 at 6:25 PM, Paolo Bonzini <pbonz...@redhat.com> wrote:
>
>
> On 28/12/2015 23:23, David Matlack wrote:
>> I'm wondering if this comment in mmu.c:init_kvm_nested_mmu is correct (at
>> least in the context of Nested EPT):
>>
>>
The comment had the meaning of mmu.gva_to_gpa and nested_mmu.gva_to_gpa
swapped. Fix that, and also add some details describing how each translation
works.
Signed-off-by: David Matlack <dmatl...@google.com>
---
arch/x86/kvm/mmu.c | 10 ++
1 file changed, 6 insertions(+), 4 del
I'm wondering if this comment in mmu.c:init_kvm_nested_mmu is correct (at
least in the context of Nested EPT):
4055 /*
4056 * Note that arch.mmu.gva_to_gpa translates l2_gva to l1_gpa. The
4057 * translation of l2_gpa to l1_gpa addresses is done using the
4058 *
On Wed, Dec 30, 2015 at 3:36 AM, Paolo Bonzini <pbonz...@redhat.com> wrote:
>
>
> On 29/12/2015 17:37, David Matlack wrote:
>>> > Yes, it's correct.
>
> s/it's/you're/ :)
Ah ok. Thanks for your help!
I will send a patch to fix the comment then.
>
> Paolo
71 matches
Mail list logo