Avi Kivity wrote:
> On 10/04/2009 09:07 PM, Jan Kiszka wrote:
>>> btw, instead of adding a new ioctl, perhaps it makes sense to define a
>>> new KVM_VCPU_STATE structure that holds all current and future state
>>> (with generous reserved space), instead of separating state over a dozen
>>> ioctls.
On Fri, Oct 2, 2009 at 7:47 PM, Marcelo Tosatti wrote:
> On Fri, Oct 02, 2009 at 01:54:22PM +0200, James Brackinshaw wrote:
>> Hello,
>>
>> If I suspend and resume a guest under kvm, or I migrate it from one
>> host to another, I sometimes get a soft lockup.
>>
>> Is there a timer mode to prevent
On 10/05/2009 09:43 AM, Jan Kiszka wrote:
Avi Kivity wrote:
On 10/04/2009 09:07 PM, Jan Kiszka wrote:
btw, instead of adding a new ioctl, perhaps it makes sense to define a
new KVM_VCPU_STATE structure that holds all current and future state
(with generous reserved space), instead of
Marcelo Tosatti wrote:
[]
You should see min_delta_ns increase to a much smaller value, hopefully in
the 2000-1 range.
That's what I see:
Oct 4 16:13:09 paltus kernel: [boot]
Oct 5 12:35:51 paltus kernel: hrtimer: interrupt too slow, forcing clock min
delta to 1500 ns
Oct 5 12:47:29 pa
Update headers from linux 2.6.32-rc1, this mainly
adds irqfd which will make it easier to add vhost,
down the line. Also reduce code duplication by including
kvm_types.h instead of copying it.
Signed-off-by: Michael S. Tsirkin
---
kvm/include/linux/kvm.h| 131 +++
Linus, please find in
git://git.kernel.org/pub/scm/virt/kvm/kvm.git kvm-updates/2.6.32
some KVM fixes, most notably an EPT TLB fix on vcpu migration. Also
included is glue code for ksm. While KVM will work without this code,
any shared pages will be removed from the shadow page tables and un
On 10/04/2009 09:02 PM, Jan Kiszka wrote:
H, good point. Mind reverting 2/2 and applying this one instead?
Jan
->
KVM: x86: Rework guest single-step flag injection and filtering
Push TF and RF injection and filtering on guest single-stepping into the
vender get/set_rflags callbac
On 09/29/2009 03:58 PM, Michael Tokarev wrote:
Avi Kivity wrote:
On 09/29/2009 03:12 PM, Michael Tokarev wrote:
[]
The thing is that after some uptime, kvm
guest prints something like this:
hrtimer: interrupt too slow, forcing clock min delta to 461487495 ns
[]
What happens if you use hpet
On 09/29/2009 05:34 AM, Xu, Jiajun wrote:
Hi All,
This Weekly KVM Testing Report against lastest kvm.git
94252a58662dc4ca6191eac479efb40e0716865c and qemu-kvm.git
5cc3cfb6c2254483ae324da407a13307fe7355f3.
Qemu-kvm tree build issue is fixed by qemu commit
781774b38c90797add71d029b7fbee43200c66d
Push TF and RF injection and filtering on guest single-stepping into the
vender get/set_rflags callbacks. This makes the whole mechanism more
robust /wrt user space IOTCTL order and instruction emulations.
Signed-off-by: Jan Kiszka
---
arch/x86/include/asm/kvm_host.h |3 ++
arch/x86/kvm/x86
Avi Kivity wrote:
> On 10/05/2009 09:43 AM, Jan Kiszka wrote:
>> Avi Kivity wrote:
>>
>>> On 10/04/2009 09:07 PM, Jan Kiszka wrote:
>>>
> btw, instead of adding a new ioctl, perhaps it makes sense to define a
> new KVM_VCPU_STATE structure that holds all current and future state
>>>
On 10/05/2009 01:18 PM, Jan Kiszka wrote:
Avi Kivity wrote:
On 10/05/2009 09:43 AM, Jan Kiszka wrote:
Avi Kivity wrote:
On 10/04/2009 09:07 PM, Jan Kiszka wrote:
btw, instead of adding a new ioctl, perhaps it makes sense to define a
new KVM_VCPU_STATE structure t
On 09/30/2009 08:41 PM, Dietmar Maurer wrote:
I just think of common scenarios like 'maintanace mode', where all VM should
migrate to another host. A endless migrate task can make that fail.
For me, it is totally unclear what value I should set for 'max_downtime' to
avoid that behavior?
Avi Kivity wrote:
> On 10/05/2009 01:18 PM, Jan Kiszka wrote:
>> Avi Kivity wrote:
>>
>>> On 10/05/2009 09:43 AM, Jan Kiszka wrote:
>>>
Avi Kivity wrote:
> On 10/04/2009 09:07 PM, Jan Kiszka wrote:
>
>
>>> btw, instead of adding a new ioctl
On Tuesday, 29 September 2009 00:55:02 -0400,
Jim Paris wrote:
> > According to the tests that I was doing in guest with kernel with
> > support for virtio, shrinking works, but when trying to return to
> > the amount of initial memory, seems that it fails and I lose
> > connectivity by serial con
On 10/05/2009 02:18 PM, Jan Kiszka wrote:
True pointers are no go since we have to deal with compat code (31/32
bit userspace calling into a 64 bit kernel). Offsets into the state
structure are easier.
So current KVM_GET_DIRTY_LOG is broken in the compat case...
Yes, for big-endi
Avi Kivity wrote:
> On 10/05/2009 02:18 PM, Jan Kiszka wrote:
>>> True pointers are no go since we have to deal with compat code (31/32
>>> bit userspace calling into a 64 bit kernel). Offsets into the state
>>> structure are easier.
>>>
>> So current KVM_GET_DIRTY_LOG is broken in the compa
On Sat, 03 Oct 2009 12:04:57 +0200
Avi Kivity wrote:
> On 10/01/2009 11:13 PM, Luiz Capitulino wrote:
> >> If we're going to support the protocol for 0.12, I'd like to most of the
> >> code merged by the end of October.
> >>
> > Four weeks.. Not so much time, but let's try.
> >
> > Ther
On 10/05/2009 01:07 PM, Jan Kiszka wrote:
Push TF and RF injection and filtering on guest single-stepping into the
vender get/set_rflags callbacks. This makes the whole mechanism more
robust /wrt user space IOTCTL order and instruction emulations.
Applied, thanks.
--
error compiling commit
On 10/05/2009 02:42 PM, Jan Kiszka wrote:
Yes, for big-endian 32/64 and s390. There are some patches floating around.
Well, that's for fixing up the endianess of the bitmap itself. But the
problem with void * in compat code are their different sizes. And
GET_DIRTY_LOG solves this via pa
On Mon, Oct 05, 2009 at 02:17:30PM +0200, Avi Kivity wrote:
> On 09/30/2009 08:41 PM, Dietmar Maurer wrote:
>>
>> I just think of common scenarios like 'maintanace mode', where all VM should
>> migrate to another host. A endless migrate task can make that fail.
>>
>> For me, it is totally unclear
On 10/05/2009 03:04 PM, Glauber Costa wrote:
On Mon, Oct 05, 2009 at 02:17:30PM +0200, Avi Kivity wrote:
On 09/30/2009 08:41 PM, Dietmar Maurer wrote:
I just think of common scenarios like 'maintanace mode', where all VM should
migrate to another host. A endless migrate task can make
> We used to have a heuristic that said 'if an iteration transfers more
> pages than the previous iteration, we've stopped converging'. Why
> wouldn't that work?
This does not protect you from very long migration times.
- Dietmar
--
To unsubscribe from this list: send the line "unsubscribe kvm"
On 10/05/2009 04:01 PM, Dietmar Maurer wrote:
We used to have a heuristic that said 'if an iteration transfers more
pages than the previous iteration, we've stopped converging'. Why
wouldn't that work?
This does not protect you from very long migration times.
Well, if each iteratio
On 10/05/2009 02:43 PM, Luiz Capitulino wrote:
Are you using a standard json parser with your test script? That's an
additional validation.
I'm using Python's json module, but I could run one of the checkers
listed in the json's page for each test, before the Python's module
kicks in.
> Heuristics like number of pages, maybe. But since we don't export
> iteration information, we can't expect management tools to stop the
> guest if migration doesn't converge.
>
> I suppose it could issue a 'stop' after some amount of time (constant *
> memory size / bandwidth).
'bandwidth' is
> -Original Message-
> From: Avi Kivity [mailto:a...@redhat.com]
> Sent: Montag, 05. Oktober 2009 16:06
> To: Dietmar Maurer
> Cc: Glauber Costa; Anthony Liguori; kvm
> Subject: Re: migrate_set_downtime bug
>
> On 10/05/2009 04:01 PM, Dietmar Maurer wrote:
> >> We used to have a heuristi
> On 10/05/2009 04:01 PM, Dietmar Maurer wrote:
> >> We used to have a heuristic that said 'if an iteration transfers
> more
> >> pages than the previous iteration, we've stopped converging'. Why
> >> wouldn't that work?
> >>
> > This does not protect you from very long migration times.
> >
> >
>
On 10/05/2009 04:08 PM, Dietmar Maurer wrote:
Well, if each iteration transfers one page less than the previous one,
it doesn't.
So how long does a migration take in this scenario when you have a VM with 8GB
RAM?
At 1 Gbps, about 2 years.
--
error compiling committee.c: too many a
> We used to have a heuristic that said 'if an iteration transfers more
> pages than the previous iteration, we've stopped converging'. Why
> wouldn't that work?
I agree that this is the 'right' approach - but it is just too difficult to
detect that we are not 'converging', and it does not set a
The Buildbot has detected a new failure of default_x86_64_out_of_tree on
qemu-kvm.
Full details are available at:
http://buildbot.b1-systems.de/qemu-kvm/builders/default_x86_64_out_of_tree/builds/37
Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/
Buildslave for this Build: b1_qemu_kvm_1
The Buildbot has detected a new failure of disable_kvm_x86_64_debian_5_0 on
qemu-kvm.
Full details are available at:
http://buildbot.b1-systems.de/qemu-kvm/builders/disable_kvm_x86_64_debian_5_0/builds/86
Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/
Buildslave for this Build: b1_qemu_
The Buildbot has detected a new failure of default_i386_debian_5_0 on qemu-kvm.
Full details are available at:
http://buildbot.b1-systems.de/qemu-kvm/builders/default_i386_debian_5_0/builds/98
Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/
Buildslave for this Build: b1_qemu_kvm_2
Build
The Buildbot has detected a new failure of disable_kvm_i386_debian_5_0 on
qemu-kvm.
Full details are available at:
http://buildbot.b1-systems.de/qemu-kvm/builders/disable_kvm_i386_debian_5_0/builds/87
Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/
Buildslave for this Build: b1_qemu_kvm_
The Buildbot has detected a new failure of disable_kvm_i386_out_of_tree on
qemu-kvm.
Full details are available at:
http://buildbot.b1-systems.de/qemu-kvm/builders/disable_kvm_i386_out_of_tree/builds/35
Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/
Buildslave for this Build: b1_qemu_kv
The Buildbot has detected a new failure of default_i386_out_of_tree on qemu-kvm.
Full details are available at:
http://buildbot.b1-systems.de/qemu-kvm/builders/default_i386_out_of_tree/builds/35
Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/
Buildslave for this Build: b1_qemu_kvm_2
Buil
This new autotest module implements a benchmark for parallel
processing (SMP) systems. Besides the traditional benchmarking,
some sanity checks are made, in order to test effectively the
SMP implementation of virtual machines. So this module at
the same time is a regular benchmark, but it can be al
On Mon, Oct 05, 2009 at 04:09:43PM +0200, Dietmar Maurer wrote:
> > Heuristics like number of pages, maybe. But since we don't export
> > iteration information, we can't expect management tools to stop the
> > guest if migration doesn't converge.
> >
> > I suppose it could issue a 'stop' after so
On 10/05/2009 11:46 AM, Michael S. Tsirkin wrote:
Update headers from linux 2.6.32-rc1, this mainly
adds irqfd which will make it easier to add vhost,
down the line. Also reduce code duplication by including
kvm_types.h instead of copying it.
Signed-off-by: Michael S. Tsirkin
---
kvm/include/l
First of all, thanks for this client side module Chen. I believe it
might be interesting for quite a lot of people doing performance
testing.
Here are my remarks found during the review of your code:
On Mon, Sep 21, 2009 at 7:01 AM, Cao, Chen wrote:
> - Using NPB OpenMP implementaion.
>
> Change
Currently client/setup_modules.py has an undefined variable error
that was spot by Amos Kong , and a simple fix
was proposed. (see http://patchwork.test.kernel.org/patch/1315/)
It seems to me that in a previous refactor of setup_modules, some
code was moved but not all references were properly fix
Hi Amos, thanks for the fix! It is fine, but to avoid introducing
global statements, I've worked out another patch to fix that issue.
Also, there was another undefined variable lying around (base_path).
I've finished up the patch and sent it to the mailing list!
Cheers,
On Tue, Sep 22, 2009 at 11
Fix an undefined variable reference error inside
client/setup_modules.py - just remove code that wasn't
supposed to be there.
3rd try: After IRC chat and investigation, this is a
best fix than my previous patch that tried to accomplish
the same fix.
Signed-off-by: Lucas Meneghel Rodrigues
---
c
Here's what I had in mind.
-- John
On Mon, Oct 5, 2009 at 11:20 AM, John Admanski wrote:
>
> After some investigation and irc chat, it has become clear that this
> misbehaving chunk of code in _autotest_logging_handle_error is in fact an
> error; the patch that was applied in rev 3649 in subve
Hi Yolkfull! I've checked your patch, but it turns out that the comma
is valid syntax for the logging module. By any chance you actually had
an error with it?
On Mon, Sep 28, 2009 at 4:45 AM, Yolkfull Chow wrote:
>
> Signed-off-by: Yolkfull Chow
> ---
> client/tests/kvm/kvm_vm.py | 2 +-
> 1
Patchset applied!
On Tue, Sep 29, 2009 at 5:04 PM, Michael Goldish wrote:
> In get_command_status_output() and is_responsive() use read_nonblocking(0) to
> read the unread output before sending input (e.g. a command).
> The timeout is currently 0.1 because theoretically it should help if the gues
Patchset applied!
On Sun, Sep 20, 2009 at 12:16 PM, Michael Goldish wrote:
> The shell line separator string is appended to strings sent by sendline().
>
> The string is controlled by the parameter shell_linesep. It defaults to "\n".
>
> Signed-off-by: Michael Goldish
> ---
> client/tests/kvm/
On Mon, Oct 05, 2009 at 05:38:35PM +0200, Avi Kivity wrote:
> On 10/05/2009 11:46 AM, Michael S. Tsirkin wrote:
>> Update headers from linux 2.6.32-rc1, this mainly
>> adds irqfd which will make it easier to add vhost,
>> down the line. Also reduce code duplication by including
>> kvm_types.h inste
Addressing comments.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
So one can measure SMP overhead.
Signed-off-by: Marcelo Tosatti
Index: qemu-kvm-parallel-vmexit/kvm/user/test/x86/vmexit.c
===
--- qemu-kvm-parallel-vmexit.orig/kvm/user/test/x86/vmexit.c
+++ qemu-kvm-parallel-vmexit/kvm/user/test/x
Non-wait version of on_cpu.
Signed-off-by: Marcelo Tosatti
Index: qemu-kvm-parallel-vmexit/kvm/user/test/lib/x86/smp.c
===
--- qemu-kvm-parallel-vmexit.orig/kvm/user/test/lib/x86/smp.c
+++ qemu-kvm-parallel-vmexit/kvm/user/test/lib/
I've currently a HP DL 380 G6 server which I can use for some benchmarks
I want to share with you. Maybe someone find it interesting or usefull.
Both host and guest running Gentoo with kernel 2.6.31.1 (which is stable
2.6.31 update 1). The host have the following components:
2 x Intel Xeon CPU L55
I would like to know is there a plan for KVM to be supported under Windows(host
OS)? If yes, by when?
-Thanks
Abhishek
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
I am concerned about an apparent misencoding for ioctl KVM_SET_IRQCHIP
kvm/include/linux/kvm.h defines KVM_SET_IRQCHIP as
#define KVM_SET_IRQCHIP _IOR(KVMIO, 0x63, struct kvm_irqchip)
But the verb "SET" in the ioctl name would imply that the ioctl
encoding constructor should be _IOW,
Hi Marcelo!
Marcelo Tosatti wrote:
> On Fri, Oct 02, 2009 at 04:19:27PM -0400, Gregory Haskins wrote:
>> What: xinterface is a mechanism that allows kernel modules external to
>> the kvm.ko proper to interface with a running guest. It accomplishes
>> this by creating an abstracted interface which
Avi Kivity wrote:
> On 10/02/2009 10:19 PM, Gregory Haskins wrote:
>> What: xinterface is a mechanism that allows kernel modules external to
>> the kvm.ko proper to interface with a running guest. It accomplishes
>> this by creating an abstracted interface which does not expose any
>> private deta
Avi Kivity wrote:
> On 10/02/2009 10:19 PM, Gregory Haskins wrote:
>> This allows a scatter-gather approach to IO, which will be useful for
>> building high performance interfaces, like zero-copy and low-latency
>> copy (avoiding multiple calls to copy_to/from).
>>
>> The interface is based on the
This allows you to not specify the full path in the
config file, appends to the image dir.
Signed-off-by: David Huff
---
client/tests/kvm/kvm_vm.py | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/client/tests/kvm/kvm_vm.py b/client/tests/kvm/kvm_vm.py
index f
In order to resolve the question, 'how will the guest
operating system tell the host operating system that
the unattended install process finish', we took the
simple approach and created a simple socket communication
ack process: The test instantiates a server tcp socket
on port 12323, and waits du
Add inl(ACPI_PMTIMER_PORT) test.
Signed-off-by: Marcelo Tosatti
Index: qemu-kvm-parallel-vmexit/kvm/user/test/x86/vmexit.c
===
--- qemu-kvm-parallel-vmexit.orig/kvm/user/test/x86/vmexit.c
+++ qemu-kvm-parallel-vmexit/kvm/user/test/
For the purpose of developing the test, 2 operating systems
were used, Fedora 11 and Windows XP 32 bit. This patch adds
the unattended install files for each OS:
* Fedora 11: Fedora-11.ks
* Win XP: winnt.bat and winxp32.sif
Attention: Those files work great in case we use user mode
networking.
In order to make it possible to prepare the environment
for the guests installation, we have to:
* Prepare a boot floppy for both windows and linux.
The boot floppy contains the unattended file, and in
case of windows, it will also hold a program that
can send to the server a ACK message. For Kic
In order to accomodate the unattended install test,
some changes had to be made:
* Now cd isos and md5 sum values don't belong only
to the step file install only
* introduced the needed variables for the unattended
install test
* Created 2 test sets, winxp_unattended and fc11_unattended.
Signe
In order to make windows guests to tell the unattended install
server that the install process ended, a simple C++ program
using the winsock 2 API had to be developed. The program was
based on an MSDN article. Its usage is
finish.exe [host-ip]
The test expect this to be compiled under deps. This
Bugs item #2873263, was opened at 2009-10-06 10:30
Message generated for change (Tracker Item Submitted) made by kolobrod
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2873263&group_id=180599
Please note that this message will contain a full copy of the
65 matches
Mail list logo
