On 07/28/2011 07:44 PM, André Weidemann wrote:
Hi,
On 28.07.2011 15:49, Paolo Bonzini wrote:
On 07/28/2011 03:21 PM, Avi Kivity wrote:
I haven't used debuggers very much, so I hope I grabbed the correct
lines from the disassembly:
http://pastebin.com/t3sfvmTg
That's the bug check routine. Ca
On 27.07.2011 10:56, Gleb Natapov wrote:
On Tue, Jul 26, 2011 at 12:57:44PM +0200, André Weidemann wrote:
Hi,
On 26.07.2011 12:08, Gleb Natapov wrote:
On Tue, Jul 26, 2011 at 07:29:04AM +0200, André Weidemann wrote:
On 07.07.2011 07:26, André Weidemann wrote:
Hi,
I am running Windows7 x64 in
Hi Stefan
On 07/28/2011 11:44 PM, Stefan Hajnoczi wrote:
On Thu, Jul 28, 2011 at 3:29 PM, Liu Yuan wrote:
Did you investigate userspace virtio-blk performance? If so, what
issues did you find?
Yes, in the performance table I presented, virtio-blk in the user space
lags behind the vhost-blk
Hi
On 07/29/2011 12:48 PM, Stefan Hajnoczi wrote:
On Thu, Jul 28, 2011 at 4:44 PM, Stefan Hajnoczi wrote:
On Thu, Jul 28, 2011 at 3:29 PM, Liu Yuan wrote:
Did you investigate userspace virtio-blk performance? If so, what
issues did you find?
I have a hacked up world here that basically impl
2011/7/27 Nadav Har'El :
> On Wed, Jul 20, 2011, Zachary Amsden wrote about "Re: Nested VMX - L1 hangs
> on running L2":
>> > > No, both patches are wrong.
>> >
>>
>> kvm_get_msr(vcpu, MSR_IA32_TSC, &tsc) should always return the L1 TSC,
>> regardless of the setting of any MSR bitmap. The reason w
On Fri, Jul 29, 2011 at 8:22 AM, Liu Yuan wrote:
> Hi Stefan
> On 07/28/2011 11:44 PM, Stefan Hajnoczi wrote:
>>
>> On Thu, Jul 28, 2011 at 3:29 PM, Liu Yuan wrote:
>>
>> Did you investigate userspace virtio-blk performance? If so, what
>> issues did you find?
>>
>
> Yes, in the performance tabl
On Fri, Jul 29, 2011 at 05:01:16AM -0400, Zachary Amsden wrote:
> So you are right, this is still wrong for the case in which L1 does
> not trap TSC MSR reads. Note however, the RDTSC instruction is still
> virtualized properly, it is only the relatively rare actual TSC MSR
> read via RDMSR which
On Fri, Jul 29, 2011 at 03:59:53PM +0800, Liu Yuan wrote:
> I noted bdrv_aio_multiwrite() do the murging job, but I am not sure
Just like I/O schedulers it's actually fairly harmful on high IOPS,
low latency devices. I've just started doing a lot of qemu bencharks,
and disabling that multiwrite
https://bugzilla.kernel.org/show_bug.cgi?id=39412
Jay Ren changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugzilla.kernel.org/show_bug.cgi?id=39412
Jay Ren changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
--
Configure bugmail: https://bug
Hello!
On Thu, Jul 28, 2011 at 11:34, Avi Kivity wrote:
> Looks like you are blocked on disk. What does iostat say about disk
> utilization (in both guest and host)?
I also thought so, but host cpu states doesn't show any disk blocking.
iostat 5 with cache=none:
Guest:
avg-cpu: %user %nice %s
On 07/28/2011 10:47 PM, Christoph Hellwig wrote:
On Thu, Jul 28, 2011 at 10:29:05PM +0800, Liu Yuan wrote:
From: Liu Yuan
Vhost-blk driver is an in-kernel accelerator, intercepting the
IO requests from KVM virtio-capable guests. It is based on the
vhost infrastructure.
This is supposed to be a
On Thu, Jul 28, 2011 at 04:36:17AM -0400, Avi Kivity wrote:
> Architecturally, PDPTEs are cached in the PDPTRs when CR3 is reloaded.
> On SVM, it is not possible to implement this, but on VMX this is possible
> and was indeed implemented until nested SVM changed this to unconditionally
> read PDPTE
On Fri, Jul 29, 2011 at 09:20:35AM +0200, André Weidemann wrote:
> On 27.07.2011 10:56, Gleb Natapov wrote:
> >On Tue, Jul 26, 2011 at 12:57:44PM +0200, André Weidemann wrote:
> >>Hi,
> >>
> >>On 26.07.2011 12:08, Gleb Natapov wrote:
> >>>On Tue, Jul 26, 2011 at 07:29:04AM +0200, André Weidemann wr
Hi All,
This is KVM test result against kvm.git
e72ef590a3ef3047f6ed5bcb8808a9734f6c4b32 based on kernel 3.0.0+, and
qemu-kvm.git fda19064e889d4419dd3dc69ca8e6e7a1535fdf5.
We found no new bugs during the past two weeks.
We found 2 bugs got fixed. One fixed bug is about Win2k8 and Vista guest’s
On 07/29/2011 05:06 PM, Stefan Hajnoczi wrote:
I mean did you investigate *why* userspace virtio-blk has higher
latency? Did you profile it and drill down on its performance?
It's important to understand what is going on before replacing it with
another mechanism. What I'm saying is, if I have
On Fri, Jul 29, 2011 at 1:01 PM, Liu Yuan wrote:
> On 07/29/2011 05:06 PM, Stefan Hajnoczi wrote:
>>
>> I mean did you investigate *why* userspace virtio-blk has higher
>> latency? Did you profile it and drill down on its performance?
>>
>> It's important to understand what is going on before rep
I hit a weirdness yesterday, just want to mention it in case you notice it too.
When running vanilla qemu-kvm I forgot to use aio=native. When I
compared the results against virtio-blk-data-plane (which *always*
uses Linux AIO) I was surprised to find average 4k read latency was
lower and the sta
On 07/26/2011 06:25 AM, Avi Kivity wrote:
This patchset contains the core of the memory API, with one device
(usb-ohci) coverted for reference. The API is currently implemented on
top of the old ram_addr_t/cpu_register_physical_memory() API, but the plan
is to make it standalone later.
The goal
On 07/29/2011 08:50 PM, Stefan Hajnoczi wrote:
I hit a weirdness yesterday, just want to mention it in case you notice it too.
When running vanilla qemu-kvm I forgot to use aio=native. When I
compared the results against virtio-blk-data-plane (which *always*
uses Linux AIO) I was surprised to f
On 07/29/2011 10:45 PM, Liu Yuan wrote:
On 07/29/2011 08:50 PM, Stefan Hajnoczi wrote:
I hit a weirdness yesterday, just want to mention it in case you
notice it too.
When running vanilla qemu-kvm I forgot to use aio=native. When I
compared the results against virtio-blk-data-plane (which *al
On 07/28/2011 11:22 PM, Michael S. Tsirkin wrote:
On Thu, Jul 28, 2011 at 10:29:05PM +0800, Liu Yuan wrote:
From: Liu Yuan
Vhost-blk driver is an in-kernel accelerator, intercepting the
IO requests from KVM virtio-capable guests. It is based on the
vhost infrastructure.
This is supposed to be
On Fri, 2011-07-29 at 20:01 +0800, Liu Yuan wrote:
> Looking at this long list,most are function pointers that can not be
> inlined, and the internal data structures used by these functions are
> dozons. Leave aside code complexity, this long code path would really
> need retrofit. As Christoph
Hi Liu Yuan,
I am glad to see that you started looking at vhost-blk. I did an
attempt year ago to improve block
performance using vhost-blk approach.
http://lwn.net/Articles/379864/
http://lwn.net/Articles/382543/
I will take a closer look at your patchset to find differences and
similarit
Following patch deals with VCPU and iothread starvation during the migration of
a guest. Currently the iothread is responsible for performing the guest
migration. It holds qemu_mutex during the migration and doesn't allow VCPU to
enter the qemu mode and delays its return to the guest. The guest mig
This patch creates a separate thread for the guest migration on the source side.
Signed-off-by: Umesh Deshpande
---
buffered_file.c | 28 -
buffered_file.h |4 +++
migration.c | 59 +++---
migration.h |3
This patch creates a separate dirty bitmap for each slot. Currently dirty bitmap
is created for addresses ranging from 0 to the end address of the last memory
slot. Since the memslots are not necessarily contiguous, current bitmap might
contain empty region or holes that doesn't represent any VM pa
In the migration thread, qemu_mutex is released during the most time consuming
part. i.e. during is_dup_page which identifies the uniform data pages and during
the put_buffer. qemu_mutex is also released while blocking on select to wait for
the descriptor to become ready for writes.
Signed-off-by:
To even the latency, refill buffer right after being used.
Sign-off-by: Shirley Ma
---
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 0c7321c..c8201d4 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -429,6 +429,22 @@ static int add_recvbuf_mergeabl
Windows Server 2008 SP2 checked build with smp > 1 BSOD's during
boot due to lack of microcode update:
*** Assertion failed: The system BIOS on this machine does not properly
support the processor. The system BIOS did not load any microcode update.
A BIOS containing the latest microcode update i
Resubmit it with a typo fix.
Signed-off-by: Shirley Ma
---
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 0c7321c..c8201d4 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -429,6 +429,22 @@ static int add_recvbuf_mergeable(struct virtnet_info *vi,
Hi folks !
So I promised Anthony I would try to summarize some of the comments &
issues we have vs. VFIO after we've tried to use it for PCI pass-through
on POWER. It's pretty long, there are various items with more or less
impact, some of it is easily fixable, some are API issues, and we'll
proba
On Fri, Jul 29, 2011 at 3:55 PM, Shirley Ma wrote:
> Resubmit it with a typo fix.
>
> Signed-off-by: Shirley Ma
> ---
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 0c7321c..c8201d4 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -429,6
33 matches
Mail list logo
