From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: VMEXIT and Threads Date: Mon, 06 Oct 2014 08:51:10 +0200 Message-ID: <54323BDE.6040309@redhat.com> References: <54321E64.8070306@softlab.cs.tsukuba.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit To: Oscar Garcia , kvm@vger.kernel.org Return-path: Received: from mail-wi0-f176.google.com ([209.85.212.176]:45057 "EHLO mail-wi0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750929AbaJFGvR (ORCPT ); Mon, 6 Oct 2014 02:51:17 -0400 Received: by mail-wi0-f176.google.com with SMTP id hi2so3550117wib.9 for ; Sun, 05 Oct 2014 23:51:16 -0700 (PDT) In-Reply-To: <54321E64.8070306@softlab.cs.tsukuba.ac.jp> Sender: kvm-owner@vger.kernel.org List-ID: Il 06/10/2014 06:45, Oscar Garcia ha scritto: > > 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. 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. 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? At the KVM level, _most_ VCPU ioctls can run concurrently because they only take a VCPU-level mutex. QEMU however will take a global mutex on each exit to userspace. What vmexits are these? Paolo