On Tue, Jul 28, 2009 at 10:30 AM, Ryan Harper wrote:
> * Luk?? Doktor [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
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 o
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
Signed-off-by: Lucas Meneghel Rodrigues
---
client/tests/kvm/kvm_tests.cfg.sample |8 +++
client/tests/kvm/kvm_vm.
On Wednesday 29 July 2009 06:46:38 Bartlomiej Zolnierkiewicz wrote:
> From: Bartlomiej Zolnierkiewicz
> 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_injec
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 !defined(MADV_MERGABLE
On Tue, Jul 28, 2009 at 8:54 PM, Avi Kivity 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
From: Bartlomiej Zolnierkiewicz
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 initializer 'vcpu'
arch/x8
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 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
On 28.07.2009, at 23:24, Ben Sanders
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 SCSI drive with "-drive file=da
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 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 progra
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 Tue, Jul 28, 2009 at 11:15:19PM +0200, Alexander Graf wrote:
>
> On 28.07.2009, at 22:52, Glauber Costa 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 initiali
On 28.07.2009, at 22:52, Glauber Costa 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
becomes explicitly a
On 28.07.2009, at 22:52, Glauber Costa 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
becomes explicitly a
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 chang
On Tue, Jul 28, 2009 at 10:30 AM, Ryan Harper wrote:
> * Luk?? Doktor [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
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,
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
Index: kvm/arch/x86/kvm/mmu.c
=
Marcelo Tosatti wrote:
From: Izik Eidus
First check if the list is empty before attempting to look at list
entries.
Signed-off-by: Izik Eidus
Signed-off-by: Marcelo Tosatti
Index: kvm/arch/x86/kvm/mmu.c
===
--- kvm.orig/arch/x8
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
From: Izik Eidus
First check if the list is empty before attempting to look at list
entries.
Signed-off-by: Izik Eidus
Signed-off-by: Marcelo Tosatti
Index: kvm/arch/x86/kvm/mmu.c
===
--- kvm.orig/arch/x86/kvm/mmu.c
+++ kvm/arch/
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
Index: kvm/arch/x86/kvm/mmu.c
==
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 eve
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
---
fs/eventfd.c | 56 ++--
1 files changed,
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:
On Tue, Jul 28, 2009 at 09:51:26AM -0700, Jordan Justen wrote:
> On Tue, Jul 28, 2009 at 7:40 AM, Marcelo Tosatti 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 wi
On Mon, 27 Jul 2009 23:37:48 +0300
"Michael S. Tsirkin" 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 function
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
Date: Tue, 28 Jul 2009 19:14:26 +0300
Subject: [PATCH] kvm use
On Tue, Jul 28, 2009 at 7:40 AM, Marcelo Tosatti 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. This change
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
Date: Tue, 28 Jul 2009 19:14:26 +0300
Subject: [PATCH] kvm userspace: ksm support
rfc
This patch is not for inclusion just rfc.
Thanks.
>From 1297b86aa257100b3d819df9f9f0932bf4f7f49d Mon Sep 17 00:00:00 2001
From: Izik Eidus
Date: Tue, 28 Jul 2009 19:14:26 +0300
Subject: [PATCH] kvm userspace: ksm support
rfc for ksm support to kvm userpsace.
thanks
Signed-off-by: Izik Eidus
From: Julia Lawall
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 match that find
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
---
Here's the patch for 2.6.30.x (simply applie
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 just
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:
> > > - d
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
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*
de
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
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 w
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: b1_qemu_kvm_
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
B
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 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: b1_qemu_
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 (o
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
pr
On 07/28/2009 09:17 AM, Avi Kivity wrote:
I found out that doing kill -38 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 ioctl
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, otherwis
* Luk?? Doktor [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 one
of the fe
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
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.
> >
> > Sig
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 (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
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 somethi
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? Re
On Tue, Jul 28, 2009 at 02:03:10AM -0300, Lucas Meneghel Rodrigues wrote:
> On Thu, Jul 23, 2009 at 4:18 AM, Yolkfull Chow 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 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 allo
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
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:
58 matches
Mail list logo
