From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f73.google.com (mail-pj1-f73.google.com [209.85.216.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A9F5F2505AA for ; Thu, 7 Aug 2025 13:31:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.73 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754573465; cv=none; b=jTtDa7N0llluuAnHnrFq2SxptpKPlL+Q5D4CIZh9ah+jIh1rd4OIdEcUFDtfcybzKMrj4hngx3GoyDFtTM/uKPTPKyaL4HCtspIV7C9Jk/Ffwh3iYNXrEtJXyJeHXhYQIawFn37DxheQFsg1+YcHHPqVWy4NDO9/X1gCa2L5pyo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754573465; c=relaxed/simple; bh=d/kKAEtIIyJ0bQh3buKpp4Wr2OJkvH7JeyS+N3tuwHA=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=t+O5qU+f6cKWEVhxd9inus0+Wv0oxeGijLmrIHX/CRxynmowWw4QR6oibg9VeXnrDujmlK7P7ADh5s9WuJrSZKNZXEXK7UOGCwUKCxakSapf9VwxT2s03F1PzTXOG6hanEOlynijNQpi0rciDo2urUhewy4Ff6aL0NnCRJzWoyw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=U+acAYC0; arc=none smtp.client-ip=209.85.216.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="U+acAYC0" Received: by mail-pj1-f73.google.com with SMTP id 98e67ed59e1d1-31eac278794so1060875a91.3 for ; Thu, 07 Aug 2025 06:31:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1754573463; x=1755178263; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=m9K3KPRGz9FryMMa95mgTHuiYVPTsY16w0q5qkSOZls=; b=U+acAYC0VaVRvkWl+Tr/aexSzMYSVEz4HGuIiSsNB+np3rGNdpzaMcRjnCrZQ2VigH 3LQbvio3Xo1KP4UzIwYMt6MRX2k+d7qANQfl78fVqB+5EdlL1C+QfXjFVETvIAJ+Yhob W/aZe/jxoH4fm1EF0LHrepFbzUcaiaZ5hWHqFchOKrR60GA4KxXwul5IZEU1eDT6YV2Y TkepQWRDaNh5G6inC/FuEcBpjKWHjtK0N0GFf/i6jsk0SooLZ0uviM6CvRIgX/wgAtKo DgtXmWCP893VlAKqoREyjM9wM+vQ6BPWNX9J1MvYe/16m7cApcXDJw7e1h4dWzAR0eOe Szog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754573463; x=1755178263; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=m9K3KPRGz9FryMMa95mgTHuiYVPTsY16w0q5qkSOZls=; b=DDyqKbxSKHfolNzH06Hik3NsXCpxsNUmEHeOpoM61BrveXr93tzT43WTwCW7JLDDX6 6jJ5D7uZ9RrTHznvU+jmXs8zaWpu1rnKqlEG+e8GUQl6dJu8MrEwZeYrSxALUwpwDHs6 GEZLsJUCYcWwpgpkMJub21XkhmYUW3M7BnXpsqU5CvNcenXd9B21uPLebi/kbYXA1Qy4 TDEKM0PB7DjTxRp0koy3XJTRxCzHk73gVLQwCXCvRfOF0Gu4ffRuI0itC4PSTtC+jf8W CQ17GM/JyPDfh2b6Gh9yagRuiVMsZRGEP9pKKbxJlF+HiPSFnbjf3T9zxtO5RDct58t+ O/Xg== X-Forwarded-Encrypted: i=1; AJvYcCW6ndxB+rc08hr4KqMaRwCel/cMzzLCdfLpyRCDXfv4m/PZoN4y7DrpDLvyeeeLswyevgdEkDult7mA8ko=@vger.kernel.org X-Gm-Message-State: AOJu0Yzk34OR2UzVAgA/5CU48fHP7ztDrFAIS0cOtJ0gsxBbTYe5G4D1 EVeS02EO4E0GH9Y3W33TOhpHmKRlOrx50Q+8QpGkv5ROU5HNNUQlQd4kqlBEg/hJGjQ6b8F/Yo+ uTViZyg== X-Google-Smtp-Source: AGHT+IGVx/b9/DE76huBvcgdMopzzQiNlanWWyUNo4hp0Ku1LZFsRYEWrghOh2bi1IKsFzfcbKTDAkY9OZ4= X-Received: from pjbnw14.prod.google.com ([2002:a17:90b:254e:b0:31e:3c57:ffc8]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:55cc:b0:312:39c1:c9cf with SMTP id 98e67ed59e1d1-32166c164d8mr8817588a91.7.1754573462916; Thu, 07 Aug 2025 06:31:02 -0700 (PDT) Date: Thu, 7 Aug 2025 06:31:00 -0700 In-Reply-To: <515a5221-dbcd-45cc-bc55-887ae70b63db@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250805190526.1453366-1-seanjc@google.com> <20250805190526.1453366-18-seanjc@google.com> <515a5221-dbcd-45cc-bc55-887ae70b63db@linux.intel.com> Message-ID: Subject: Re: [PATCH 17/18] KVM: x86: Push acquisition of SRCU in fastpath into kvm_pmu_trigger_event() From: Sean Christopherson To: Dapeng Mi Cc: Paolo Bonzini , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Xin Li , Sandipan Das Content-Type: text/plain; charset="us-ascii" On Thu, Aug 07, 2025, Dapeng Mi wrote: > > On 8/7/2025 1:33 AM, Sean Christopherson wrote: > > On Wed, Aug 06, 2025, Dapeng Mi wrote: > >> On 8/6/2025 3:05 AM, Sean Christopherson wrote: > >>> Acquire SRCU in the VM-Exit fastpath if and only if KVM needs to check the > >>> PMU event filter, to further trim the amount of code that is executed with > >>> SRCU protection in the fastpath. Counter-intuitively, holding SRCU can do > >>> more harm than good due to masking potential bugs, and introducing a new > >>> SRCU-protected asset to code reachable via kvm_skip_emulated_instruction() > >>> would be quite notable, i.e. definitely worth auditing. > >>> > >>> E.g. the primary user of kvm->srcu is KVM's memslots, accessing memslots > >>> all but guarantees guest memory may be accessed, accessing guest memory > >>> can fault, and page faults might sleep, which isn't allowed while IRQs are > >>> disabled. Not acquiring SRCU means the (hypothetical) illegal sleep would > >>> be flagged when running with PROVE_RCU=y, even if DEBUG_ATOMIC_SLEEP=n. > >>> > >>> Note, performance is NOT a motivating factor, as SRCU lock/unlock only > >>> adds ~15 cycles of latency to fastpath VM-Exits. I.e. overhead isn't a > >>> concern _if_ SRCU protection needs to be extended beyond PMU events, e.g. > >>> to honor userspace MSR filters. > >>> > >>> Signed-off-by: Sean Christopherson > >>> --- > > ... > > > >>> @@ -968,12 +968,14 @@ static void kvm_pmu_trigger_event(struct kvm_vcpu *vcpu, > >>> (unsigned long *)&pmu->global_ctrl, X86_PMC_IDX_MAX)) > >>> return; > >>> > >>> + idx = srcu_read_lock(&vcpu->kvm->srcu); > >> It looks the asset what "kvm->srcu" protects here is > >> kvm->arch.pmu_event_filter which is only read by pmc_is_event_allowed(). > >> Besides here, pmc_is_event_allowed() is called by reprogram_counter() but > >> without srcu_read_lock()/srcu_read_unlock() protection. > > No, reprogram_counter() is only called called in the context of KVM_RUN, i.e. with > > the vCPU loaded and thus with kvm->srcu already head for read (acquired by > > kvm_arch_vcpu_ioctl_run()). > > Not sure if I understand correctly, but KVM_SET_PMU_EVENT_FILTER ioctl is a > VM-level ioctl and it can be set when vCPUs are running. So assume > KVM_SET_PMU_EVENT_FILTER ioctl is called at vCPU0 and vCPU1 is running > reprogram_counter(). Is it safe without srcu_read_lock()/srcu_read_unlock() > protection? No, but reprogram_counter() can be reached if and only if the CPU holds SRCU. kvm_arch_vcpu_ioctl_run() => kvm_vcpu_srcu_read_lock(vcpu); | -> vcpu_run() | -> vcpu_enter_guest() | -> kvm_pmu_handle_event() | -> reprogram_counter()