On 09/08/2010 11:33 PM, Anthony Liguori wrote:
On 09/08/2010 03:05 PM, Arjan Koers wrote:
On 2010-09-08 18:29, Marcelo Tosatti wrote:
qemu-kvm-0.13.0-rc1 is now available. This release is based on the
upstream qemu 0.13.0-rc1, plus kvm-specific enhancements.
This release can be used with the
From: Jes Sorensen jes.soren...@redhat.com
Some operating systems store data about the host processor at the
time of installation, and when booted on a more uptodate cpu tries
to read MSR_EBC_FREQUENCY_ID. This has been found with XP.
Signed-off-by: Jes Sorensen jes.soren...@redhat.com
---
On 09/09/2010 10:33 AM, jes.soren...@redhat.com wrote:
From: Jes Sorensenjes.soren...@redhat.com
Some operating systems store data about the host processor at the
time of installation, and when booted on a more uptodate cpu tries
to read MSR_EBC_FREQUENCY_ID. This has been found with XP.
On 09/09/10 10:12, Avi Kivity wrote:
From the spec:
31:24 Core Clock Frequency to System
Bus Frequency Ratio. (R)
The processor core clock
frequency to system bus
frequency ratio observed at the
de-assertion of the reset pin.
A frequency ratio of 0 might
On Wednesday 08 September 2010 18:04:18 Avi Kivity wrote:
On 09/04/2010 04:29 PM, Hillf Danton wrote:
The second call to kvm_mmu_reset_context() seems unnecessary and is
removed.
@@ -783,10 +783,6 @@ static int set_efer(struct kvm_vcpu *vcp
vcpu-arch.mmu.base_role.nxe = (efer
On 09/09/10 10:29, Jes Sorensen wrote:
On 09/09/10 10:12, Avi Kivity wrote:
From the spec:
31:24 Core Clock Frequency to System
Bus Frequency Ratio. (R)
The processor core clock
frequency to system bus
frequency ratio observed at the
de-assertion of the reset
Krishna Kumar2/India/IBM wrote on 09/08/2010 10:17:49 PM:
Some more results and likely cause for single netperf
degradation below.
Guest - Host (single netperf):
I am getting a drop of almost 20%. I am trying to figure out
why.
Host - guest (single netperf):
I am getting an improvement
From: Jes Sorensen jes.soren...@redhat.com
Hi,
Discussed this with Juan and he spotted this place in
arch/x86/kernel/cpu/cpufreq/speedstep-lib.c which relies on the 'Core
Clock Frequency to System Bus Frequency Ratio', so leaving it set to 0
is not going to work. Reading the spec it also says
From: Jes Sorensen jes.soren...@redhat.com
Signed-off-by: Jes Sorensen jes.soren...@redhat.com
---
arch/x86/include/asm/msr-index.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 986f779..83c4bb1
From: Jes Sorensen jes.soren...@redhat.com
Some operating systems store data about the host processor at the
time of installation, and when booted on a more uptodate cpu tries
to read MSR_EBC_FREQUENCY_ID. This has been found with XP.
Signed-off-by: Jes Sorensen jes.soren...@redhat.com
---
On Wednesday 08 September 2010, Krishna Kumar2 wrote:
On Wednesday 08 September 2010, Krishna Kumar2 wrote:
The new guest and qemu code work with old vhost-net, just with
reduced
performance, yes?
Yes, I have tested new guest/qemu with old vhost but using
#numtxqs=1 (or not
jes.soren...@redhat.com wrote:
From: Jes Sorensen jes.soren...@redhat.com
Hi,
Discussed this with Juan and he spotted this place in
arch/x86/kernel/cpu/cpufreq/speedstep-lib.c which relies on the 'Core
Clock Frequency to System Bus Frequency Ratio', so leaving it set to 0
is not going to
-Original Message-
From: Hollis Blanchard [mailto:hollis_blanch...@mentor.com]
Sent: Thursday, September 09, 2010 12:07 AM
To: Liu Yu-B13201
Cc: kvm@vger.kernel.org; kvm-...@vger.kernel.org; ag...@suse.de
Subject: Re: [PATCH 1/2] kvm/e500v2: Remove shadow tlb
On 09/08/2010
On 09/09/2010 01:17 AM, Avi Kivity wrote:
On 09/08/2010 11:33 PM, Anthony Liguori wrote:
On 09/08/2010 03:05 PM, Arjan Koers wrote:
On 2010-09-08 18:29, Marcelo Tosatti wrote:
qemu-kvm-0.13.0-rc1 is now available. This release is based on the
upstream qemu 0.13.0-rc1, plus kvm-specific
Krishna Kumar2/India/IBM wrote on 09/09/2010 03:15:53 PM:
I will start a full test run of original vs submitted
code with minimal tuning (Avi also suggested the same),
and re-send. Please let me know if you need any other
data.
Same patch, only change is that I ran taskset -p 03
all vhost
Arnd Bergmann a...@arndb.de wrote on 09/09/2010 04:10:27 PM:
Can you live migrate a new guest from new-qemu/new-kernel
to old-qemu/old-kernel, new-qemu/old-kernel and old-qemu/new-kernel?
If not, do we need to support all those cases?
I have not tried this, though I added some
Rusty Russell ru...@rustcorp.com.au wrote on 09/09/2010 05:44:25 PM:
This seems a bit weird. I mean, the driver used vdev-config-
find_vqs
to find the queues, which returns them (in order). So, can't you put
this
into your struct send_queue?
I am saving the vqs in the send_queue,
On Wed, Sep 01 2010 at 11:22pm -0400,
Mike Snitzer snit...@redhat.com wrote:
On Wed, Sep 01 2010 at 2:59pm -0400,
Mike Snitzer snit...@redhat.com wrote:
My hope was that the request-based deadlock I'm seeing would disappear
if that relaxed ordering patch wasn't applied. Unfortunately, I
* Mike Snitzer snit...@redhat.com [2010-09-09 10:29]:
On Wed, Sep 01 2010 at 11:22pm -0400,
Mike Snitzer snit...@redhat.com wrote:
On Wed, Sep 01 2010 at 2:59pm -0400,
Mike Snitzer snit...@redhat.com wrote:
My hope was that the request-based deadlock I'm seeing would disappear
if
On Thu, Sep 09 2010 at 11:44am -0400,
Ryan Harper ry...@us.ibm.com wrote:
* Mike Snitzer snit...@redhat.com [2010-09-09 10:29]:
On Wed, Sep 01 2010 at 11:22pm -0400,
Mike Snitzer snit...@redhat.com wrote:
On Wed, Sep 01 2010 at 2:59pm -0400,
Mike Snitzer snit...@redhat.com wrote:
* Mike Snitzer snit...@redhat.com [2010-09-09 10:58]:
On Thu, Sep 09 2010 at 11:44am -0400,
Ryan Harper ry...@us.ibm.com wrote:
* Mike Snitzer snit...@redhat.com [2010-09-09 10:29]:
On Wed, Sep 01 2010 at 11:22pm -0400,
Mike Snitzer snit...@redhat.com wrote:
On Wed, Sep 01 2010
On 09/09/2010 04:03 AM, Liu Yu-B13201 wrote:
-Original Message-
From: kvm-ppc-ow...@vger.kernel.org
[mailto:kvm-ppc-ow...@vger.kernel.org] On Behalf Of Hollis Blanchard
Sent: Thursday, September 09, 2010 12:07 AM
To: Liu Yu-B13201
Cc: kvm@vger.kernel.org; kvm-...@vger.kernel.org;
On Thu, Sep 09 2010 at 12:03pm -0400,
Ryan Harper ry...@us.ibm.com wrote:
* Mike Snitzer snit...@redhat.com [2010-09-09 10:58]:
I'm using virtio-blk w/ cache=none for the root device. virtio-blk
isn't used for any other devices in the guest.
And you don't have any other disks in the
On 09/09/2010 04:16 AM, Liu Yu-B13201 wrote:
Yes, it's hard to resume TLB0. We only resume TLB1 in previous code.
But TLB1 is even more smaller (13 free entries) than 440,
So that it still has little possibility to get hit.
thus the resumption is useless.
The only reason hits are unlikely in
* Mike Snitzer snit...@redhat.com [2010-09-09 12:56]:
On Thu, Sep 09 2010 at 12:03pm -0400,
Ryan Harper ry...@us.ibm.com wrote:
* Mike Snitzer snit...@redhat.com [2010-09-09 10:58]:
I'm using virtio-blk w/ cache=none for the root device. virtio-blk
isn't used for any other devices
On Thu, Sep 09 2010 at 2:35pm -0400,
Ryan Harper ry...@us.ibm.com wrote:
* Mike Snitzer snit...@redhat.com [2010-09-09 12:56]:
I have verified that I no longer get the hang if I switch the root
device from virtio to ide.
And in the failing case, do you see:
/sys/block/vda/serial
On Thu, Sep 09 2010 at 3:15pm -0400,
Mike Snitzer snit...@redhat.com wrote:
On Thu, Sep 09 2010 at 2:35pm -0400,
Ryan Harper ry...@us.ibm.com wrote:
* Mike Snitzer snit...@redhat.com [2010-09-09 12:56]:
I have verified that I no longer get the hang if I switch the root
device from
On Thu, Sep 09, 2010 at 12:06:44PM +0200, jes.soren...@redhat.com wrote:
From: Jes Sorensen jes.soren...@redhat.com
Hi,
Discussed this with Juan and he spotted this place in
arch/x86/kernel/cpu/cpufreq/speedstep-lib.c which relies on the 'Core
Clock Frequency to System Bus Frequency
Anthony Liguori wrote:
On 08/31/2010 03:54 PM, Andrew Theurer wrote:
On Mon, 2010-08-23 at 16:27 -0500, Anthony Liguori wrote:
On 08/23/2010 04:16 PM, Andre Przywara wrote:
Anthony Liguori wrote:
On 08/23/2010 01:59 PM, Marcelo Tosatti wrote:
On Wed, Aug 11, 2010 at 03:52:18PM +0200,
On Thu, Sep 09 2010 at 3:43pm -0400,
Mike Snitzer snit...@redhat.com wrote:
Interestingly, just this loop:
while true ; do cat /sys/block/vda/serial date sleep 1 ; done
Thu Sep 9 15:29:30 EDT 2010
...
Thu Sep 9 15:31:19 EDT 2010
caused the following hang:
...
So it seems like the
* Mike Snitzer snit...@redhat.com [2010-09-09 15:15]:
On Thu, Sep 09 2010 at 3:43pm -0400,
Mike Snitzer snit...@redhat.com wrote:
Interestingly, just this loop:
while true ; do cat /sys/block/vda/serial date sleep 1 ; done
Thu Sep 9 15:29:30 EDT 2010
...
Thu Sep 9 15:31:19
On Wednesday 08 September 2010 21:14:39 matthew.r.roh...@l-3com.com wrote:
When trying to use vhost I get the error vhost-net requested but
could
not be initialized. The only thing I have been able to find about
this
problem relates to SElinux being turned off which mine is
On Thu, Sep 09 2010 at 4:30pm -0400,
Ryan Harper ry...@us.ibm.com wrote:
* Mike Snitzer snit...@redhat.com [2010-09-09 15:15]:
On Thu, Sep 09 2010 at 3:43pm -0400,
Mike Snitzer snit...@redhat.com wrote:
Interestingly, just this loop:
while true ; do cat /sys/block/vda/serial
On Thu, Sep 09, 2010 at 05:00:42PM -0400, Mike Snitzer wrote:
diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index 1260628..831e75c 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -199,6 +199,7 @@ static int virtblk_get_id(struct gendisk
On 9/9/2010 2:45 AM, Krishna Kumar2 wrote:
Krishna Kumar2/India/IBM wrote on 09/08/2010 10:17:49 PM:
Some more results and likely cause for single netperf
degradation below.
Guest - Host (single netperf):
I am getting a drop of almost 20%. I am trying to figure out
why.
Host - guest
On 08.09.2010, at 11:40, Liu Yu wrote:
Current guest TLB1 is mapped to host TLB1.
As host kernel only provides 4K uncontinuous pages,
we have to break guest large mapping into 4K shadow mappings.
These 4K shadow mappings are then mapped into host TLB1 on fly.
As host TLB1 only has 13 free
On 09.09.2010, at 20:13, Hollis Blanchard wrote:
On 09/09/2010 04:16 AM, Liu Yu-B13201 wrote:
Yes, it's hard to resume TLB0. We only resume TLB1 in previous code.
But TLB1 is even more smaller (13 free entries) than 440,
So that it still has little possibility to get hit.
thus the
On 09/09/2010 04:26 PM, Alexander Graf wrote:
On 09.09.2010, at 20:13, Hollis Blanchard wrote:
On 09/09/2010 04:16 AM, Liu Yu-B13201 wrote:
Yes, it's hard to resume TLB0. We only resume TLB1 in previous code.
But TLB1 is even more smaller (13 free entries) than 440,
So that it still
On 10.09.2010, at 01:39, Hollis Blanchard wrote:
On 09/09/2010 04:26 PM, Alexander Graf wrote:
On 09.09.2010, at 20:13, Hollis Blanchard wrote:
On 09/09/2010 04:16 AM, Liu Yu-B13201 wrote:
Yes, it's hard to resume TLB0. We only resume TLB1 in previous code.
But TLB1 is even more
On 9/7/2010 9:41 AM, Venkateswararao Jujjuri (JV) wrote:
Bruno Cesar Ribas wrote:
On Thu, Aug 26, 2010 at 09:44:32AM -0700, Venkateswararao Jujjuri (JV) wrote:
Bruno Cesar Ribas wrote:
Hi,
[snip]
This quick test is with QEMU patches that are on mailing lists but not merged
into mainline.
-Original Message-
From: Hollis Blanchard [mailto:hollis_blanch...@mentor.com]
Sent: Friday, September 10, 2010 12:23 AM
To: Liu Yu-B13201
Cc: kvm@vger.kernel.org; kvm-...@vger.kernel.org; ag...@suse.de
Subject: Re: [PATCH 0/2] kvm/e500v2: MMU optimization
Hi
On Thu, 9 Sep 2010 11:19:33 pm Krishna Kumar2 wrote:
Rusty Russell ru...@rustcorp.com.au wrote on 09/09/2010 05:44:25 PM:
Ah, good point. Move the queue index into the struct virtqueue?
Is it OK to move the queue_index from virtio_pci_vq_info
to virtqueue? I didn't want to change any data
From: Michael S. Tsirkin m...@redhat.com
Date: Mon, 6 Sep 2010 14:36:06 +0300
The following tree includes more regression fixes for vhost-net
in 2.6.36. It is on top of net-2.6.
Please merge it for 2.6.36.
Pulled, thanks Michael.
--
To unsubscribe from this list: send the line unsubscribe
Sridhar Samudrala s...@us.ibm.com wrote on 09/10/2010 04:30:24 AM:
I remember seeing similar issue when using a separate vhost thread for
TX and
RX queues. Basically, we should have the same vhost thread process a
TCP flow
in both directions. I guess this allows the data and ACKs to be
-Original Message-
From: kvm-ppc-ow...@vger.kernel.org
[mailto:kvm-ppc-ow...@vger.kernel.org] On Behalf Of Hollis Blanchard
Sent: Thursday, September 09, 2010 12:07 AM
To: Liu Yu-B13201
Cc: k...@vger.kernel.org; kvm-ppc@vger.kernel.org; ag...@suse.de
Subject: Re: [PATCH 0/2]
-Original Message-
From: Hollis Blanchard [mailto:hollis_blanch...@mentor.com]
Sent: Thursday, September 09, 2010 12:07 AM
To: Liu Yu-B13201
Cc: k...@vger.kernel.org; kvm-ppc@vger.kernel.org; ag...@suse.de
Subject: Re: [PATCH 1/2] kvm/e500v2: Remove shadow tlb
On 09/08/2010
On 09/09/2010 04:03 AM, Liu Yu-B13201 wrote:
-Original Message-
From: kvm-ppc-ow...@vger.kernel.org
[mailto:kvm-ppc-ow...@vger.kernel.org] On Behalf Of Hollis Blanchard
Sent: Thursday, September 09, 2010 12:07 AM
To: Liu Yu-B13201
Cc: k...@vger.kernel.org; kvm-ppc@vger.kernel.org;
On 09/09/2010 04:16 AM, Liu Yu-B13201 wrote:
Yes, it's hard to resume TLB0. We only resume TLB1 in previous code.
But TLB1 is even more smaller (13 free entries) than 440,
So that it still has little possibility to get hit.
thus the resumption is useless.
The only reason hits are unlikely in
On 08.09.2010, at 11:40, Liu Yu wrote:
Current guest TLB1 is mapped to host TLB1.
As host kernel only provides 4K uncontinuous pages,
we have to break guest large mapping into 4K shadow mappings.
These 4K shadow mappings are then mapped into host TLB1 on fly.
As host TLB1 only has 13 free
On 09.09.2010, at 20:13, Hollis Blanchard wrote:
On 09/09/2010 04:16 AM, Liu Yu-B13201 wrote:
Yes, it's hard to resume TLB0. We only resume TLB1 in previous code.
But TLB1 is even more smaller (13 free entries) than 440,
So that it still has little possibility to get hit.
thus the
On 09/09/2010 04:26 PM, Alexander Graf wrote:
On 09.09.2010, at 20:13, Hollis Blanchard wrote:
On 09/09/2010 04:16 AM, Liu Yu-B13201 wrote:
Yes, it's hard to resume TLB0. We only resume TLB1 in previous code.
But TLB1 is even more smaller (13 free entries) than 440,
So that it still
On 10.09.2010, at 01:39, Hollis Blanchard wrote:
On 09/09/2010 04:26 PM, Alexander Graf wrote:
On 09.09.2010, at 20:13, Hollis Blanchard wrote:
On 09/09/2010 04:16 AM, Liu Yu-B13201 wrote:
Yes, it's hard to resume TLB0. We only resume TLB1 in previous code.
But TLB1 is even more
-Original Message-
From: Hollis Blanchard [mailto:hollis_blanch...@mentor.com]
Sent: Friday, September 10, 2010 12:23 AM
To: Liu Yu-B13201
Cc: k...@vger.kernel.org; kvm-ppc@vger.kernel.org; ag...@suse.de
Subject: Re: [PATCH 0/2] kvm/e500v2: MMU optimization
Hi
53 matches
Mail list logo
