From: Avi Kivity a...@redhat.com
cpu_env-stopped is part of the cpu state that is implicitly cleared by reset.
kvm runs reset with all vcpus stopped, but the implicit clearing causes this
to fail.
Fix by moving -stopped out of the implicit clear area. Testcase is reboots
under smp.
On 07/28/2009 03:48 AM, Glauber Costa wrote:
On Mon, Jul 27, 2009 at 06:43:47PM +0300, Avi Kivity wrote:
On 07/22/2009 01:13 AM, Glauber Costa wrote:
qemu CPUState already provides stop and stopped states. And they
mean exactly that. There is no need for us to provide our own.
Hi,
Description:
kvm (on core 2 duo) freezes shortly after startup.
Additional info:
* package version(s)
kernel 2.6.21
qemu 0.9.1-1
* config and/or log files etc.
[redhat as guest]
dmesg:
kvm: guest NX capability removed
Steps to reproduce:
modprobe kvm-intel
[redhat]
qemu-kvm -hda new.qcow2
On Tue, Jul 28, 2009 at 11:47:43AM +0530, Haneef Syed wrote:
Hi,
Description:
kvm (on core 2 duo) freezes shortly after startup.
Additional info:
* package version(s)
kernel 2.6.21
qemu 0.9.1-1
Is this kvm that comes with 2.6.21 or kvm-88 compiled for kernel 2.6.21?
* config and/or
On Tue, Jul 28, 2009 at 09:17:05AM +0300, Avi Kivity wrote:
On 07/28/2009 03:48 AM, Glauber Costa wrote:
On Mon, Jul 27, 2009 at 06:43:47PM +0300, Avi Kivity wrote:
On 07/22/2009 01:13 AM, Glauber Costa wrote:
qemu CPUState already provides stop and stopped states. And they
mean
On 07/28/2009 09:24 AM, Gleb Natapov wrote:
What are backtraces of all threads when it happens?
I wasn't able to attach with gdb. But I thought you reproduced it?
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
--
To unsubscribe from this list:
On Tue, Jul 28, 2009 at 09:28:26AM +0300, Avi Kivity wrote:
On 07/28/2009 09:24 AM, Gleb Natapov wrote:
What are backtraces of all threads when it happens?
I wasn't able to attach with gdb. But I thought you reproduced it?
Glauber may be yes. Me not even tried :)
--
On 07/28/2009 09:29 AM, Gleb Natapov wrote:
On Tue, Jul 28, 2009 at 09:28:26AM +0300, Avi Kivity wrote:
On 07/28/2009 09:24 AM, Gleb Natapov wrote:
What are backtraces of all threads when it happens?
I wasn't able to attach with gdb. But I thought you reproduced it?
On Mon, Jul 27, 2009 at 03:05:40PM -0300, Glauber Costa wrote:
Hello, goodfellas
I'm seeing a strange problem in our much loved qemu-kvm.git
This bug shouldn't depend on qemu-kvm.git at all unless you are running
with no-kvm-irqchip. The only things that involved in APIC timer
calibration are
Hi,
why do we wait on condition variables with silly timeouts (both in
upstream as in qemu-kvm)? There used to be some qemu_aio_poll in
qemu-kvm, but it's no longer there, and upstream never had (unless I
missed something). Is this polling legacy now? Remove it?
Jan
signature.asc
Description:
On Tue, Jul 28, 2009 at 12:44:31PM +0930, Rusty Russell wrote:
On Mon, 27 Jul 2009 01:17:09 am Michael S. Tsirkin wrote:
This refactors find_vqs, making it more readable and robust, and fixing
two regressions from 2.6.30:
- double free_irq causing BUG_ON on device removal
- probe failure
On 07/28/2009 12:32 AM, Stephen Donnelly wrote:
What I don't understand is how to turn the host address returned from
mmap into a ram_addr_t to pass to pci_register_bar.
Memory must be allocated using the qemu RAM functions.
That seems to be the problem. The memory cannot be
On Tue, Jul 28, 2009 at 02:03:10AM -0300, Lucas Meneghel Rodrigues wrote:
On Thu, Jul 23, 2009 at 4:18 AM, Yolkfull Chowyz...@redhat.com wrote:
Hi Yaniv, following is the output from Windows guest:
---
Microsoft DiskPart version 6.0.6001
Copyright (C) 1999-2007 Microsoft Corporation.
On 07/28/2009 10:16 AM, Jan Kiszka wrote:
Hi,
why do we wait on condition variables with silly timeouts (both in
upstream as in qemu-kvm)? There used to be some qemu_aio_poll in
qemu-kvm, but it's no longer there, and upstream never had (unless I
missed something). Is this polling legacy now?
Avi Kivity wrote:
On 07/28/2009 10:16 AM, Jan Kiszka wrote:
Hi,
why do we wait on condition variables with silly timeouts (both in
upstream as in qemu-kvm)? There used to be some qemu_aio_poll in
qemu-kvm, but it's no longer there, and upstream never had (unless I
missed something). Is this
On (Mon) Jul 27 2009 [18:44:28], Anthony Liguori wrote:
Jamie Lokier wrote:
With multiple X servers, there can be more than one currently logged in user.
Same with multiple text consoles - that's more familiar.
Which one owns /dev/vmch3?
For a VMM, copy/paste should work with whatever
Yes, this looks more pythonish and actually better than my version. I'm
missing only one thing, extra_params += -mem-path /mnt/hugepage down
in configuration (see below).
This cause problem with predefined mount point, because it needs to be
the same in extra_params and python script.
Dne
On Sat, Jul 25, 2009 at 12:30:52PM -0300, Marcelo Tosatti wrote:
On Thu, Jul 23, 2009 at 04:34:13PM +0300, Michael S. Tsirkin wrote:
When adding a vector fails, the used counter should
not be incremented, otherwise on vector change we will
try to update the routing entry.
On Tue, Jul 28, 2009 at 09:33:05AM +0300, Gleb Natapov wrote:
On Mon, Jul 27, 2009 at 03:05:40PM -0300, Glauber Costa wrote:
Hello, goodfellas
I'm seeing a strange problem in our much loved qemu-kvm.git
This bug shouldn't depend on qemu-kvm.git at all unless you are running
with
* Luk?? Doktor ldok...@redhat.com [2009-07-28 08:22]:
Yes, this looks more pythonish and actually better than my version. I'm
missing only one thing, extra_params += -mem-path /mnt/hugepage down
in configuration (see below).
Don't we also need to inspect the qemu binary to determine if it's
On Tue, Jul 28, 2009 at 04:22:36PM +0300, Michael S. Tsirkin wrote:
On Sat, Jul 25, 2009 at 12:30:52PM -0300, Marcelo Tosatti wrote:
On Thu, Jul 23, 2009 at 04:34:13PM +0300, Michael S. Tsirkin wrote:
When adding a vector fails, the used counter should
not be incremented, otherwise on
On 07/28/2009 09:17 AM, Avi Kivity wrote:
I found out that doing kill -38your_pid makes it run again, so
we're likely
hanging somewhere while holding qemu_mutex. The state of the process
is D,
so we're holding qemu_mutex, and then calling something that can block.
Sounds like we call a vcpu
Amit Shah wrote:
Right; use virtio just as the transport and all the interesting
activity happens in userspaces. That was the basis with which I started.
I can imagine dbus doing the copy/paste, lock screen, etc. actions.
However for libguestfs, dbus isn't an option and they already have some
On Mon, Jul 27, 2009 at 06:44:28PM -0500, Anthony Liguori wrote:
It really suggests that you need _one_ vmchannel that's exposed to
userspace with a single userspace daemon that consumes it.
... or a more flexible API. I don't like having fixed /dev/vmch*
devices either.
A long time ago (on
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/12
Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/
Buildslave for this Build:
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/15
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 default_x86_64_debian_5_0 on
qemu-kvm.
Full details are available at:
http://buildbot.b1-systems.de/qemu-kvm/builders/default_x86_64_debian_5_0/builds/14
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_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/13
Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/
Buildslave for this Build:
On (Tue) Jul 28 2009 [12:44:31], Rusty Russell wrote:
On Mon, 27 Jul 2009 01:17:09 am Michael S. Tsirkin wrote:
This refactors find_vqs, making it more readable and robust, and fixing
two regressions from 2.6.30:
- double free_irq causing BUG_ON on device removal
- probe failure when vq
On Sun, Jul 26, 2009 at 05:23:51PM -0700, Jordan Justen wrote:
The bios will now reserve more memory via the E820 functions.
Note that the standard KVM BIOS will most likely not make use of
this expanded BIOS region. This change will synchronize
the BIOS INT15-E820 reservations to match
Richard W.M. Jones wrote:
On Mon, Jul 27, 2009 at 06:44:28PM -0500, Anthony Liguori wrote:
It really suggests that you need _one_ vmchannel that's exposed to
userspace with a single userspace daemon that consumes it.
... or a more flexible API. I don't like having fixed /dev/vmch*
On Tue, Jul 28, 2009 at 09:48:00AM -0500, Anthony Liguori wrote:
Richard W.M. Jones wrote:
On Mon, Jul 27, 2009 at 06:44:28PM -0500, Anthony Liguori wrote:
It really suggests that you need _one_ vmchannel that's exposed to
userspace with a single userspace daemon that consumes it.
On Tue, Jul 28, 2009 at 08:00:52PM +0530, Amit Shah wrote:
On (Tue) Jul 28 2009 [12:44:31], Rusty Russell wrote:
On Mon, 27 Jul 2009 01:17:09 am Michael S. Tsirkin wrote:
This refactors find_vqs, making it more readable and robust, and fixing
two regressions from 2.6.30:
- double
Richard W.M. Jones wrote:
On Tue, Jul 28, 2009 at 09:48:00AM -0500, Anthony Liguori wrote:
Dave Miller nacked that approach with a sledgehammer instead preferring
that we just use standard TCP/IP which is what led to the current
implementation using slirp.
I'm aware of that - I
kvm_notify_acked_irq does not check irq type, so that it sometimes
interprets msi vector as irq. As a result, ack notifiers are not
called, which typially hangs the guest. The fix is to track and
check irq type.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
Here's the patch for
From: Julia Lawall ju...@diku.dk
This code is not executed before file has been initialized to the result of
calling eventfd_fget. This function returns an ERR_PTR value in an error
case instead of NULL. Thus the test that file is not NULL is always true.
A simplified version of the semantic
This patch is not for inclusion just rfc.
Thanks.
From 1297b86aa257100b3d819df9f9f0932bf4f7f49d Mon Sep 17 00:00:00 2001
From: Izik Eidus iei...@redhat.com
Date: Tue, 28 Jul 2009 19:14:26 +0300
Subject: [PATCH] kvm userspace: ksm support
rfc for ksm support to kvm userpsace.
thanks
Izik Eidus wrote:
This patch is not for inclusion just rfc.
The madvise() interface looks really nice :-)
Thanks.
From 1297b86aa257100b3d819df9f9f0932bf4f7f49d Mon Sep 17 00:00:00 2001
From: Izik Eidus iei...@redhat.com
Date: Tue, 28 Jul 2009 19:14:26 +0300
Subject: [PATCH] kvm
On Tue, Jul 28, 2009 at 7:40 AM, Marcelo Tosattimtosa...@redhat.com wrote:
On Sun, Jul 26, 2009 at 05:23:51PM -0700, Jordan Justen wrote:
The bios will now reserve more memory via the E820 functions.
Note that the standard KVM BIOS will most likely not make use of
this expanded BIOS region.
Anthony Liguori wrote:
Izik Eidus wrote:
This patch is not for inclusion just rfc.
The madvise() interface looks really nice :-)
Thanks.
From 1297b86aa257100b3d819df9f9f0932bf4f7f49d Mon Sep 17 00:00:00 2001
From: Izik Eidus iei...@redhat.com
Date: Tue, 28 Jul 2009 19:14:26 +0300
On Mon, 27 Jul 2009 23:37:48 +0300
Michael S. Tsirkin m...@redhat.com wrote:
On Mon, Jul 27, 2009 at 09:14:23AM -0700, Greg KH wrote:
Fine with me. You forgot the documentation though :)
This enough?
pci: expose function reset capability in sysfs
Some devices allow an individual
On Tue, Jul 28, 2009 at 09:51:26AM -0700, Jordan Justen wrote:
On Tue, Jul 28, 2009 at 7:40 AM, Marcelo Tosattimtosa...@redhat.com wrote:
On Sun, Jul 26, 2009 at 05:23:51PM -0700, Jordan Justen wrote:
The bios will now reserve more memory via the E820 functions.
Note that the standard KVM
Davide, all,
This RFC series implements a new EFD_STATE flag for eventfd.
When set, this changes eventfd behaviour in the following way:
- write simply stores the value written, and is always non-blocking
- read unblocks when the value written changes, and
returns the value written
Motivation:
This slightly reorganizes the code in eventfd, encapsulating counter
math in inline functions, so that it will be easier to add a new flag.
No functional changes.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
fs/eventfd.c | 56 ++--
1
This implements a new EFD_STATE flag for eventfd.
When set, this flag changes eventfd behaviour in the following way:
- write simply stores the value written, and is always non-blocking
- read unblocks when the value written changes, and
returns the value written
Motivation: we'd like to use
Remove the bogus n_free_mmu_pages assignment from alloc_mmu_pages.
It breaks accounting of mmu pages, since n_free_mmu_pages is modified
but the real number of pages remains the same.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
Index: kvm/arch/x86/kvm/mmu.c
From: Izik Eidus iei...@redhat.com
First check if the list is empty before attempting to look at list
entries.
Signed-off-by: Izik Eidus iei...@redhat.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
Index: kvm/arch/x86/kvm/mmu.c
See patches for details.
--
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
Marcelo Tosatti wrote:
From: Izik Eidus iei...@redhat.com
First check if the list is empty before attempting to look at list
entries.
Signed-off-by: Izik Eidus iei...@redhat.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
Index: kvm/arch/x86/kvm/mmu.c
Marcelo Tosatti wrote:
Remove the bogus n_free_mmu_pages assignment from alloc_mmu_pages.
It breaks accounting of mmu pages, since n_free_mmu_pages is modified
but the real number of pages remains the same.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
Index: kvm/arch/x86/kvm/mmu.c
use cpuid code from upstream. By doing that, we lose the following snippet
in kvm_get_supported_cpuid():
ret |= 1 12; /* MTRR */
ret |= 1 16; /* PAT */
ret |= 1 7; /* MCE */
ret |= 1 14; /* MCA */
A quick search in mailing lists says this code is not really necessary, and
On Tue, Jul 28, 2009 at 10:30 AM, Ryan Harperry...@us.ibm.com wrote:
* Luk?? Doktor ldok...@redhat.com [2009-07-28 08:22]:
Yes, this looks more pythonish and actually better than my version. I'm
missing only one thing, extra_params += -mem-path /mnt/hugepage down
in configuration (see below).
Falling back to tcg has proven to be evil through time. The option is to
do not try to act behind user's back, and quit the program completely if
we fail to initialize kvm. Right now, the only way to run tcg from our tree
becomes explicitly asking for it, with the -no-kvm option.
But it will
On 28.07.2009, at 22:52, Glauber Costa glom...@redhat.com wrote:
Falling back to tcg has proven to be evil through time. The option
is to
do not try to act behind user's back, and quit the program
completely if
we fail to initialize kvm. Right now, the only way to run tcg from
our tree
On 28.07.2009, at 22:52, Glauber Costa glom...@redhat.com wrote:
Falling back to tcg has proven to be evil through time. The option
is to
do not try to act behind user's back, and quit the program
completely if
we fail to initialize kvm. Right now, the only way to run tcg from
our tree
On Tue, Jul 28, 2009 at 11:15:19PM +0200, Alexander Graf wrote:
On 28.07.2009, at 22:52, Glauber Costa glom...@redhat.com wrote:
Falling back to tcg has proven to be evil through time. The option is
to
do not try to act behind user's back, and quit the program completely
if
we fail to
Maybe my first announcement of it working was a bit premature. ESX is
indeed running on KVM, but is somewhat useless as I can't seem to add
a datastore (where ESX puts the virtual machine disks). I tried
adding a SCSI drive with -drive file=datastore.img,if=scsi but to no
avail. It seems that
On 28.07.2009, at 23:28, Glauber Costa glom...@redhat.com wrote:
On Tue, Jul 28, 2009 at 11:15:19PM +0200, Alexander Graf wrote:
On 28.07.2009, at 22:52, Glauber Costa glom...@redhat.com wrote:
Falling back to tcg has proven to be evil through time. The option
is
to
do not try to act
On 28.07.2009, at 23:24, Ben Sanders ben.m.sanders+...@gmail.com
wrote:
Maybe my first announcement of it working was a bit premature. ESX is
indeed running on KVM, but is somewhat useless as I can't seem to add
a datastore (where ESX puts the virtual machine disks). I tried
adding a
On 28.07.2009, at 23:28, Glauber Costa wrote:
On Tue, Jul 28, 2009 at 11:15:19PM +0200, Alexander Graf wrote:
On 28.07.2009, at 22:52, Glauber Costa glom...@redhat.com wrote:
Falling back to tcg has proven to be evil through time. The option
is
to
do not try to act behind user's back,
From: Bartlomiej Zolnierkiewicz bzoln...@gmail.com
Subject: [PATCH] kvm: remove superfluous NULL pointer check in
kvm_inject_pit_timer_irqs()
This takes care of the following entries from Dan's list:
arch/x86/kvm/i8254.c +714 kvm_inject_pit_timer_irqs(6) warning: variable
derefenced in
On Tue, Jul 28, 2009 at 8:54 PM, Avi Kivitya...@redhat.com wrote:
On 07/28/2009 12:32 AM, Stephen Donnelly wrote:
What I don't understand is how to turn the host address returned from
mmap into a ram_addr_t to pass to pci_register_bar.
Memory must be allocated using the qemu RAM functions.
Izik Eidus wrote:
You mean: when we later call for other madvise calls, if it will
remove the MADV_MERGEABLE from that memory?
if yes, the answer is no, it should be still l left in the
vma-vm_flags...
Excellent.
I'd suggest doing the following in osdep.h too:
#if
On Wednesday 29 July 2009 06:46:38 Bartlomiej Zolnierkiewicz wrote:
From: Bartlomiej Zolnierkiewicz bzoln...@gmail.com
Subject: [PATCH] kvm: remove superfluous NULL pointer check in
kvm_inject_pit_timer_irqs()
This takes care of the following entries from Dan's list:
arch/x86/kvm/i8254.c
This patch adds a small setup script to set up huge memory
pages during the kvm tests execution. Also, added hugepage setup to the
fc8_quick sample.
Signed-off-by: Lukáš Doktor ldok...@redhat.com
Signed-off-by: Lucas Meneghel Rodrigues l...@redhat.com
---
client/tests/kvm/kvm_tests.cfg.sample |
In order to make it easier to figure out problems and
also to avoid aborting tests prematurely due to
incompatible qemu options, keep record of supported
qemu options, and if extra options are passed to qemu,
verify if they are amongst the supported options. Also,
try to replace known misspelings
On Tue, Jul 28, 2009 at 10:30 AM, Ryan Harperry...@us.ibm.com wrote:
* Luk?? Doktor ldok...@redhat.com [2009-07-28 08:22]:
Yes, this looks more pythonish and actually better than my version. I'm
missing only one thing, extra_params += -mem-path /mnt/hugepage down
in configuration (see below).
On Tue, Jul 28, 2009 at 04:11:57PM +0800, Liu Yu-B13201 wrote:
On Sat, Jul 25, 2009 at 04:40:12PM +0800, Liu Yu wrote:
For example booke has a code template for
jumping to and returning from interrupt handlers:
bl transfer
.long handler_addr
.long ret_addr
when call
68 matches
Mail list logo
