On Fri, Mar 18, 2011 at 7:30 PM, Joerg Roedel wrote:
> Hi Ben,
>
> Can you try to run
>
> # perf record -a -g
>
> for a while when your VMs are up and unresponsive?
Hi Joerg,
Thanks for the response. Here's that output:
http://paste.ubuntu.com/582345/
Looks like it's spending all its time in k
Yan:
I have tested the newest balloon driver (from 1.1.16) on windows
server 2003, balloon.sys can not be installed successfully and return
error code 10. have you tested this or any updates? thanks.
Regards.
Green.
2010/2/15 Yan Vugenfirer :
> repository: C:/dev/kvm-guest-drivers-windows
On Fri, 2011-03-18 at 08:33 -0500, Herbert Xu wrote:
> Shirley Ma wrote:
> >
> > + /* Drop packet instead of stop queue for better performance
> */
>
> I would like to see some justification as to why this is the right
> way to go and not just papering over the real problem.
Fair. KVM gue
With this we can fail the test much earlier if a guest
kernel panic happens, instead of waiting for the full
timeout to complete.
Signed-off-by: Lucas Meneghel Rodrigues
---
client/tests/kvm/tests/unattended_install.py |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/clie
A method to verify guest kernel panics can be very
useful for a number of tests. Adapted from a function
present on virtio_console test, create VM.verify_kernel_crash()
and use it on unattended_install.
Changes from v1:
* According to mgoldish's comments, instead of using
read_nonblocking() and r
On Fri, Mar 18, 2011 at 4:06 PM, Guido Winkelmann
wrote:
> Am Wednesday 16 March 2011 schrieb Stefan Hajnoczi:
>> On Tue, Mar 15, 2011 at 1:20 PM, Guido Winkelmann
>>
>> wrote:
>> > Am Tuesday 15 March 2011 schrieben Sie:
>> >> On Mon, Mar 14, 2011 at 10:57 PM, Guido Winkelmann
>> >>
>> >> wrote
On Fri, 2011-03-18 at 15:15 +0200, Michael S. Tsirkin wrote:
> Is this the local or remote throughput?
> With UDP_STREAM you are mostly interested in
> remote throughput, local one can be pretty high
> while most packets get dropped.
This is local throughput. Remote is called recv(netserver) data
Am Wednesday 16 March 2011 schrieb Stefan Hajnoczi:
> On Tue, Mar 15, 2011 at 1:20 PM, Guido Winkelmann
>
> wrote:
> > Am Tuesday 15 March 2011 schrieben Sie:
> >> On Mon, Mar 14, 2011 at 10:57 PM, Guido Winkelmann
> >>
> >> wrote:
> >> > On Monday 14 March 2011 20:32:23 Stefan Hajnoczi wrote:
Part 3 of the patch implements the following options for the 'configure' script.
--disable-hpet-driftfix
--enable-hpet-driftfix
Signed-off-by: Ulrich Obergfell
diff -up ./configure.orig3 ./configure
--- ./configure.orig3 2011-02-18 22:48:06.0 +0100
+++ ./configure 2011-03-13 12:43:4
Part 2 of the patch compensates loss of timer interrupts caused by ...
- delayed timer callback.
- interrupt coalescing (x86 only).
Lost timer interrupts are compensated by gradually injecting additional
interrupts during the subsequent timer intervals, starting at a rate of
one additional int
Part 1 of the patch implements the following QEMU command line option.
-hpet [device=none|present][,driftfix=none|slew]
Signed-off-by: Ulrich Obergfell
diff -up ./qemu-config.c.orig1 ./qemu-config.c
--- ./qemu-config.c.orig1 2011-02-18 22:48:06.0 +0100
+++ ./qemu-config.c 20
Hi,
By the beginning of February I posted an RFC regarding an approach to
alleviate time drift with HPET periodic timers.
Ref.: http://article.gmane.org/gmane.comp.emulators.kvm.devel/67346
http://lists.gnu.org/archive/html/qemu-devel/2011-02/msg00327.html
During the discussion it became
On Thursday, March 10, 2011 11:16:11 am Tom Lendacky wrote:
> On Thursday, March 10, 2011 09:34:22 am Michael S. Tsirkin wrote:
> > On Thu, Mar 10, 2011 at 09:23:42AM -0600, Tom Lendacky wrote:
> > > On Thursday, March 10, 2011 12:54:58 am Michael S. Tsirkin wrote:
> > > > On Wed, Mar 09, 2011 at 0
On Fri, 2011-03-18 at 11:24 +0100, Jan Kiszka wrote:
> On 2011-03-17 23:42, Glauber Costa wrote:
> > kvmclock presence can be signalled by two different flags. So for
> > device creation, we have to test for both.
> Patch is OK, but the subject's logic is inverted.
Indeed, should have said somethi
Shirley Ma wrote:
>
> + /* Drop packet instead of stop queue for better performance */
I would like to see some justification as to why this is the right
way to go and not just papering over the real problem.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PG
On Thu, Mar 17, 2011 at 09:13:08AM -0700, Greg KH wrote:
> On Thu, Mar 17, 2011 at 10:53:33AM +0200, Michael S. Tsirkin wrote:
> > irqfd in kvm used flush_work incorrectly:
> > it assumed that work scheduled previously can't run
> > after flush_work, but since kvm uses a non-reentrant
> > workqueue
On Thu, Mar 17, 2011 at 08:28:47PM -0700, Shirley Ma wrote:
> On Thu, 2011-03-17 at 08:18 -0700, Shirley Ma wrote:
> > On Thu, 2011-03-17 at 07:02 +0200, Michael S. Tsirkin wrote:
> > > So, this just tries to make sure there's enough space for
> > > max packet in the ring, if not - drop and return
On Fri, Mar 18, 2011 at 12:02 PM, Ben Nagy wrote:
> KVM commandline (using libvirt):
> LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin
> QEMU_AUDIO_DRV=none /usr/local/bin/kvm-snapshot -S -M pc-0.14
> -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name fb-0
> -u
Hi Ben,
On Fri, Mar 18, 2011 at 07:02:40PM +0700, Ben Nagy wrote:
> Here's some output from perf top while the system is locky:
>263832.00 46.3% delay_tsc
> [kernel.kallsyms]
>231491.00 40.7% __ticket_spin_trylock
> [kernel.kallsyms]
> 14609.00 2.6% native_read
From: Jan Kiszka
This allows to override the interrupt handling of QEMU in system mode.
KVM will make use of it to set a specialized handler.
Signed-off-by: Jan Kiszka
---
cpu-all.h | 14 +-
exec.c|4 +++-
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/cp
From: Jan Kiszka
KVM only requires to set the raised IRQ in CPUState and to kick the
receiving vcpu if it is remote. Installing a specialized handler allows
potential future changes to the TCG code path without risking KVM side
effects.
Signed-off-by: Jan Kiszka
---
kvm-all.c | 11 ++
From: Jan Kiszka
Both have only two lines in common, and we will convert the system
service into a callback which is of no use for user mode operation.
Signed-off-by: Jan Kiszka
CC: Riku Voipio
---
exec.c | 14 ++
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/e
Repost of the remaining three patches from part V. No functional
changes, I just updated the commit log for reflect their complete
rationale.
CC: Riku Voipio
Jan Kiszka (3):
Break up user and system cpu_interrupt implementations
Redirect cpu_interrupt to callback handler
kvm: Install speci
Hi,
We've been trying to debug a problem when bring up VMs on a 48 core
AMD machine (4 x Opteron 6128). After some investigation and some
helpful comments from #kvm, it appears that we hit a serious lock
contention issue at a certain point. We have enabled lockdep debugging
(had to increase MAX_LO
On Fri, Mar 18, 2011 at 11:18:40AM +0100, Jan Kiszka wrote:
> On 2011-03-15 21:12, Jan Kiszka wrote:
> > On 2011-03-15 18:10, Marcelo Tosatti wrote:
> >> On Tue, Mar 15, 2011 at 12:26:17PM +0100, Jan Kiszka wrote:
> >>> KVM only requires to set the raised IRQ in CPUState and to kick the
> >>> recei
On 2011-03-17 23:42, Glauber Costa wrote:
> kvmclock presence can be signalled by two different flags. So for
> device creation, we have to test for both.
Patch is OK, but the subject's logic is inverted.
Jan
>
> Signed-off-by: Glauber Costa
> ---
> hw/kvmclock.c |6 +-
> 1 files chan
On 2011-03-15 21:12, Jan Kiszka wrote:
> On 2011-03-15 18:10, Marcelo Tosatti wrote:
>> On Tue, Mar 15, 2011 at 12:26:17PM +0100, Jan Kiszka wrote:
>>> KVM only requires to set the raised IRQ in CPUState and to kick the
>>> receiving vcpu if it is remote.
>>>
>>> Signed-off-by: Jan Kiszka
>>> ---
27 matches
Mail list logo
