On Thu, Oct 28, 2010 at 12:32:35PM -0700, Shirley Ma wrote:
On Thu, 2010-10-28 at 07:20 +0200, Michael S. Tsirkin wrote:
My concern is this can delay signalling for unlimited time.
Could you pls test this with guests that do not have
2b5bbe3b8bee8b38bdc27dd9c0270829b6eb7eeb
On Thu, Oct 28, 2010 at 10:14:22AM -0700, Shirley Ma wrote:
Two ideas:
1. How about writing out used, just delaying the signal?
This way we don't have to queue separately.
This improves some performance, but not as good as delaying
both used and signal. Since delaying used buffers
On Thu, Oct 28, 2010 at 02:40:50PM -0700, Shirley Ma wrote:
On Thu, 2010-10-28 at 14:04 -0700, Sridhar Samudrala wrote:
It would be some change in virtio-net driver that may have improved
the
latency of small messages which in turn would have reduced the
bandwidth
as TCP could not
On Thu, Oct 28, 2010 at 01:13:55PM -0700, Shirley Ma wrote:
On Thu, 2010-10-28 at 12:32 -0700, Shirley Ma wrote:
Also I found a big TX regression for old guest and new guest. For old
guest, I am able to get almost 11Gb/s for 2K message size, but for the
new guest kernel, I can only get 3.5
On Thu, Oct 28, 2010 at 12:48:57PM +0530, Krishna Kumar2 wrote:
Krishna Kumar2/India/IBM wrote on 10/28/2010 10:44:14 AM:
Results for UDP BW tests (unidirectional, sum across
3 iterations, each iteration of 45 seconds, default
netperf, vhosts bound to cpus 0-3; no other
To support VFIO based device assignment, we need to be able to get
an EOI out of the KVM irqchip. This introduces a mechanism to do
that by registering an eventfd to be signaled when the IRQ is ACKed.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
include/linux/kvm.h | 13
On Fri, 29 Oct 2010 13:26 +0200, Michael S. Tsirkin m...@redhat.com
wrote:
On Thu, Oct 28, 2010 at 12:48:57PM +0530, Krishna Kumar2 wrote:
Krishna Kumar2/India/IBM wrote on 10/28/2010 10:44:14 AM:
In practice users are very unlikely to pin threads to CPUs.
I may be misunderstanding what
For device assignment, we need to be able to retreive the IRQ that
the device interrupt pin is assigned to and be notified if that
mapping changes (this happens via ACPI interrupt link updates on
x86). We can then make use of the IRQ for EOI notification.
Current qemu-kvm device assignment code
On Fri, 2010-10-29 at 10:10 +0200, Michael S. Tsirkin wrote:
Hmm. I don't yet understand. We are still doing copies into the per-vq
buffer, and the data copied is really small. Is it about cache line
bounces? Could you try figuring it out?
per-vq buffer is much less expensive than 3
For VFIO based device assignment, we need to know what guest memory
areas are actual RAM. RAMBlocks have long since become a grab bag
of misc allocations, so aren't effective for this. Anthony has had
a RAM API in mind for a while now that addresses this problem. This
implements just enough of
This adds a minimum chunk of Anthony's RAM API support so that we
can identify actual VM RAM versus all the other things that make
use of qemu_ram_alloc.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
Makefile.target |1 +
cpu-common.h|2 +
memory.c| 82
Register the actual VM RAM using the new API
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
hw/pc.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/hw/pc.c b/hw/pc.c
index 69b13bf..0ea6d10 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -912,14 +912,14
Required for regions mapped via qemu_ram_alloc_from_ptr(). VFIO
will make use of this to remove mappings when devices are hot
unplugged. (Current callers of qemu_ram_alloc_from_ptr() should
probably need this too)
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
cpu-common.h |
This allows us to register an eventfd to be triggered on EOI for the
given IRQ.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
Userspace side of:
[PATCH] kvm: Create an eventfd mechanism for EOIs to get to userspace
kvm-all.c | 19 +++
kvm.h
For device assignment, we need to know when the VM writes an end
of interrupt to the APIC, which allows us to re-enable interrupts
on the physical device. Add a new wrapper for ioapic generated
interrupts with a callback on eoi and create an interface for
drivers to be notified on eoi.
With the KVM irqchip, we need to get the EOI via an eventfd. This
adds support for that, abstracting the details to the caller.
The get_fd function allows drivers to make further optimizations
in handling the EOI. For instance with VFIO, we can make use of
an irqfd-like mechanism to have the
On 10/29/2010 12:56 PM, Alex Williamson wrote:
For device assignment, we need to know when the VM writes an end
of interrupt to the APIC, which allows us to re-enable interrupts
on the physical device. Add a new wrapper for ioapic generated
interrupts with a callback on eoi and create an
On Fri, Oct 29, 2010 at 4:39 PM, Alex Williamson
alex.william...@redhat.com wrote:
This adds a minimum chunk of Anthony's RAM API support so that we
can identify actual VM RAM versus all the other things that make
use of qemu_ram_alloc.
Signed-off-by: Alex Williamson
On Fri, 2010-10-29 at 19:57 +, Blue Swirl wrote:
On Fri, Oct 29, 2010 at 4:39 PM, Alex Williamson
alex.william...@redhat.com wrote:
This adds a minimum chunk of Anthony's RAM API support so that we
can identify actual VM RAM versus all the other things that make
use of qemu_ram_alloc.
From: Xin, Xiaohui xiaohui@intel.com
Date: Wed, 27 Oct 2010 09:33:12 +0800
Somehow, it seems not a trivial work to support it now. Can we support it
later and as a todo with our current work?
I would prefer the feature work properly, rather than only in specific
cases, before being
Hi,
I have problem to compile qemu-kvm 0.13.0 with gcc version 4.1.2
20080704 (Red Hat 4.1.2-48) in CentOS 5. Errors below:
/usr/src/qemu-kvm-0.13.0/hw/ide/core.c: In function ‘ide_drive_pio_post_load’:
/usr/src/qemu-kvm-0.13.0/hw/ide/core.c:2782: warning: comparison is
always false due to
On Friday 29 October 2010, Sridhar Samudrala wrote:
Add support for 'mode' parameter when creating a macvtap device.
This allows a macvtap device to be created in bridge, private or
the default vepa modes.
Signed-off-by: Sridhar Samudrala s...@us.ibm.com
Acked-by: Arnd Bergmann
On Friday 29 October 2010, Sridhar Samudrala wrote:
With the current default 'vepa' mode, a KVM guest using virtio with
macvtap backend has the following limitations.
- cannot change/add a mac address on the guest virtio-net
I believe this could be changed if there is a neeed, but I actually
[ CCed VHOST contacts ]
On Thu, Oct 28, 2010 at 01:22:02PM -0700, Jesse Gross wrote:
On Thu, Oct 28, 2010 at 4:54 AM, Simon Horman ho...@verge.net.au wrote:
My reasoning is that in the non-mirroring case the guest is
limited by the external interface through wich the packets
eventually
24 matches
Mail list logo
