On 02/09/2011 04:11 PM, Jan Kiszka wrote:
The goal of this document shall be
- overview of all locks used in KVM core
- provide details on the scope of each lock
- explain the lock type, specifically of a raw spin locks
- provide a lock ordering guide
Start with one dependency chain and two
On 03/04/2011 12:34 AM, IVAN ANGELOV wrote:
Hello,
This provided dmesg message and kernel behavior appear when trying to
run qemu-kvm with kvm_amd module. Without kvm_amd qemu-kvm runs fine
but a slower. I managed to see that this happens with 2.6.38-rc6 ,
2.6.38-rc7 vanilla kernels compiled
On Sat, Mar 05, 2011 at 01:35:58PM -0300, Marcelo Tosatti wrote:
On Sat, Feb 26, 2011 at 01:29:01PM +0100, Jan Kiszka wrote:
at
/var/tmp/portage/app-emulation/qemu-kvm-0.14.0/work/qemu-kvm-0.14.0/qemu-kvm.c:1466
#12 0x777bb944 in start_thread () from /lib/libpthread.so.0
On 03/05/2011 06:35 PM, Marcelo Tosatti wrote:
Regarding global mutex, TCG and KVM execution behaviour can become more
similar wrt locking by dropping qemu_global_mutex during generation and
execution of TBs.
How can you do that? During generation, a device can assert the reset
line,
The RCU use in kvm_irqfd_deassign is tricky: we have rcu_assign_pointer
but no synchronize_rcu: synchronize_rcu is done by kvm_irq_routing_update
which we share a spinlock with.
Fix up a comment in an attempt to make this clearer.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
copy_from_user is pretty high on perf top profile,
replacing it with __copy_from_user helps.
It's also safe because we do access_ok checks during setup.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
drivers/vhost/vhost.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff
On 03/04/2011 01:00 PM, Xiao Guangrong wrote:
No need to record the gfn to verifier the pte has the same mode as
current vcpu, it's because we only speculatively update the pte only
if the pte and vcpu have the same mode
True. We can, as an additional cleanup, change mmu_pte_write_new_pte()
On 03/06/2011 02:14 PM, Avi Kivity wrote:
On 03/04/2011 01:00 PM, Xiao Guangrong wrote:
No need to record the gfn to verifier the pte has the same mode as
current vcpu, it's because we only speculatively update the pte only
if the pte and vcpu have the same mode
True. We can, as an
On 03/04/2011 01:00 PM, Xiao Guangrong wrote:
pte_prefetch_gfn_to_memslot and mapping_level_dirty_bitmap have the same
operation, so integrated
Signed-off-by: Xiao Guangrongxiaoguangr...@cn.fujitsu.com
---
arch/x86/kvm/mmu.c | 26 ++
1 files changed, 18
On 03/04/2011 01:02 PM, Xiao Guangrong wrote:
We can get memslot id from memslot-id directly
@@ -388,6 +387,12 @@ int kvm_gfn_to_hva_cache_init(struct kvm *kvm, struct
gfn_to_hva_cache *ghc,
int kvm_clear_guest_page(struct kvm *kvm, gfn_t gfn, int offset, int len);
int
On 03/04/2011 12:56 PM, Xiao Guangrong wrote:
Only remove write access in the last sptes
Thanks, applied patches 1, 3, 5, 6, 8, and 9.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to
On 03/06/2011 01:03 PM, Michael S. Tsirkin wrote:
The RCU use in kvm_irqfd_deassign is tricky: we have rcu_assign_pointer
but no synchronize_rcu: synchronize_rcu is done by kvm_irq_routing_update
which we share a spinlock with.
Fix up a comment in an attempt to make this clearer.
Applied,
On 03/05/2011 05:40 AM, Takuya Yoshikawa wrote:
From: Takuya Yoshikawayoshikawa.tak...@oss.ntt.co.jp
Access to this page is mostly done through the regs member which holds
the address to this page. The exceptions are in vmx_vcpu_reset() and
kvm_free_lapic() and these both can easily be
On Sat, Mar 05, 2011 at 10:40:08AM +0100, Francis Moreau wrote:
[ was post on LKML but try it here since it's more appropriate ]
Hello,
I'm running kernel 2.6.38-rc6 with qemu-kvm 0.12.3.
Doing this inside the guest:
int main(void)
{
if (ioperm(0x3e0, 4, 1) 0) {
On 03/06/2011 02:42 PM, Gleb Natapov wrote:
IO permission checking for 64-bit guest in KVM is wrong. The patch bellow
should fix it.
diff --git a/arch/x86/include/asm/kvm_emulate.h
b/arch/x86/include/asm/kvm_emulate.h
index 50ebc32..7ef5b86 100644
--- a/arch/x86/include/asm/kvm_emulate.h
+++
On Sun, Mar 06, 2011 at 02:55:17PM +0200, Avi Kivity wrote:
On 03/06/2011 02:42 PM, Gleb Natapov wrote:
IO permission checking for 64-bit guest in KVM is wrong. The patch bellow
should fix it.
diff --git a/arch/x86/include/asm/kvm_emulate.h
b/arch/x86/include/asm/kvm_emulate.h
index
On 03/05/2011 02:21 AM, Nikola Ciprich wrote:
Can you try this patch to see if it fixes the problem?
You haven't read my replies, did you? ;-)
kvm_request_guest_time_update seems to have been
removed, and kvm_make_request(KVM_REQ_CLOCK_UPDATE, vcpu)
seems to be used instead, adding it
On 03/06/2011 04:35 PM, Gleb Natapov wrote:
+ r = ops-read_std(base + 102,io_bitmap_ptr, 2, ctxt-vcpu, NULL);
if (r != X86EMUL_CONTINUE)
return false;
Note: if we get a fault here, we ought to propagate it. Only
happens if there's a race, since the cpu checks
On 03/06/2011 05:02 PM, Avi Kivity wrote:
(for #TS we need additional logic... will this arch never end?)
Actually these instructions don't generate #TS.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the
I did read your mail, but I was working on an old tree... because of
that transformation, this fix will unfortunately have to be back and
forward ported by hand.
OK, sorry, I didn't mean to be adverse...
Did you try just that change right applied on top of the patch
Hello,
Am 22.02.2010 um 22:26 schrieb Marcelo Tosatti:
Change the way the internal qemu signal, used for communication
between
iothread and vcpus, is handled.
Block and consume it with sigtimedwait on the outer vcpu loop, which
allows more precise timing control.
Mac OS X v10.5 does not
On 2011-03-06 18:46, Andreas Färber wrote:
Hello,
Am 22.02.2010 um 22:26 schrieb Marcelo Tosatti:
Change the way the internal qemu signal, used for communication between
iothread and vcpus, is handled.
Block and consume it with sigtimedwait on the outer vcpu loop, which
allows more
Hi
On Sun, Mar 6, 2011 at 1:42 PM, Gleb Natapov g...@redhat.com wrote:
On Sat, Mar 05, 2011 at 10:40:08AM +0100, Francis Moreau wrote:
IO permission checking for 64-bit guest in KVM is wrong. The patch bellow
should fix it.
Yes it fixes the reported issue. (BTW git complained that it adds
Hi list,
I'm not sure if this is the right list, but I have to ask for help on
some performance issues with KVM and Windows 2008 R2.
Windows guest is working properly on a clean install. But once some
applications get installed - especially MSSQL, but others as well -
system becomes pretty
On Sat, Mar 05, 2011 at 07:11:53PM +0100, Jan Kiszka wrote:
On 2011-03-05 16:37, Marcelo Tosatti wrote:
On Fri, Mar 04, 2011 at 11:20:00AM +0100, Jan Kiszka wrote:
KVM only requires to set the raised IRQ in CPUState and, if the user
space irqchip is used, to kick the receiving vcpu if it is
This patch breaks the support for x86 hardware breakpoints because
cpu_resume_from_signal() and raise_exception_env() are used in
breakpoint_handler().
--
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
From: Michael S. Tsirkin m...@redhat.com
Date: Sun, 6 Mar 2011 13:33:49 +0200
copy_from_user is pretty high on perf top profile,
replacing it with __copy_from_user helps.
It's also safe because we do access_ok checks during setup.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Is Rusty
On 03/04/2011 07:43 PM, Jan Kiszka wrote:
On 2011-03-04 11:58, Xiao Guangrong wrote:
fix:
[ 3494.671786] stack backtrace:
[ 3494.671789] Pid: 10527, comm: qemu-system-x86 Not tainted 2.6.38-rc6+ #23
[ 3494.671790] Call Trace:
[ 3494.671796] [8107d15f] ?
On 03/06/2011 12:48 AM, Marcelo Tosatti wrote:
On Fri, Mar 04, 2011 at 06:57:27PM +0800, Xiao Guangrong wrote:
Don not walk to the next level if spte is mapping to the large page
Signed-off-by: Xiao Guangrong xiaoguangr...@cn.fujitsu.com
---
arch/x86/kvm/mmu.c |3 ++-
1 files changed,
On 03/06/2011 08:16 PM, Avi Kivity wrote:
On 03/06/2011 02:14 PM, Avi Kivity wrote:
On 03/04/2011 01:00 PM, Xiao Guangrong wrote:
No need to record the gfn to verifier the pte has the same mode as
current vcpu, it's because we only speculatively update the pte only
if the pte and vcpu have
On 03/06/2011 08:28 PM, Avi Kivity wrote:
static int mapping_level(struct kvm_vcpu *vcpu, gfn_t large_gfn)
@@ -2155,9 +2166,8 @@ pte_prefetch_gfn_to_memslot(struct kvm_vcpu *vcpu,
gfn_t gfn, bool no_dirty_log)
{
struct kvm_memory_slot *slot;
-slot = gfn_to_memslot(vcpu-kvm,
Hi, all,
This is KVM test result against kvm.git
b35049715d619c9badaea07dec766787b433facf based kernel 2.6.38-rc6, and
qemu-kvm.git 27f368604a3d27ca4ddac0f62a6928bb93cdacd5.
No. 29232 bug VT-d device passthrough fail to guest has been fixed.
There's a new bug about NIC assignment. NIC doesn't
On Sun, Mar 06, 2011 at 06:03:39PM -0800, David Miller wrote:
From: Michael S. Tsirkin m...@redhat.com
Date: Sun, 6 Mar 2011 13:33:49 +0200
copy_from_user is pretty high on perf top profile,
replacing it with __copy_from_user helps.
It's also safe because we do access_ok checks during
33 matches
Mail list logo
