Il 02/09/2014 18:13, Laurent Dufour ha scritto:
fc95ca7284bc54953165cba76c3228bd2cdb9591 introduces a memset in
kvmppc_alloc_hpt since the general CMA doesn't clear the memory it
allocates.
However, the size argument passed to memset is computed from a signed value
and its signed bit is
On 01.09.14 11:01, Mihai Caraman wrote:
ePAPR represents hardware threads as cpu node properties in device tree.
So with existing QEMU, hardware threads are simply exposed as vcpus with
one hardware thread.
The e6500 core shares TLBs between hardware threads. Without tlb write
conditional
https://bugzilla.kernel.org/show_bug.cgi?id=82211
--- Comment #9 from Paolo Bonzini bonz...@gnu.org ---
Nope, your binary works with kvm/queue for me:
/sys/module/kvm_intel/parameters/emulate_invalid_guest_state:Y
/sys/module/kvm_intel/parameters/enable_apicv:N
Hello Eric,
On 09/02/2014 10:31 PM, Eric Blake wrote:
On 09/02/2014 09:25 AM, David Marchand wrote:
Here is a patchset containing an update on ivshmem specs documentation and
importing ivshmem server and client tools.
These tools have been written from scratch and are not related to what is
Il 02/09/2014 21:57, Chris J Arges ha scritto:
Can you please trace the test using trace-cmd
(http://www.linux-kvm.org/page/Tracing) and send the output?
Paolo
Paolo,
I have posted the trace data here:
http://people.canonical.com/~arges/kvm/trace.dat.xz
Can you try running the
Il 02/09/2014 21:57, Chris J Arges ha scritto:
Seconds get from host: 1409687073
Seconds get from kvmclock: 1409333034
Offset:-354039
offset too large!
Check the stability of raw cycle ...
Worst warp -354462672821748
Total vcpus: 2
Test loops: 1000
Total
On Wed, Sep 03, 2014 at 09:42:30AM +0800, tangchen wrote:
Hi Gleb,
On 09/03/2014 12:00 AM, Gleb Natapov wrote:
..
+static void vcpu_reload_apic_access_page(struct kvm_vcpu *vcpu)
+{
+/*
+ * apic access page could be migrated. When the page is being migrated,
+ * GUP will
On Wed, Aug 27, 2014 at 06:17:40PM +0800, Tang Chen wrote:
This patch only handle L1 and L2 vm share one apic access page situation.
When L1 vm is running, if the shared apic access page is migrated,
mmu_notifier will
request all vcpus to exit to L0, and reload apic access page physical
On 09/03/2014 09:47 AM, Paolo Bonzini wrote:
Il 02/09/2014 21:57, Chris J Arges ha scritto:
Can you please trace the test using trace-cmd
(http://www.linux-kvm.org/page/Tracing) and send the output?
Paolo
Paolo,
I have posted the trace data here:
On 09/03/2014 07:01 AM, David Marchand wrote:
Rather than introducing new files with bugs, followed by patches to
clean it up, why not just introduce the new files correct in the first
place? I think you are better off squashing in a lot of the cleanup
patches into patch 1.
Actually, I
On 09/03/2014 09:59 AM, Paolo Bonzini wrote:
Il 02/09/2014 21:57, Chris J Arges ha scritto:
Seconds get from host: 1409687073
Seconds get from kvmclock: 1409333034
Offset:-354039
offset too large!
Check the stability of raw cycle ...
Worst warp -354462672821748
Il 03/09/2014 18:23, Chris J Arges ha scritto:
$ uptime
16:18:31 up 53 min, 1 user, load average: 1.16, 0.39, 0.17
$ grep -m1 model.name /proc/cpuinfo
model name : Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz
Here is the output of the command:
qemu-system-x86_64 -enable-kvm -device
snip
I'm not sure about the reason for the warp, but indeed the offset and
uptime match (I'll check them against the trace tomorrow) so it's just
that the VM's TSC base is not taken into account correctly.
Can you gather another trace with the problematic patch reverted?
Paolo
Here is
On Tue, Aug 26, 2014 at 12:08:32PM +0300, Pekka Enberg wrote:
On Sun, Aug 17, 2014 at 11:54 AM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 15/08/2014 18:54, Marcelo Tosatti ha scritto:
Ping on integration.
It's been in kvm/next for a while, and is now in Linus's tree:
Does this make
-Original Message-
From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On
Behalf Of Wang, Wei W
Sent: Friday, August 29, 2014 8:59 AM
To: Paolo Bonzini; Zhang, Yang Z; kvm@vger.kernel.org
Cc: alex.william...@redhat.com
Subject: RE: [PATCH v2] KVM: x86: keep eoi exit
Hi, all
I start a VM with virtio-serial (default ports number: 31), and found
that virtio-blk performance degradation happened, about 25%, this
problem can be reproduced 100%.
without virtio-serial:
4k-read-random 1186 IOPS
with virtio-serial:
4k-read-random 871 IOPS
but
Hi Jason,
I tested below patch, it's okay, the e1000 interrupt storm disappeared.
But I am going to make a bit change on it, could you help review it?
Currently, we call ioapic_service() immediately when we find the irq is
still
active during eoi broadcast. But for real hardware, there's
On 09/04/2014 09:56 AM, Zhang Haoyu wrote:
Hi Jason,
I tested below patch, it's okay, the e1000 interrupt storm disappeared.
But I am going to make a bit change on it, could you help review it?
Currently, we call ioapic_service() immediately when we find the irq
is still
active
Il 02/09/2014 18:13, Laurent Dufour ha scritto:
fc95ca7284bc54953165cba76c3228bd2cdb9591 introduces a memset in
kvmppc_alloc_hpt since the general CMA doesn't clear the memory it
allocates.
However, the size argument passed to memset is computed from a signed value
and its signed bit is
On 01.09.14 11:01, Mihai Caraman wrote:
ePAPR represents hardware threads as cpu node properties in device tree.
So with existing QEMU, hardware threads are simply exposed as vcpus with
one hardware thread.
The e6500 core shares TLBs between hardware threads. Without tlb write
conditional
20 matches
Mail list logo
