On 12/01/2014 19:50, Andrea Arcangeli wrote:
> On Sun, Jan 12, 2014 at 01:56:12PM +0200, Haggai Eran wrote:
>> Hi,
>>
>> On 10/01/2014 18:57, Andrea Arcangeli wrote:
>>> Hi!
>>>
>>> On Fri, Jan 10, 2014 at 06:38:06PM +0200, Izik Eidus wrote:
It look like commit 6bdb913f0a70a4dfb7f066fb15e2d6f9
On 2014-01-15 13:40, Paolo Bonzini wrote:
> Il 15/01/2014 13:39, Andrew Jones ha scritto:
>> Commit e66d2ae7c67bd moved the assignment
>> vcpu->arch.apic_base = value above a condition with
>> (vcpu->arch.apic_base ^ value), causing that check
>> to always fail. Use old_value, vcpu->arch.apic_base'
On Wed, 2014-01-15 at 16:59 +0800, 李义 wrote:
> >Which OS is this, exactly?
> >Does this reproduce with a newer guest?
>
> the guest kernel (2.6.32.43) is come from the mainline of kernel.org.
> this issue just happened once at my guest kernel (2.6.32.43).
What are the options used to start the VM
On Wed, Jan 15, 2014 at 06:08:11PM +0100, Paolo Bonzini wrote:
> After the previous patch from Marcelo, the comment before this write
> became obsolete. In fact, the write is unnecessary. The calls to
> kvm_write_tsc ultimately result in a master clock update as soon as
> all TSCs agree and the m
On Tue, Jan 14, 2014 at 8:45 PM, Alex Williamson
wrote:
> PCI resets will attempt to take the device_lock for any device to be
> reset. This is a problem if that lock is already held, for instance
> in the device remove path. It's not sufficient to simply kill the
> user process or skip the rese
Dear KVM community,
I am quite new to virtualization implementation. Does any one know how
KVM handles cases when the guest OS disables paging? To the best of my
knowledge, the hypervisor should not use the same shadow page table
because the translation is no longer valid. Can anyone point out how
After the previous patch from Marcelo, the comment before this write
became obsolete. In fact, the write is unnecessary. The calls to
kvm_write_tsc ultimately result in a master clock update as soon as
all TSCs agree and the master clock is re-enabled. This master
clock update will rewrite tsc_t
On Wed, Jan 15, 2014 at 05:53:22PM +0100, Paolo Bonzini wrote:
> Il 15/01/2014 17:37, Marcelo Tosatti ha scritto:
> > > Right. Another question, what about this comment:
> > >
> > > /* Reset of TSC must disable overshoot protection below */
> > > vcpu->arch.hv_clock.tsc_timestamp
Il 15/01/2014 17:37, Marcelo Tosatti ha scritto:
> > Right. Another question, what about this comment:
> >
> > /* Reset of TSC must disable overshoot protection below */
> > vcpu->arch.hv_clock.tsc_timestamp = 0;
> > vcpu->arch.last_guest_tsc = data;
> >
> > Should it be
On Wed, Jan 15, 2014 at 01:55:50PM +0100, Paolo Bonzini wrote:
> Il 15/01/2014 13:34, Marcelo Tosatti ha scritto:
> > On Wed, Jan 15, 2014 at 12:43:02PM +0100, Paolo Bonzini wrote:
> >> Il 06/01/2014 15:18, Marcelo Tosatti ha scritto:
> >>>
> >>> To fix a problem related to different resolution of
Just an update, I found that with different tools I was able to see a
repeating 'lapic increasing min_delta_ns' scrolling furiously. I've
added -no-hpet to the cmdline, but was still able to replicate it.
On Tue, Jan 14, 2014 at 1:36 PM, Marcus Sorensen wrote:
> Does anyone have tips on troublesh
Il 15/01/2014 13:34, Marcelo Tosatti ha scritto:
> On Wed, Jan 15, 2014 at 12:43:02PM +0100, Paolo Bonzini wrote:
>> Il 06/01/2014 15:18, Marcelo Tosatti ha scritto:
>>>
>>> To fix a problem related to different resolution of TSC and system clock,
>>> the offset in TSC units is approximated by
>>>
On Wed, Jan 15, 2014 at 12:43:02PM +0100, Paolo Bonzini wrote:
> Il 06/01/2014 15:18, Marcelo Tosatti ha scritto:
> >
> > To fix a problem related to different resolution of TSC and system clock,
> > the offset in TSC units is approximated by
> >
> > delta = vcpu->hv_clock.tsc_timestamp-
Il 15/01/2014 13:39, Andrew Jones ha scritto:
> Commit e66d2ae7c67bd moved the assignment
> vcpu->arch.apic_base = value above a condition with
> (vcpu->arch.apic_base ^ value), causing that check
> to always fail. Use old_value, vcpu->arch.apic_base's
> old value, in the condition instead.
>
> Si
Commit e66d2ae7c67bd moved the assignment
vcpu->arch.apic_base = value above a condition with
(vcpu->arch.apic_base ^ value), causing that check
to always fail. Use old_value, vcpu->arch.apic_base's
old value, in the condition instead.
Signed-off-by: Andrew Jones
---
arch/x86/kvm/lapic.c | 2 +-
On Wed, Jan 15, 2014 at 12:43:02PM +0100, Paolo Bonzini wrote:
> Il 06/01/2014 15:18, Marcelo Tosatti ha scritto:
> >
> > To fix a problem related to different resolution of TSC and system clock,
> > the offset in TSC units is approximated by
> >
> > delta = vcpu->hv_clock.tsc_timestamp-
Il 15/01/2014 11:11, James Hogan ha scritto:
> ProAptiv support includes support for EHINV (TLB invalidation) and FTLB
> (large fixed page size TLBs), both of which cause problems when combined
> with KVM. These two patches fix those problems.
>
> These are based on John Crispin's mips-next-3.14 b
Il 06/01/2014 15:00, Marcelo Tosatti ha scritto:
>
>
> Limit PIT timer frequency similarly to the limit applied by
> LAPIC timer.
>
> Cc: sta...@kernel.org
> Signed-off-by: Marcelo Tosatti
>
> diff --git a/arch/x86/kvm/i8254.c b/arch/x86/kvm/i8254.c
> index 412a5aa..518d864 100644
> --- a/arc
Il 06/01/2014 15:18, Marcelo Tosatti ha scritto:
>
> To fix a problem related to different resolution of TSC and system clock,
> the offset in TSC units is approximated by
>
> delta = vcpu->hv_clock.tsc_timestamp - vcpu->last_guest_tsc
>
> (Guest TSC value at (Guest TSC
Il 08/01/2014 23:47, Christoffer Dall ha scritto:
> git://git.linaro.org/people/christoffer.dall/linux-kvm-arm.git
> tags/kvm-arm-for-3.14
Pulled, thanks.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info
Il 03/01/2014 20:09, Marcelo Tosatti ha scritto:
>
> Rom Freiman notes other code paths vulnerable to
> bug fixed by 989c6b34f6a9480e397b.
>
> Signed-off-by: Marcelo Tosatti
>
> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> index 31a5702..e50425d 100644
> --- a/arch/x86/kvm/mmu.c
> +
Il 10/01/2014 01:43, Scott Wood ha scritto:
> Commit 7940876e1330671708186ac3386aa521ffb5c182 ("kvm: make local
> functions static") broke KVM PPC builds due to removing (rather than
> moving) the stub version of kvm_vcpu_eligible_for_directed_yield().
>
> This patch reintroduces it.
>
> Signed-o
Il 10/01/2014 01:28, Paul Bolle ha scritto:
> Building vfio.o triggers a GCC warning (when building for 32 bits x86):
> arch/x86/kvm/../../../virt/kvm/vfio.c: In function 'kvm_vfio_set_group':
> arch/x86/kvm/../../../virt/kvm/vfio.c:104:22: warning: cast to pointer
> from integer of differ
On 01/15/2014 10:11 AM, James Hogan wrote:
When KVM is enabled and TLB invalidation is supported,
kvm_mips_flush_host_tlb() can cause a machine check exception due to
multiple matching TLB entries. This can occur on shutdown even when KVM
hasn't been actively used.
Commit adb78de9eae8 (MIPS: mm:
ProAptiv support includes support for EHINV (TLB invalidation) and FTLB
(large fixed page size TLBs), both of which cause problems when combined
with KVM. These two patches fix those problems.
These are based on John Crispin's mips-next-3.14 branch where ProAptiv
support is applied. Please conside
The initialisation of the shadow host TLB assumes the number of host TLB
entries <= 64, an assumption that can break in the presense of an FTLB
for which support was recently added. This results in an overflow and
amongst other things the comparecount timer callback function pointer
being overwritt
When KVM is enabled and TLB invalidation is supported,
kvm_mips_flush_host_tlb() can cause a machine check exception due to
multiple matching TLB entries. This can occur on shutdown even when KVM
hasn't been actively used.
Commit adb78de9eae8 (MIPS: mm: Move UNIQUE_ENTRYHI macro to a header
file)
On Wed, Jan 15, 2014 at 04:59:45PM +0800, 李义 wrote:
> >Which OS is this, exactly?
> >Does this reproduce with a newer guest?
>
> the guest kernel (2.6.32.43) is come from the mainline of kernel.org.
> this issue just happened once at my guest kernel (2.6.32.43).
Hmm. Could be one of the gazillion
>Which OS is this, exactly?
>Does this reproduce with a newer guest?
the guest kernel (2.6.32.43) is come from the mainline of kernel.org.
this issue just happened once at my guest kernel (2.6.32.43).
>What uses irq 11? Could you check with lspci before you try to shutdown?
# lspci
00:00.0 Host
On Wed, Jan 15, 2014 at 02:48:35PM +0800, 李义 wrote:
> Hi ALL,
>
> i have meet kvm guest os issue at redhat7beta.
>
> Host os:
> iredhat7 Beta
> #virsh version
> Compiled against library: libvirt 1.1.1
> Using library: libvirt 1.1.1
> Using API: QEMU 1.1.1
> Running hypervisor: QEMU 1.5.3
>
> g
30 matches
Mail list logo
