From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: VMEXIT and Threads Date: Mon, 6 Oct 2014 16:07:16 -0300 Message-ID: <20141006190716.GA5731@amt.cnet> References: <54321E64.8070306@softlab.cs.tsukuba.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org To: Oscar Garcia Return-path: Received: from mx1.redhat.com ([209.132.183.28]:52111 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753011AbaJFTHh (ORCPT ); Mon, 6 Oct 2014 15:07:37 -0400 Content-Disposition: inline In-Reply-To: <54321E64.8070306@softlab.cs.tsukuba.ac.jp> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, Oct 06, 2014 at 01:45:24PM +0900, Oscar Garcia wrote: > Hello, > > I have a question about parallel vmexit calls, I would appreciate > any answer or suggestion. > > I have a host with debian 7 (intel i7 - RAM 8GB), the guest OS is > also debian. I am running a program with some threads, every thread > makes a vmexit call. How is that vmexit call made? > Also every thread runs in a isolated vcpu. The > problem is that the program does not run fluently, it looks like > that every thread interfere with each other. Can you be more precise about this? Did you perform a measurement? > This situation does not happen when separately processes call vmexit > simultaneously. The question is: there is any restriction (any lock) > that block the threads. I am not sure maybe libc, RCU, on even Qemu > and KVM? In QEMU there is a mutex which is shared by all vcpus, and is acquired right after entry in QEMU, named qemu_mutex.