On Mon, Jan 04, 2016 at 02:33:12PM -0800, Andy Lutomirski wrote:
> On Mon, Jan 4, 2016 at 12:26 PM, Marcelo Tosatti wrote:
> > On Sun, Dec 20, 2015 at 03:05:41AM -0800, Andy Lutomirski wrote:
> >> From: Andy Lutomirski
> >>
> >> The pvclock vdso code was too
On Sun, Dec 20, 2015 at 03:05:41AM -0800, Andy Lutomirski wrote:
> From: Andy Lutomirski
>
> 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
On Mon, Dec 21, 2015 at 02:49:25PM -0800, Andy Lutomirski wrote:
> On Fri, Dec 18, 2015 at 1:49 PM, Marcelo Tosatti wrote:
> > On Fri, Dec 18, 2015 at 12:25:11PM -0800, Andy Lutomirski wrote:
> >> [cc: John Stultz -- maybe you have ideas on how this should best
> >> i
On Fri, Dec 18, 2015 at 12:25:11PM -0800, Andy Lutomirski wrote:
> [cc: John Stultz -- maybe you have ideas on how this should best
> integrate with the core code]
>
> On Fri, Dec 18, 2015 at 11:45 AM, Marcelo Tosatti wrote:
> > On Fri, Dec 18, 2015 at 11:27:13AM -0800, And
On Fri, Dec 18, 2015 at 11:27:13AM -0800, Andy Lutomirski wrote:
> On Fri, Dec 18, 2015 at 3:47 AM, Marcelo Tosatti wrote:
> > On Thu, Dec 17, 2015 at 05:12:59PM -0800, Andy Lutomirski wrote:
> >> On Thu, Dec 17, 2015 at 11:08 AM, Marcelo Tosatti
> >> wrote:
> >
On Thu, Dec 17, 2015 at 05:12:59PM -0800, Andy Lutomirski wrote:
> On Thu, Dec 17, 2015 at 11:08 AM, Marcelo Tosatti wrote:
> > On Thu, Dec 17, 2015 at 08:33:17AM -0800, Andy Lutomirski wrote:
> >> On Wed, Dec 16, 2015 at 1:57 PM, Marcelo Tosatti
> >> wrote:
> >
On Thu, Dec 17, 2015 at 08:33:17AM -0800, Andy Lutomirski wrote:
> On Wed, Dec 16, 2015 at 1:57 PM, Marcelo Tosatti wrote:
> > On Wed, Dec 16, 2015 at 10:17:16AM -0800, Andy Lutomirski wrote:
> >> On Wed, Dec 16, 2015 at 9:48 AM, Andy Lutomirski
> >> wrote:
> >
On Wed, Dec 16, 2015 at 10:17:16AM -0800, Andy Lutomirski wrote:
> On Wed, Dec 16, 2015 at 9:48 AM, Andy Lutomirski wrote:
> > On Tue, Dec 15, 2015 at 12:42 AM, Paolo Bonzini wrote:
> >>
> >>
> >> On 14/12/2015 23:31, Andy Lutomirski wrote:
> >>> > RAW TSC NTP corrected TS
GOn Mon, Dec 14, 2015 at 02:31:10PM -0800, Andy Lutomirski wrote:
> On Mon, Dec 14, 2015 at 2:00 PM, Marcelo Tosatti wrote:
> > On Mon, Dec 14, 2015 at 02:44:15PM +0100, Paolo Bonzini wrote:
> >>
> >>
> >> On 11/12/2015 22:57, Andy Lutomirski wrote:
&
On Mon, Dec 14, 2015 at 02:44:15PM +0100, Paolo Bonzini wrote:
>
>
> On 11/12/2015 22:57, Andy Lutomirski wrote:
> > I'm still not seeing the issue.
> >
> > The formula is:
> >
> > (((rdtsc - pvti->tsc_timestamp) * pvti->tsc_to_system_mul) >>
> > pvti->tsc_shift) + pvti->system_time
> >
> > Ob
On Mon, Dec 14, 2015 at 10:07:21AM -0800, Andy Lutomirski wrote:
> On Fri, Dec 11, 2015 at 3:48 PM, Marcelo Tosatti wrote:
> > On Fri, Dec 11, 2015 at 01:57:23PM -0800, Andy Lutomirski wrote:
> >> On Thu, Dec 10, 2015 at 1:32 PM, Marcelo Tosatti
> >> wrote:
> >
On Fri, Dec 11, 2015 at 01:57:23PM -0800, Andy Lutomirski wrote:
> On Thu, Dec 10, 2015 at 1:32 PM, Marcelo Tosatti wrote:
> > On Wed, Dec 09, 2015 at 01:10:59PM -0800, Andy Lutomirski wrote:
> >> I'm trying to clean up kvmclock and I can't get it to work at all. My
&
6-2571 [002] 102370.447688: kvm_update_master_clock:
> masterclock 0 hostclock tsc offsetmatched 1
>
> I suspect, but I haven't verified, that this is fallout from:
>
> commit 16a9602158861687c78b6de6dc6a79e6e8a9136f
> Author: Marcelo Tosatti
> Date: Wed May 14 12:43:24 2
On Wed, Dec 09, 2015 at 02:27:36PM -0800, Andy Lutomirski wrote:
> On Wed, Dec 9, 2015 at 2:12 PM, Paolo Bonzini wrote:
> >
> >
> > On 09/12/2015 22:49, Andy Lutomirski wrote:
> >> On Wed, Dec 9, 2015 at 1:16 PM, Paolo Bonzini wrote:
> >>>
> >>>
> >>> On 09/12/2015 22:10, Andy Lutomirski wrote:
>
6-2571 [002] 102370.447688: kvm_update_master_clock:
> masterclock 0 hostclock tsc offsetmatched 1
>
> I suspect, but I haven't verified, that this is fallout from:
>
> commit 16a9602158861687c78b6de6dc6a79e6e8a9136f
> Author: Marcelo Tosatti
> Date: Wed May 14 12:43:24 2
On Fri, Nov 13, 2015 at 07:47:28PM -0200, Marcelo Tosatti wrote:
> On Thu, Nov 12, 2015 at 08:52:45PM +0900, Takuya Yoshikawa wrote:
> > kvm_mmu_mark_parents_unsync() alone uses pte_list_walk(), witch does
> > nearly the same as the for_each_rmap_spte macro. The only differe
On Thu, Nov 12, 2015 at 08:53:43PM +0900, Takuya Yoshikawa wrote:
> At some call sites of rmap_get_first() and rmap_get_next(), BUG_ON is
> placed right after the call to detect unrelated sptes which must not be
> found in the reverse-mapping list.
>
> Move this check in rmap_get_first/next() so t
On Thu, Nov 12, 2015 at 08:52:45PM +0900, Takuya Yoshikawa wrote:
> kvm_mmu_mark_parents_unsync() alone uses pte_list_walk(), witch does
> nearly the same as the for_each_rmap_spte macro. The only difference
> is that is_shadow_present_pte() checks cannot be placed there because
> kvm_mmu_mark_par
On Wed, Oct 28, 2015 at 06:05:00PM +0100, Paolo Bonzini wrote:
>
>
> On 28/10/2015 17:00, Alex Williamson wrote:
> > > Alex, would it make sense to use the IRQ bypass infrastructure always,
> > > not just for VT-d, to do the MSI injection directly from the VFIO
> > > interrupt handler and bypass
On Thu, Oct 22, 2015 at 04:45:21PM -0200, Eduardo Habkost wrote:
> On Tue, Oct 20, 2015 at 03:22:51PM +0800, Haozhong Zhang wrote:
> > This patchset enables QEMU to save/restore vcpu's TSC rate during the
> > migration. When cooperating with KVM which supports TSC scaling, guest
> > programs can ob
To avoid that, move steal time accumulation to vcpu entry time,
before copying steal time data to guest.
Signed-off-by: Marcelo Tosatti
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 8f0f6ec..0e0332e 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2030,6 +2030,8 @@ sta
On Tue, Sep 22, 2015 at 09:52:49PM +0200, Paolo Bonzini wrote:
>
>
> On 22/09/2015 21:01, Marcelo Tosatti wrote:
> > On Fri, Sep 18, 2015 at 05:54:30PM +0200, Radim Krčmář wrote:
> >> Shifting pvclock_vcpu_time_info.system_time on write to KVM system time
> >>
On Tue, Sep 22, 2015 at 06:33:46PM +0200, Radim Krčmář wrote:
> PVCLOCK_COUNTS_FROM_ZERO broke ABI and (at least) three things with it.
> All problems stem from repeated writes to MSR_KVM_SYSTEM_TIME(_NEW).
> The reverted patch treated the MSR write as a one-shot initializer:
> any write from VCPU
On Fri, Sep 18, 2015 at 05:54:29PM +0200, Radim Krčmář wrote:
> Newer KVM won't be exposing PVCLOCK_COUNTS_FROM_ZERO anymore.
> The purpose of that flags was to start counting system time from 0 when
> the KVM clock has been initialized.
> We can achieve the same by selecting one read as the initia
On Fri, Sep 18, 2015 at 05:54:30PM +0200, Radim Krčmář wrote:
> Shifting pvclock_vcpu_time_info.system_time on write to KVM system time
> MSR is a change of ABI. Probably only 2.6.16 based SLES 10 breaks due
> to its custom enhancements to kvmclock, but KVM never declared the MSR
> only for one-sh
> So either:
>
> Proceed with guest solution:
> -> Make sure the overflow can't happen (and write down why not in the
> code). Don't assume a small delta between kvmclock values of vcpus.
> -> Handle stable -> non-stable kvmclock transition.
> -> kvmclock counts from zero should not depend on stab
On Tue, Sep 22, 2015 at 12:00:39AM +0200, Radim Krčmář wrote:
> 2015-09-21 17:53-0300, Marcelo Tosatti:
> > On Mon, Sep 21, 2015 at 10:00:27PM +0200, Radim Krčmář wrote:
> >> 2015-09-21 12:52-0300, Marcelo Tosatti:
> >> > On Mon, Sep 21, 2015 at 05:12:10PM +0200, Ra
On Mon, Sep 21, 2015 at 10:00:27PM +0200, Radim Krčmář wrote:
> 2015-09-21 12:52-0300, Marcelo Tosatti:
> > On Mon, Sep 21, 2015 at 05:12:10PM +0200, Radim Krčmář wrote:
> >> 2015-09-20 19:57-0300, Marcelo Tosatti:
> >>> Is it counting from zero that breaks SL
On Mon, Sep 21, 2015 at 05:12:10PM +0200, Radim Krčmář wrote:
> 2015-09-20 19:57-0300, Marcelo Tosatti:
> > On Fri, Sep 18, 2015 at 05:54:28PM +0200, Radim Krčmář wrote:
> >> This patch series will be disabling PVCLOCK_COUNTS_FROM_ZERO flag and is
> >> RFC because I have
On Fri, Sep 18, 2015 at 05:54:28PM +0200, Radim Krčmář wrote:
> This patch series will be disabling PVCLOCK_COUNTS_FROM_ZERO flag and is
> RFC because I haven't explored many potential problems or tested it.
The justification to disable PVCLOCK_COUNTS_FROM_ZERO is because you
haven't explored pote
Linus,
Please pull from
git://git.kernel.org/pub/scm/virt/kvm/kvm.git master
To receive the following KVM bug fix, which restores
APIC migration functionality.
Radim Krčmář (1):
KVM: x86: fix lapic.timer_mode on restore
arch/x86/kvm/lapic.c | 26 --
1 file c
On Tue, Apr 14, 2015 at 07:37:44AM +, Wu, Feng wrote:
>
>
> > -Original Message-
> > From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
> > Sent: Tuesday, March 31, 2015 7:56 AM
> > To: Wu, Feng
> > Cc: h...@zytor.com; t...@linutronix.de; mi..
Initialize kvmclock base, on kvmclock system MSR write time,
so that the guest sees kvmclock counting from zero.
This matches baremetal behaviour when kvmclock in guest
sets sched clock stable.
Signed-off-by: Marcelo Tosatti
---
arch/x86/kvm/x86.c |4
1 file changed, 4 insertions
clock does provide a stable
sched_clock callback. So, let the scheduler know this which
in turn makes NOHZ_FULL work in the guest.
Signed-off-by: Marcelo Tosatti
Signed-off-by: Luiz Capitulino
---
arch/x86/kernel/kvmclock.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
Setting sched clock stable for kvmclock causes the printk timestamps
to not start from zero, which is different from baremetal and
can possibly break userspace. Add a flag to indicate that
hypervisor sets clock base at zero when kvmclock is initialized.
Signed-off-by: Marcelo Tosatti
kvmclock provides the behaviour sched_clock users expect.
Mark it as stable allowing nohz_full in guests.
See individual patches for more details.
v2: address comments from Paolo:
- set COUNTS_FROM_ZERO unconditionally (host).
- rely on KVM_FEATURE_CLOCKSOURCE_STABLE_BIT (guest).
Setting sched clock stable for kvmclock causes the printk timestamps
to not start from zero, which is different from baremetal and
can possibly break userspace. Add a flag to indicate that
hypervisor sets clock base at zero when kvmclock is initialized.
Signed-off-by: Marcelo Tosatti
kvmclock provides the behaviour sched_clock users expect.
Mark it as stable allowing nohz_full in guests.
See individual patches for more details.
--
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:/
Initialize kvmclock base, on kvmclock system MSR write time,
so that the guest sees kvmclock counting from zero.
This matches baremetal behaviour when kvmclock in guest
sets sched clock stable.
Signed-off-by: Marcelo Tosatti
---
arch/x86/kvm/x86.c |5 +
1 file changed, 5 insertions
clock does provide a stable
sched_clock callback. So, let the scheduler know this which
in turn makes NOHZ_FULL work in the guest.
Signed-off-by: Marcelo Tosatti
Signed-off-by: Luiz Capitulino
---
arch/x86/kernel/kvmclock.c | 17 +++--
1 file changed, 15 insertions(+), 2 dele
Initialize kvmclock base, on kvmclock system MSR write time,
so that the guest sees kvmclock counting from zero.
This matches baremetal behaviour when kvmclock in guest
sets sched clock stable.
Signed-off-by: Marcelo Tosatti
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index cc2c759
On Mon, May 18, 2015 at 10:13:03PM -0400, Sasha Levin wrote:
> On 05/18/2015 10:02 PM, Sasha Levin wrote:
> > On 05/18/2015 08:13 PM, Marcelo Tosatti wrote:
> >> GOn Mon, May 18, 2015 at 07:45:41PM -0400, Sasha Levin wrote:
> >>>> On 05/18/2015 06:39 PM, Marcelo To
Initialize kvmclock base, on kvmclock system MSR write time,
so that the guest sees kvmclock counting from zero.
This matches baremetal behaviour when kvmclock in guest
sets sched clock stable.
Signed-off-by: Marcelo Tosatti
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index cc2c759
.
v2:
-> Make parameter read-only (Radim)
-> Return early on kvmclock_sync_fn (Andrew)
Reported-and-tested-by: Luiz Capitulino
Signed-off-by: Marcelo Tosatti
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 986b3f5..4c0c954 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm
40/0x540
> [] kthread+0xef/0x110
> [] ? __kthread_parkme+0xa0/0xa0
> [] ret_from_fork+0x42/0x70
> [] ? __kthread_parkme+0xa0/0xa0
> ---[ end trace 06e3507544a38866 ]---
>
> However, it turns out that kvmclock does provide a stable
> sched_clock callback. So, let th
On Fri, Apr 24, 2015 at 10:36:14PM -0300, Marcelo Tosatti wrote:
>
> Drop unnecessary rdtsc_barrier(), as has been determined empirically,
> see 057e6a8c660e95c3f4e7162e00e2fee1fc90c50d for details.
>
> Noticed by Andy Lutomirski.
>
> Improves clock_gettime() by approximate
Drop unnecessary rdtsc_barrier(), as has been determined empirically,
see 057e6a8c660e95c3f4e7162e00e2fee1fc90c50d for details.
Noticed by Andy Lutomirski.
Improves clock_gettime() by approximately 15% on
Intel i7-3520M @ 2.90GHz.
Signed-off-by: Marcelo Tosatti
diff --git a/arch/x86/include
5,6 +1711,13 @@ static int kvm_guest_time_update(struct kvm_vcpu *v)
> kvm_write_guest_cached(v->kvm, &vcpu->pv_time,
> &vcpu->hv_clock,
> sizeof(vcpu->hv_clock));
> +
> + smp_wmb();
> +
> +
On Thu, Apr 23, 2015 at 02:02:29PM +0200, Paolo Bonzini wrote:
>
>
> On 23/04/2015 13:51, Marcelo Tosatti wrote:
> >>> > > https://bugzilla.redhat.com/show_bug.cgi?id=1174664
> >> >
> >> > That was the missing volatile in an asm. Older compi
On Thu, Apr 23, 2015 at 11:13:23AM +0200, Paolo Bonzini wrote:
>
>
> On 22/04/2015 23:21, Marcelo Tosatti wrote:
> > On Mon, Apr 20, 2015 at 01:27:58PM -0700, Andy Lutomirski wrote:
> >> On Mon, Apr 20, 2015 at 9:59 AM, Paolo Bonzini wrote:
> >>>
> >>
On Wed, Apr 22, 2015 at 11:01:49PM +0200, Paolo Bonzini wrote:
>
>
> On 22/04/2015 22:56, Marcelo Tosatti wrote:
> >> > But then why was the task migration notifier even in Jeremy's original
> >> > code for Xen?
> > To cover for the vcpu1 -> vcpu2
On Mon, Apr 20, 2015 at 01:27:58PM -0700, Andy Lutomirski wrote:
> On Mon, Apr 20, 2015 at 9:59 AM, Paolo Bonzini wrote:
> >
> >
> > On 17/04/2015 22:18, Marcelo Tosatti wrote:
> >> The bug which this is fixing is very rare, have no memory of a report.
> >&
On Mon, Apr 20, 2015 at 06:59:04PM +0200, Paolo Bonzini wrote:
>
>
> On 17/04/2015 22:18, Marcelo Tosatti wrote:
> > The bug which this is fixing is very rare, have no memory of a report.
> >
> > In fact, its even difficult to create a synthetic reproducer.
>
measure.
Signed-off-by: Marcelo Tosatti
Cc: sta...@kernel.org
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index cc2c759..e75fafd 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1658,12 +1658,20 @@ static int kvm_guest_time_update(struct kvm_vcpu *v
On Fri, Apr 17, 2015 at 05:04:29PM -0700, Andy Lutomirski wrote:
> On Fri, Apr 17, 2015 at 4:38 PM, Marcelo Tosatti wrote:
> >
> > From: Radim Krčmář
> >
> > As noted by Andy Lutomirski, kvm does not follow the documented version
> > protocol. Fix it.
> &g
On Fri, Apr 17, 2015 at 05:04:29PM -0700, Andy Lutomirski wrote:
> On Fri, Apr 17, 2015 at 4:38 PM, Marcelo Tosatti wrote:
> >
> > From: Radim Krčmář
> >
> > As noted by Andy Lutomirski, kvm does not follow the documented version
> > protocol. Fix it.
> &g
On Fri, Apr 17, 2015 at 03:25:28PM -0700, Andy Lutomirski wrote:
> On Fri, Apr 17, 2015 at 3:04 PM, Linus Torvalds
> wrote:
> > On Fri, Apr 17, 2015 at 5:42 PM, Andy Lutomirski
> > wrote:
> >>
> >> Muahaha. The auditors have invaded your system. (I did my little
> >> benchmark with a more sens
.
Signed-off-by: Marcelo Tosatti
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index cc2c759f69a3..8658599e0024 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1658,12 +1658,24 @@ static int kvm_guest_time_update(struct kvm_vcpu *v)
&guest_hv_clock, si
On Fri, Apr 17, 2015 at 09:57:12PM +0200, Paolo Bonzini wrote:
>
>
> >> From 4eb9d7132e1990c0586f28af3103675416d38974 Mon Sep 17 00:00:00 2001
> >> From: Paolo Bonzini
> >> Date: Fri, 17 Apr 2015 14:57:34 +0200
> >> Subject: [PATCH] sched: add CONFIG_TASK_MIGRATION_NOTIFIER
> >>
> >> The task mi
On Fri, Apr 17, 2015 at 03:38:58PM +0200, Paolo Bonzini wrote:
> On 17/04/2015 15:10, Peter Zijlstra wrote:
> > On Fri, Apr 17, 2015 at 02:46:57PM +0200, Paolo Bonzini wrote:
> >> On 17/04/2015 12:55, Peter Zijlstra wrote:
> >>> Also, it looks like you already do exactly this for other things, look
Sebastian,
rebased against v3.18.7-rt2 as requested.
The problem:
On -RT, an emulated LAPIC timer instance has the following path:
1) hard interrupt
2) ksoftirqd is scheduled
3) ksoftirqd wakes up vcpu thread
4) vcpu thread is scheduled
This extra context switch introduces unnecessary latency
context.
cyclictest command line:
# cyclictest -m -n -q -p99 -l 100 -h60 -D 1m
This patch reduces the average latency in my tests from 14us to 11us.
Signed-off-by: Marcelo Tosatti
---
arch/arm/kvm/arm.c |4 ++--
arch/arm/kvm/psci.c |4 ++--
arch
Since lapic timer handler only wakes up a simple waitqueue,
it can be executed from hardirq context.
Also handle the case where hrtimer_start_expires fails due to -ETIME,
by injecting the interrupt to the guest immediately.
Reduces average cyclictest latency by 3us.
Signed-off-by: Marcelo
) ||
> + smp_rmb();
> + } while (unlikely((pvti->pvti.version & 1) ||
> pvti->pvti.version != version ||
> pvti->migrate_count != migrate_count));
>
> --
> 2.3.4
>
> --
> To unsubscribe
On Mon, Mar 30, 2015 at 04:46:55AM +, Wu, Feng wrote:
>
>
> > -Original Message-
> > From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
> > Sent: Saturday, March 28, 2015 3:30 AM
> > To: Wu, Feng
> > Cc: h...@zytor.com; t...@linutronix.de; mi..
Linus,
Please pull from
git://git.kernel.org/pub/scm/virt/kvm/kvm.git master
To receive the following PPC KVM bug fixes
Marcelo Tosatti (1):
Merge tag 'signed-for-4.0' of git://github.com/agraf/linux-2.6
Paul Mackerras (3):
KVM: PPC: Book3S HV: Fix spinlock/mutex orde
On Fri, Mar 27, 2015 at 06:34:14AM +, Wu, Feng wrote:
> > > Currently, the following code is executed before local_irq_disable() is
> > > called,
> > > so do you mean 1)moving local_irq_disable() to the place before it. 2)
> > > after
> > interrupt
> > > is disabled, set KVM_REQ_EVENT in case
On Mon, Mar 23, 2015 at 07:27:19PM +0100, Jan Kiszka wrote:
> From: Jan Kiszka
>
> If the guest CPU is supposed to support rdtscp and the host has rdtscp
> enabled in the secondary execution controls, we can also expose this
> feature to L1. Just extend nested_vmx_exit_handled to properly route
>
ES; i++)
> > + for (i = 0; i < KVM_NR_BUSES; i++) {
> > kvm_io_bus_destroy(kvm->buses[i]);
> > + kvm->buses[i] = NULL;
> > + }
> > kvm_coalesced_mmio_free(kvm);
> > #if defined(CONFIG_MMU_NOTIFIER) && defined(KVM_ARCH_WANT_MM
On Thu, Mar 26, 2015 at 04:28:37PM -0700, Andy Lutomirski wrote:
> On Thu, Mar 26, 2015 at 4:22 PM, Marcelo Tosatti wrote:
> > On Thu, Mar 26, 2015 at 04:09:53PM -0700, Andy Lutomirski wrote:
> >> On Thu, Mar 26, 2015 at 3:56 PM, Marcelo Tosatti
> >> wrote:
> >
On Thu, Mar 26, 2015 at 04:09:53PM -0700, Andy Lutomirski wrote:
> On Thu, Mar 26, 2015 at 3:56 PM, Marcelo Tosatti wrote:
> > On Thu, Mar 26, 2015 at 01:58:25PM -0700, Andy Lutomirski wrote:
> >> On Thu, Mar 26, 2015 at 1:31 PM, Radim Krcmar wrote:
> >> > 2015-03-
On Thu, Mar 26, 2015 at 01:58:25PM -0700, Andy Lutomirski wrote:
> On Thu, Mar 26, 2015 at 1:31 PM, Radim Krcmar wrote:
> > 2015-03-26 11:51-0700, Andy Lutomirski:
> >> On Thu, Mar 26, 2015 at 4:29 AM, Marcelo Tosatti
> >> wrote:
> >> > On Wed, Mar 25, 20
On Thu, Mar 26, 2015 at 03:24:10PM -0700, Andy Lutomirski wrote:
> On Thu, Mar 26, 2015 at 3:22 PM, Marcelo Tosatti wrote:
> > On Thu, Mar 26, 2015 at 09:59:24PM +0100, Radim Krčmář wrote:
> >> 2015-03-23 20:21-0300, Marcelo Tosatti:
> >> >
> >> > The fol
On Thu, Mar 26, 2015 at 09:59:24PM +0100, Radim Krčmář wrote:
> 2015-03-23 20:21-0300, Marcelo Tosatti:
> >
> > The following point:
> >
> > 2. per-CPU pvclock time info is updated if the
> >underlying CPU changes.
> >
> > Is not true
On Wed, Mar 25, 2015 at 04:22:03PM -0700, Andy Lutomirski wrote:
> On Wed, Mar 25, 2015 at 4:13 PM, Marcelo Tosatti wrote:
> > On Wed, Mar 25, 2015 at 03:48:02PM -0700, Andy Lutomirski wrote:
> >> On Wed, Mar 25, 2015 at 3:41 PM, Marcelo Tosatti
> >> wrote:
> >
On Wed, Mar 25, 2015 at 10:58:54PM +0100, Alexander Graf wrote:
> Hi Paolo,
>
> This is my current patch queue for 4.0. Please pull.
>
> Alex
>
>
> The following changes since commit f710a12d73dfa1c3a5d2417f2482b970f03bb850:
>
> Merge tag 'kvm-arm-fixes-4.0-rc5' of
> git://git.kernel.org/p
On Mon, Mar 16, 2015 at 11:42:06AM +, Wu, Feng wrote:
> > Do you have any reason why having the code at vcpu_put/vcpu_load is
> > better than the proposal to have the code at kvm_vcpu_block?
>
> I think your proposal is good, I just want to better understand your idea
> here.:)
Reduce the ov
On Wed, Mar 25, 2015 at 03:48:02PM -0700, Andy Lutomirski wrote:
> On Wed, Mar 25, 2015 at 3:41 PM, Marcelo Tosatti wrote:
> > On Wed, Mar 25, 2015 at 03:33:10PM -0700, Andy Lutomirski wrote:
> >> On Mar 25, 2015 2:29 PM, "Marcelo Tosatti" wrote:
> >> >
&
On Wed, Mar 25, 2015 at 03:33:10PM -0700, Andy Lutomirski wrote:
> On Mar 25, 2015 2:29 PM, "Marcelo Tosatti" wrote:
> >
> > On Wed, Mar 25, 2015 at 01:52:15PM +0100, Radim Krčmář wrote:
> > > 2015-03-25 12:08+0100, Radim Krčmář:
> > > > Reverting t
On Wed, Mar 25, 2015 at 05:09:13PM +, Marc Zyngier wrote:
> On 23/03/15 15:58, Andre Przywara wrote:
> > In kvm_destroy_vm() we call kvm_io_bus_destroy() pretty early,
> > especially before calling kvm_arch_destroy_vm(). To avoid
> > unregistering devices from the already destroyed bus, let's m
his
> > directory the compiler's include path, so remove it from the x86 kvm
> > Makefile.
> >
> > Signed-off-by: Andre Przywara
>
> Reviewed-by: Marc Zyngier
>
> Paolo, Marcelo: can we have your Ack on this?
>
> Thanks,
>
> M.
Revi
olves a problem later when using struct kvm_io_device
> > in arm_vgic.h.
> > Fixing up the FSF address in the GPL header and a wrong include path
> > on the way.
> >
> > Signed-off-by: Andre Przywara
> > Acked-by: Christoffer Dall
>
> Reviewed-by: Marc
On Wed, Mar 25, 2015 at 01:52:15PM +0100, Radim Krčmář wrote:
> 2015-03-25 12:08+0100, Radim Krčmář:
> > Reverting the patch protects us from any migration, but I don't think we
> > need to care about changing VCPUs as long as we read a consistent data
> > from kvmclock. (VCPU can change outside o
On Tue, Mar 24, 2015 at 04:34:12PM +0100, Radim Krčmář wrote:
> 2015-03-23 20:21-0300, Marcelo Tosatti:
> > The following point:
> >
> > 2. per-CPU pvclock time info is updated if the
> >underlying CPU changes.
> >
> > Is not true anymo
Linus,
Please pull from
git://git.kernel.org/pub/scm/virt/kvm/kvm.git master
To receive the following: fix for higher-order page
allocation failures, fix Xen-on-KVM with x2apic,
L1 crash with unrestricted guest mode (nested VMX).
Igor Mammedov (1):
kvm: avoid page allocation failure in
As thats more indicative of the variables usage.
Suggested by Andy Lutomirski.
Signed-off-by: Marcelo Tosatti
diff --git a/arch/x86/include/asm/pvclock.h b/arch/x86/include/asm/pvclock.h
index 25b1cc0..1c1b474 100644
--- a/arch/x86/include/asm/pvclock.h
+++ b/arch/x86/include/asm/pvclock.h
On Thu, Mar 19, 2015 at 09:52:41PM +0100, Radim Krčmář wrote:
> An overhead from function call is not appropriate for its size and
> frequency of execution.
>
> Suggested-by: Paolo Bonzini
> Signed-off-by: Radim Krčmář
> ---
> I'm not very fond of that smp_rmb(): there is no real synchronizati
On Wed, Mar 18, 2015 at 12:43:58PM +0100, Christian Borntraeger wrote:
> Paolo, Marcelo,
>
> here is the followup pull request. As Marcelo has not yet pushed out
> queue or next to git.kernel.org, this request is based on the previous
> s390 pull request and should merge without conflicts.
>
> Fo
On Wed, Mar 18, 2015 at 07:38:22PM +0100, Radim Krčmář wrote:
> kvm_ioapic_update_eoi() wasn't called if directed EOI was enabled.
> We need to do that for irq notifiers. (Like with edge interrupts.)
>
> Fix it by skipping EOI broadcast only.
>
> Bug: https://bugzilla.kernel.org/show_bug.cgi?id=
The following point:
2. per-CPU pvclock time info is updated if the
underlying CPU changes.
Is not true anymore since "KVM: x86: update pvclock area conditionally,
on cpu migration".
Add task migration notification back.
Problem noticed by Andy Lutomirski.
Signed-off-b
On Fri, Mar 20, 2015 at 09:51:26AM +, Igor Mammedov wrote:
> KVM guest can fail to startup with following trace on host:
>
> qemu-system-x86: page allocation failure: order:4, mode:0x40d0
> Call Trace:
> dump_stack+0x47/0x67
> warn_alloc_failed+0xee/0x150
> __alloc_pages_direct_compact+0
On Thu, Mar 19, 2015 at 02:15:18PM +0100, Thomas Huth wrote:
> > Date: Wed, 18 Mar 2015 21:23:48 -0300
> > From: Marcelo Tosatti
> >
> > On Mon, Mar 16, 2015 at 09:51:40AM +0100, Christian Borntraeger wrote:
> > > From: Thomas Huth
> > >
> > &g
On Wed, Mar 18, 2015 at 07:38:22PM +0100, Radim Krčmář wrote:
> kvm_ioapic_update_eoi() wasn't called if directed EOI was enabled.
> We need to do that for irq notifiers. (Like with edge interrupts.)
>
> Fix it by skipping EOI broadcast only.
>
> Bug: https://bugzilla.kernel.org/show_bug.cgi?id=
On Tue, Mar 17, 2015 at 09:58:21AM +0100, Paolo Bonzini wrote:
>
>
> On 17/03/2015 08:19, Takuya Yoshikawa wrote:
> > When all bits in mask are not set,
> > kvm_arch_mmu_enable_log_dirty_pt_masked() has nothing to do. But since
> > it needs to be called from the generic code, it cannot be inline
On Wed, Mar 18, 2015 at 06:59:22PM -0600, James Sullivan wrote:
> >
> > The documentation states the following:
> >
> > * When RH is 0, the interrupt is directed to the processor listed in the
> > Destination ID field.
> >
> > * If RH is 0, then the DM bit is ignored and the message is sent ahea
On Wed, Mar 18, 2015 at 06:59:22PM -0600, James Sullivan wrote:
> >
> > The documentation states the following:
> >
> > * When RH is 0, the interrupt is directed to the processor listed in the
> > Destination ID field.
> >
> > * If RH is 0, then the DM bit is ignored and the message is sent ahea
On Mon, Mar 16, 2015 at 05:18:25PM -0400, Bandan Das wrote:
>
> I hit this path on a AMD box and thought
> someone was playing a April Fool's joke on me.
>
> Signed-off-by: Bandan Das
> ---
> arch/x86/kvm/svm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
--
To uns
On Mon, Mar 16, 2015 at 04:10:40PM +0100, Saso Slavicic wrote:
> Hi,
>
> I'm fairly experienced with KVM (Centos 5/6), running about a dozen servers
> with 20-30 different (Linux & MS platform) systems.
> I have one Windows XP machine that acts very strangely - it freezes. I get
> ping timeout for
On Mon, Mar 16, 2015 at 09:51:40AM +0100, Christian Borntraeger wrote:
> From: Thomas Huth
>
> On s390, we've got to make sure to hold the IPTE lock while accessing
> logical memory. So let's add an ioctl for reading and writing logical
> memory to provide this feature for userspace, too.
> The m
On Fri, Mar 13, 2015 at 05:48:04PM +0100, Radim Krčmář wrote:
> GCC 5.0.0 enables raw strings by default and they have higher priority
> than macros, thus R"[...]" is interpreted incorrectly:
>
> lib/x86/isr.c:112:30: error: invalid character ')' in raw string delimiter
> lib/x86/isr.c:112:8:
1 - 100 of 4627 matches
Mail list logo
