On 04/16/2010 09:12 PM, Lucas Meneghel Rodrigues wrote:
The VM screendump thread recently introduced generates
a lot of output on debug logs. Such output is not needed
most of the time (we are interested to see if a screenshot
production attempt failed though) and distracts the user
from
* Zhang, Yanmin yanmin_zh...@linux.intel.com wrote:
unsigned long perf_misc_flags(struct pt_regs *regs)
{
int misc = 0;
+
if (perf_guest_cbs perf_guest_cbs-is_in_guest()) {
+ if (perf_guest_cbs-is_user_mode())
+ misc |=
* Ingo Molnar mi...@elte.hu wrote:
* Zhang, Yanmin yanmin_zh...@linux.intel.com wrote:
unsigned long perf_misc_flags(struct pt_regs *regs)
{
int misc = 0;
+
if (perf_guest_cbs perf_guest_cbs-is_in_guest()) {
+ if (perf_guest_cbs-is_user_mode())
+
On Tue, 2010-04-20 at 08:09 +0200, Ingo Molnar wrote:
* Ingo Molnar mi...@elte.hu wrote:
* Zhang, Yanmin yanmin_zh...@linux.intel.com wrote:
unsigned long perf_misc_flags(struct pt_regs *regs)
{
int misc = 0;
+
if (perf_guest_cbs perf_guest_cbs-is_in_guest()) {
Marcelo Tosatti wrote:
On Mon, Apr 19, 2010 at 01:08:29PM +0300, Avi Kivity wrote:
On 04/19/2010 12:58 PM, Lai Jiangshan wrote:
Applied the patch I just sent and let CONFIG_PROVE_RCU=y,
we can got the following dmesg. And we found that it is
because some codes in KVM dereferences
On 04/19/2010 05:50 PM, Glauber Costa wrote:
On Sat, Apr 17, 2010 at 09:58:26PM +0300, Avi Kivity wrote:
On 04/15/2010 09:37 PM, Glauber Costa wrote:
Since we're changing the msrs kvmclock uses, we have to communicate
that to the guest, through cpuid. We can add a new KVM_CAP to the
On 04/19/2010 07:18 PM, Jeremy Fitzhardinge wrote:
On 04/19/2010 07:46 AM, Peter Zijlstra wrote:
What avi says! :-)
On a 32bit machine a 64bit read are two 32bit reads, so
last = last_value;
becomes:
last.high = last_value.high;
last.low = last_vlue.low;
(or the reverse of
On 04/20/2010 04:57 AM, Marcelo Tosatti wrote:
Marcelo can probably confirm it, but he has a nehalem with an appearently
very good tsc source. Even this machine warps.
It stops warping if we only write pvclock data structure once and forget it,
(which only updated tsc_timestamp once),
On 04/20/2010 06:32 AM, Sheng Yang wrote:
On Monday 19 April 2010 16:25:17 Avi Kivity wrote:
On 04/17/2010 09:12 PM, Avi Kivity wrote:
I think you were right the first time around.
Re-reading again (esp. the part about treatment of indirect NMI
vmexits), I think this was
On 04/19/2010 09:35 PM, Zachary Amsden wrote:
Sockets and boards too? (IOW, how reliable is TSC_RELIABLE)?
Not sure, IIRC we clear that when the TSC sync test fails, eg when we
mark the tsc clocksource unusable.
Worrying. By the time we detect this the guest may already have
gotten
Hi, this is the v2 of the moving dirty gitmaps to user space!
By this patch, I think everything we need becomes clear.
So we want to step forward to be ready for the final version in the
near future: of course, this is dependent on x86 and ppc asm issues.
BTW, by whom I can get ACK for ppc and
This patch introduces is_dirty member for each memory slot.
Using this member, we remove the dirty bitmap scan which is
done in the get_dirty_log function.
This also helps us when we move the dirty bitmaps to user space:
we don't have any good way to check the bitmaps in user space with
low cost,
We will change the vmalloc() and vfree() to do_mmap() and do_munmap()
later. This patch makes it easy and cleanup the code.
Signed-off-by: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
Signed-off-by: Fernando Luis Vazquez Cao ferna...@oss.ntt.co.jp
---
virt/kvm/kvm_main.c | 27
On 20.04.2010, at 12:53, Takuya Yoshikawa wrote:
Hi, this is the v2 of the moving dirty gitmaps to user space!
By this patch, I think everything we need becomes clear.
So we want to step forward to be ready for the final version in the
near future: of course, this is dependent on x86 and
We will replace copy_to_user() to copy_in_user() when we move
the dirty bitmaps to user space.
But sadly, we have copy_in_user() only for 64 bits architectures.
So this function should work as a wrapper to hide ifdefs from outside.
Once we get copy_in_user() for 32 bits architectures, we can
We are now using generic___set_le_bit() to make dirty bitmaps le.
Though this works well, we have to replace __set_bit() to appropriate
uaccess function to move dirty bitmaps to user space. So this patch
splits generic___set_le_bit() and prepares for that.
Signed-off-by: Takuya Yoshikawa
We move dirty bitmaps to user space.
- Allocation and destruction: we use do_mmap() and do_munmap().
The new bitmap space is twice longer than the original one and we
use the additional space for double buffering: this makes it
possible to update the active bitmap while letting the user
We can now export the addree of the bitmap created by do_mmap()
to user space. For the sake of this, we introduce a new API:
KVM_SWITCH_DIRTY_LOG: application can use this to trigger the
switch of the bitmaps and get the address of the bitmap which
has been used until now. This reduces the
On 20.04.2010, at 13:00, Takuya Yoshikawa wrote:
We are now using generic___set_le_bit() to make dirty bitmaps le.
Though this works well, we have to replace __set_bit() to appropriate
uaccess function to move dirty bitmaps to user space. So this patch
splits generic___set_le_bit() and
(2010/04/20 19:54), Alexander Graf wrote:
On 20.04.2010, at 12:53, Takuya Yoshikawa wrote:
Hi, this is the v2 of the moving dirty gitmaps to user space!
By this patch, I think everything we need becomes clear.
So we want to step forward to be ready for the final version in the
near future:
On 20.04.2010, at 13:02, Takuya Yoshikawa wrote:
We move dirty bitmaps to user space.
- Allocation and destruction: we use do_mmap() and do_munmap().
The new bitmap space is twice longer than the original one and we
use the additional space for double buffering: this makes it
On 20.04.2010, at 13:03, Takuya Yoshikawa wrote:
We can now export the addree of the bitmap created by do_mmap()
to user space. For the sake of this, we introduce a new API:
KVM_SWITCH_DIRTY_LOG: application can use this to trigger the
switch of the bitmaps and get the address of the
(2010/04/20 20:10), Alexander Graf wrote:
On 20.04.2010, at 13:02, Takuya Yoshikawa wrote:
We move dirty bitmaps to user space.
- Allocation and destruction: we use do_mmap() and do_munmap().
The new bitmap space is twice longer than the original one and we
use the additional space for
(2010/04/20 20:15), Alexander Graf wrote:
On 20.04.2010, at 13:03, Takuya Yoshikawa wrote:
We can now export the addree of the bitmap created by do_mmap()
to user space. For the sake of this, we introduce a new API:
KVM_SWITCH_DIRTY_LOG: application can use this to trigger the
switch of
On 20.04.2010, at 13:33, Takuya Yoshikawa wrote:
(2010/04/20 20:15), Alexander Graf wrote:
On 20.04.2010, at 13:03, Takuya Yoshikawa wrote:
We can now export the addree of the bitmap created by do_mmap()
to user space. For the sake of this, we introduce a new API:
(2010/04/20 20:33), Alexander Graf wrote:
-#define KVM_API_VERSION 12
+#define KVM_API_VERSION 13
Is there a way to keep both interfaces around for some time at least? I'd
prefer the API version not to change if not _really_ necessary.
To enable the new dirty mapping you could for example
Fernando, sorry I have changed some part of this series and forgot to
change your Signed-off-by to Cc for some parts.
So please give me any comments(objections) as replies to this mail thread.
Thanks,
Takuya
(2010/04/20 19:53), Takuya Yoshikawa wrote:
Hi, this is the v2 of the moving
On Tue, Apr 20, 2010 at 12:35:19PM +0300, Avi Kivity wrote:
On 04/20/2010 04:57 AM, Marcelo Tosatti wrote:
Marcelo can probably confirm it, but he has a nehalem with an appearently
very good tsc source. Even this machine warps.
It stops warping if we only write pvclock data structure once
Does this mean that virtio-blk supports all three combinations?
1. FLUSH that isn't a barrier
2. FLUSH that is also a barrier
3. Barrier that is not a flush
1 is good for fsync-like operations;
2 is good for journalling-like ordered operations.
3 sounds like it doesn't mean a
call agenda
- send out a bit earlier
- cancel call if no agenda
0.12.4
- expect when Anthony is back online
KVM Forum 2010
- call for papers is out...send in your proposals!
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More
On 04/20/2010 03:59 PM, Glauber Costa wrote:
Might be due to NMIs or SMIs interrupting the rdtsc(); ktime_get()
operation which establishes the timeline. We could limit it by
having a loop doing rdtsc(); ktime_get(); rdtsc(); and checking for
some bound, but it isn't worthwhile (and will
The assigned device interrupt work handler calls kvm_set_irq, which
can sleep, for example, waiting for the ioapic mutex, from irq disabled
section.
https://bugzilla.kernel.org/show_bug.cgi?id=15725
Fix by dropping assigned_dev_lock (and re-enabling interrupts)
before invoking kvm_set_irq for
On 04/20/2010 02:31 AM, Avi Kivity wrote:
btw, do you want this code in pvclock.c, or shall we keep it kvmclock
specific?
I think its a pvclock-level fix. I'd been hoping to avoid having
something like this, but I think its ultimately necessary.
J
--
To unsubscribe from this list: send
Mohammed Gamal wrote:
On Tue, Apr 20, 2010 at 12:54 AM, jvrao jv...@linux.vnet.ibm.com wrote:
Mohammed Gamal wrote:
On Tue, Apr 13, 2010 at 9:08 PM, jvrao jv...@linux.vnet.ibm.com wrote:
jvrao wrote:
Alexander Graf wrote:
On 12.04.2010, at 13:58, Jamie Lokier wrote:
Mohammed Gamal wrote:
On Tue, Apr 20, 2010 at 10:09:57AM +0800, Lai Jiangshan wrote:
Paul E. McKenney wrote:
On Mon, Apr 19, 2010 at 12:49:04PM +0300, Avi Kivity wrote:
On 04/19/2010 12:41 PM, Lai Jiangshan wrote:
The RCU/SRCU API have already changed for proving RCU usage.
I got the following dmesg when
On 04/20/2010 09:23 PM, Jeremy Fitzhardinge wrote:
On 04/20/2010 02:31 AM, Avi Kivity wrote:
btw, do you want this code in pvclock.c, or shall we keep it kvmclock
specific?
I think its a pvclock-level fix. I'd been hoping to avoid having
something like this, but I think its
On 04/20/2010 11:54 AM, Avi Kivity wrote:
On 04/20/2010 09:23 PM, Jeremy Fitzhardinge wrote:
On 04/20/2010 02:31 AM, Avi Kivity wrote:
btw, do you want this code in pvclock.c, or shall we keep it kvmclock
specific?
I think its a pvclock-level fix. I'd been hoping to avoid having
On Mon, Apr 19, 2010 at 05:41:23PM +0800, Lai Jiangshan wrote:
The RCU/SRCU API have already changed for proving RCU usage.
I got the following dmesg when PROVE_RCU=y because we used incorrect API.
This patch coverts rcu_deference() to srcu_dereference() or family API.
Hi Marcelo,
Thanks for the patch.
I put it into my kernel source tree and tested the freshly build kernel in my
testing environment. The problem is now - almost - gone. The only suspicious
message (ONE occurrence immediate after starting the Server 2008 R2 VM) in
syslog is now:
BUG:
On Tue, Apr 20, 2010 at 02:29:29PM +0800, Lai Jiangshan wrote:
Marcelo Tosatti wrote:
On Mon, Apr 19, 2010 at 01:08:29PM +0300, Avi Kivity wrote:
On 04/19/2010 12:58 PM, Lai Jiangshan wrote:
Applied the patch I just sent and let CONFIG_PROVE_RCU=y,
we can got the following dmesg. And we
Hi,
this is a follow-up to bug 2989366:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2989366group_id=180599
after extensive debugging with the guys on #kvm it turns out that the leak is
in the qemu-kvm userland process, in virtio-blk.
A summary of my setup is described in the bug
On 21.04.2010, at 00:29, Leszek Urbanski wrote:
Hi,
this is a follow-up to bug 2989366:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2989366group_id=180599
after extensive debugging with the guys on #kvm it turns out that the leak is
in the qemu-kvm userland process, in
On 04/19/2010 11:35 PM, Avi Kivity wrote:
On 04/20/2010 04:57 AM, Marcelo Tosatti wrote:
Marcelo can probably confirm it, but he has a nehalem with an
appearently
very good tsc source. Even this machine warps.
It stops warping if we only write pvclock data structure once and
forget it,
On 04/20/2010 09:42 AM, Jeremy Fitzhardinge wrote:
On 04/20/2010 11:54 AM, Avi Kivity wrote:
On 04/20/2010 09:23 PM, Jeremy Fitzhardinge wrote:
On 04/20/2010 02:31 AM, Avi Kivity wrote:
btw, do you want this code in pvclock.c, or shall we keep it kvmclock
specific?
* Leszek Urbanski tyg...@moo.pl [2010-04-20 17:37]:
Hi,
this is a follow-up to bug 2989366:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2989366group_id=180599
after extensive debugging with the guys on #kvm it turns out that the leak is
in the qemu-kvm userland process,
On Tue, Apr 20, 2010 at 8:36 PM, jvrao jv...@linux.vnet.ibm.com wrote:
... snip ...
This'd be something interesting to do. I wonder if that would fit in
the GSoC timeframe, or whether it'd be a little too short. So how long
you'd estimate something like that would take?
I think it would
46 matches
Mail list logo
