From patchwork Fri Jul 3 15:11:42 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Peter Maydell X-Patchwork-Id: 50638 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-wg0-f71.google.com (mail-wg0-f71.google.com [74.125.82.71]) by ip-10-151-82-157.ec2.internal (Postfix) with ESMTPS id 8BD7B22916 for ; Fri, 3 Jul 2015 15:12:08 +0000 (UTC) Received: by wgfk9 with SMTP id k9sf31113382wgf.1 for ; Fri, 03 Jul 2015 08:12:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:delivered-to:from:to:cc:subject :date:message-id:in-reply-to:references:x-original-sender :x-original-authentication-results:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-unsubscribe; bh=CI0gKAZjbCuytvWHGMoLJ50V1PNbN9yHaIIfTR9b9Q0=; b=CRfCZszPJwGXvR+ZShqCthfXv0giGJYg6r8SMe51yik+2B9vhjGoKenihjHesP9UNV qtFnRmcx8JAoApU957jbiyeXn3m0GUwECy74myVb830eDLVuTmY66pwc21eY8TNiSckf H+O2O3GKvpVlIawSv/UXP/0GUCSrknqksjkEuxWhaEqmRKD7/AEhR2uK3UH+s7EOBpe3 P8KI3PTCx+3GVReQp1fBVRCgnLAkPQCR+YAlNd3NXXKVhJ1bsL+4Ls9NI//AFF2RLdFq tNFqTmOEGk43Fik4G5P7h7VjIPrmTEhl3Y8hgBAB/GyxDE+tQOIb7s8LC5vO/ya47Duc oWTA== X-Gm-Message-State: ALoCoQk5VO/0r+bx8z1IPKNLVsBCjP/WJUIgDvycna24zdw7Xao2Kur7YB4C7itLdDlLnwbc3BM/ X-Received: by 10.181.5.7 with SMTP id ci7mr3937936wid.1.1435936327872; Fri, 03 Jul 2015 08:12:07 -0700 (PDT) MIME-Version: 1.0 X-BeenThere: patchwork-forward@linaro.org Received: by 10.152.36.136 with SMTP id q8ls543889laj.91.gmail; Fri, 03 Jul 2015 08:12:07 -0700 (PDT) X-Received: by 10.152.203.162 with SMTP id kr2mr36505581lac.57.1435936327707; Fri, 03 Jul 2015 08:12:07 -0700 (PDT) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com. [209.85.215.51]) by mx.google.com with ESMTPS id h4si7430974lbm.158.2015.07.03.08.12.07 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Jul 2015 08:12:07 -0700 (PDT) Received-SPF: pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.215.51 as permitted sender) client-ip=209.85.215.51; Received: by lagh6 with SMTP id h6so88680620lag.2 for ; Fri, 03 Jul 2015 08:12:07 -0700 (PDT) X-Received: by 10.112.160.165 with SMTP id xl5mr36263226lbb.36.1435936327553; Fri, 03 Jul 2015 08:12:07 -0700 (PDT) X-Forwarded-To: patchwork-forward@linaro.org X-Forwarded-For: patch@linaro.org patchwork-forward@linaro.org Delivered-To: patches@linaro.org Received: by 10.112.108.230 with SMTP id hn6csp94401lbb; Fri, 3 Jul 2015 08:12:06 -0700 (PDT) X-Received: by 10.66.181.197 with SMTP id dy5mr56203805pac.87.1435936311648; Fri, 03 Jul 2015 08:11:51 -0700 (PDT) Received: from mnementh.archaic.org.uk (mnementh.archaic.org.uk. [2001:8b0:1d0::1]) by mx.google.com with ESMTPS id pm11si14803457pdb.55.2015.07.03.08.11.49 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 03 Jul 2015 08:11:51 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of pm215@archaic.org.uk designates 2001:8b0:1d0::1 as permitted sender) client-ip=2001:8b0:1d0::1; Received: from pm215 by mnementh.archaic.org.uk with local (Exim 4.80) (envelope-from ) id 1ZB2cx-0003zv-CK; Fri, 03 Jul 2015 16:11:43 +0100 From: Peter Maydell To: qemu-devel@nongnu.org Cc: patches@linaro.org, Paolo Bonzini , "Edgar E. Iglesias" Subject: [PATCH 2/3] cpu-exec.c: Clarify comment about cpu_reload_memory_map()'s RCU operations Date: Fri, 3 Jul 2015 16:11:42 +0100 Message-Id: <1435936303-15335-3-git-send-email-peter.maydell@linaro.org> X-Mailer: git-send-email 1.7.10.4 In-Reply-To: <1435936303-15335-1-git-send-email-peter.maydell@linaro.org> References: <1435936303-15335-1-git-send-email-peter.maydell@linaro.org> X-Removed-Original-Auth: Dkim didn't pass. X-Original-Sender: peter.maydell@linaro.org X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.215.51 as permitted sender) smtp.mail=patch+caf_=patchwork-forward=linaro.org@linaro.org Precedence: list Mailing-list: list patchwork-forward@linaro.org; contact patchwork-forward+owners@linaro.org List-ID: X-Google-Group-Id: 836684582541 List-Post: , List-Help: , List-Archive: List-Unsubscribe: , The reason for cpu_reload_memory_map()'s RCU operations is not so much because the guest could make the critical section very long, but that it could have a critical section within which it made an arbitrary number of changes to the memory map and thus accumulate an unbounded amount of memory data structures awaiting reclamation. Clarify the comment to make this clearer. Signed-off-by: Peter Maydell --- This patch is as much to get confirmation from Paolo about whether I understand this as anything else :-) (Also, fixes the duplicate "as it"...) --- cpu-exec.c | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/cpu-exec.c b/cpu-exec.c index 2ffeb6e..d84c2cd 100644 --- a/cpu-exec.c +++ b/cpu-exec.c @@ -150,13 +150,21 @@ void cpu_reload_memory_map(CPUState *cpu) AddressSpaceDispatch *d; if (qemu_in_vcpu_thread()) { - /* Do not let the guest prolong the critical section as much as it - * as it desires. + /* The guest can in theory prolong the RCU critical section as long + * as it feels like. The major problem with this is that because it + * can do multiple reconfigurations of the memory map within the + * critical section, we could potentially accumulate an unbounded + * collection of memory data structures awaiting reclamation. * - * Currently, this is prevented by the I/O thread's periodinc kicking - * of the VCPU thread (iothread_requesting_mutex, qemu_cpu_kick_thread) - * but this will go away once TCG's execution moves out of the global - * mutex. + * Because the only thing we're currently protecting with RCU is the + * memory data structures, it's sufficient to break the critical section + * in this callback, which we know will get called every time the + * memory map is rearranged. + * + * (If we add anything else in the system that uses RCU to protect + * its data structures, we will need to implement some other mechanism + * to force TCG CPUs to exit the critical section, at which point this + * part of this callback might become unnecessary.) * * This pair matches cpu_exec's rcu_read_lock()/rcu_read_unlock(), which * only protects cpu->as->dispatch. Since we reload it below, we can