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
---
arch/x86/kvm/mmu.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/x86
On Wed, Dec 30, 2015 at 3:36 AM, Paolo Bonzini 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
--
To unsubs
On Mon, Dec 28, 2015 at 6:25 PM, Paolo Bonzini 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):
>>
>> 4055 /*
>> 4
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 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 handler.
I like the id
On Wed, Dec 9, 2015 at 7:02 AM, Paolo Bonzini 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 the
>> CPU at the time of the exce
, so that the compiler always
inlines them.
Signed-off-by: David Matlack
---
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 9747ccd..9ffb5db 100644
--- a
On Wed, Oct 14, 2015 at 6:33 PM, Wu, Feng wrote:
>
>> -Original Message-
>> From: David Matlack [mailto:dmatl...@google.com]
>> Sent: Thursday, October 15, 2015 7:41 AM
>> To: Wu, Feng
>> Cc: Paolo Bonzini ; alex.william...@redhat.com; Joerg
>>
ch 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
Reviewed-by: David Matlack
>
> diff
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 the per-CPU list
I
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 howeve
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: Haozhong Zhang
>> ---
>
On Wed, Sep 23, 2015 at 5:55 PM, yangoliver 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
>> wrote:
>> > Hi Guys,
>&
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 KVM support TSC trapping to
gt; attempted polling compared to the successful polls.
Reviewed-by: David Matlack
>
> Cc: Christian Borntraeger Cc: David Matlack
> Signed-off-by: Paolo Bonzini
> ---
> arch/arm/include/asm/kvm_host.h | 1 +
> arch/arm64/include/asm/kvm_host.h | 1 +
> arch/mi
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) {
> ++vcpu->stat.halt_successful_poll;
> -
On Wed, Sep 2, 2015 at 12:12 PM, Paolo Bonzini wrote:
>
>
> On 02/09/2015 20:09, David Matlack wrote:
>> On Wed, Sep 2, 2015 at 12:29 AM, Wanpeng Li wrote:
>>> There is a downside of always-poll since poll is still happened for idle
>>> vCPUs which can was
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 max poll time 500us
> * h
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| 8 ++--
> 2 files changed, 36 inser
nd 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
> Signed-off-by: Wanpeng Li
> ---
> virt/kvm/kvm_main.c | 61
> +
On Tue, Sep 1, 2015 at 5:29 PM, Wanpeng Li wrote:
> On 9/2/15 7:24 AM, David Matlack wrote:
>>
>> On Tue, Sep 1, 2015 at 3:58 PM, Wanpeng Li wrote:
>>>
>>> Why this can happen?
>>
>> Ah, probably because I'm missing 9c8fd1ba220 (KVM: x86: optimi
On Tue, Sep 1, 2015 at 3:58 PM, Wanpeng Li wrote:
> On 9/2/15 6:34 AM, David Matlack wrote:
>>
>> On Tue, Sep 1, 2015 at 3:30 PM, Wanpeng Li wrote:
>>>
>>> On 9/2/15 5:45 AM, David Matlack wrote:
>>>>
>>>> On Thu, Aug 27, 2015
On Tue, Sep 1, 2015 at 3:30 PM, Wanpeng Li wrote:
> On 9/2/15 5:45 AM, David Matlack wrote:
>>
>> 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
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
> * drop the macros and hard
r higher frequency ticks.
Signed-off-by: David Matlack
---
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/include/trace/events/kvm
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 insertions(+), 2 deletions(-)
diff --git a/include/linu
should 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
On Thu, Aug 27, 2015 at 2:59 AM, Wanpeng Li 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
>> wrote:
>>>
>>> There is a downside of hal
Thanks for writing v2, Wanpeng.
On Mon, Aug 24, 2015 at 11:35 PM, Wanpeng Li 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 you done with these
On Mon, Aug 24, 2015 at 5:53 AM, Wanpeng Li 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 VCPU is detected.
>
>
On Mon, Aug 24, 2015 at 5:53 AM, Wanpeng Li 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.
>
> Signed-off-by: Wanpeng Li
(adding back the kvm mailing list)
On Tue, Jul 14, 2015 at 1:12 AM, "C. Bröcker"
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
>>> wrote:
>
On Thu, Jun 18, 2015 at 1:25 AM, Hansa 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 management in
On Sat, May 30, 2015 at 3:59 AM, Xiao Guangrong
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
> ---
> arch/x86/kvm/mtrr.c | 183
> ++
On Sat, May 30, 2015 at 3:59 AM, Xiao Guangrong
wrote:
> It gets the range for the specified variable MTRR
>
> Signed-off-by: Xiao Guangrong
> ---
> arch/x86/kvm/mtrr.c | 19 +--
> 1 file changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/arch/x86/kvm/mtrr.c b/arch/x86/kv
On Sat, May 30, 2015 at 3:59 AM, Xiao Guangrong
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
> ---
> arch/x86/include/asm/kvm_host.h | 12 ++
i
> ---
Reviewed-by: David Matlack
> 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
> ---
> ---
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
Reviewed-by: David Matlack
> arch/arm/include/asm/kvm_host.h
ect is also visible on Marcelo's recently-introduced latency
> test for the TSC deadline timer. Though of course a non-RT kernel has
> awful latency bounds, the latency of the timer is around 8000-1 clock
> cycles compared to 2-12 without setting halt_poll. For the TSC
> de
On Mon, Dec 22, 2014 at 4:39 PM, Andy Lutomirski 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 any vcpu other
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
> >
> > Thi
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
---
ar
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 g
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 cycl
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 app
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 Tue, Sep 2, 2014 at 9:50 AM, Paolo Bonzini 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
&
On Tue, Sep 2, 2014 at 9:49 AM, Paolo Bonzini 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 &l
On Tue, Sep 2, 2014 at 8:42 AM, Paolo Bonzini 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):
>> k
On Fri, Aug 29, 2014 at 3:31 AM, Paolo Bonzini wrote:
> From: David Matlack
>
> 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 a vcpu that is h
On Fri, Aug 29, 2014 at 12:58 AM, Paolo Bonzini 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?
>>
On Mon, Aug 18, 2014 at 3:46 PM, 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 in
> struct kvm_vcpu_arch (mmio_gfn). On Intel EPT-enabled hosts,
On Tue, Aug 19, 2014 at 5:29 PM, Xiao Guangrong
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 confused. :)
>>
>>> N
On Mon, Aug 18, 2014 at 10:19 PM, Xiao Guangrong
wrote:
> On 08/19/2014 01:00 PM, David Matlack wrote:
>> On Mon, Aug 18, 2014 at 9:41 PM, Xiao Guangrong
>> wrote:
>>> On 08/19/2014 12:31 PM, David Matlack wrote:
>>>> The single line patch I suggested w
On Mon, Aug 18, 2014 at 9:41 PM, Xiao Guangrong
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.
On Mon, Aug 18, 2014 at 8:50 PM, Xiao Guangrong
wrote:
> On 08/19/2014 05:15 AM, David Matlack wrote:
>> On Mon, Aug 18, 2014 at 12:56 PM, Xiao Guangrong
>> wrote:
>>> @@ -287,9 +293,15 @@ static bool set_mmio_spte(struct kvm *kvm, u64 *sptep,
>>> gfn_t gfn,
>
code to make it simpler for stable-tree fix. ]
Cc: sta...@vger.kernel.org
Signed-off-by: David Matlack
Signed-off-by: Xiao Guangrong
---
arch/x86/include/asm/kvm_host.h | 1 +
arch/x86/kvm/mmu.c | 4 ++--
arch/x86/kvm/mmu.h | 2 ++
arch/x86/kvm/x86.h | 21
after synchronizing kvm->srcu
readers, we guarantee the generation cached in (5) will very soon
become invalid.
Cc: sta...@vger.kernel.org
Cc: Xiao Guangrong
Signed-off-by: David Matlack
---
virt/kvm/kvm_main.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
d
On Mon, Aug 18, 2014 at 2:24 PM, Paolo Bonzini 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
On Mon, Aug 18, 2014 at 12:56 PM, Xiao Guangrong
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);
> unsigned int kvm_
On Mon, Aug 18, 2014 at 9:35 AM, Xiao Guangrong
wrote:
>
> Hi Paolo,
>
> Thank you to review the patch!
>
> On Aug 18, 2014, at 9:57 PM, Paolo Bonzini wrote:
>
>> Il 14/08/2014 09:01, Xiao Guangrong ha scritto:
>>> -update_memslots(slots, new, kvm->memslots->generation);
>>> +/* ensure ge
On Thu, Aug 14, 2014 at 12:01 AM, Xiao Guangrong
wrote:
> From: David Matlack
>
> 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 (mm
On Mon, Aug 11, 2014 at 10:02 PM, Xiao Guangrong
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 = old_memslots->generation;
here.
On the
On Thu, Aug 7, 2014 at 6:36 PM, Xiao Guangrong
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
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 Tue, Aug 5, 2014 at 8:26 PM, Xiao Guangrong
wrote:
> On 08/06/2014 06:39 AM, David Matlack wrote:
>> On Mon, Aug 4, 2014 at 8:36 PM, Xiao Guangrong
>> wrote:
>>> The memory barrier can't help us, consider this scenario:
>>>
>>> CPU 0
On Mon, Aug 4, 2014 at 8:36 PM, Xiao Guangrong
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.
>>
On Mon, Aug 4, 2014 at 5:31 PM, Wanpeng Li 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 mem
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
On Mon, Aug 4, 2014 at 5:44 AM, Paolo Bonzini 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 like this appro
mmio cache since
even direct_map (e.g. tdp) hosts use it.
Signed-off-by: David Matlack
---
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 +-
5 files changed
71 matches
Mail list logo
