From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f201.google.com (mail-pl1-f201.google.com [209.85.214.201]) (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 17C641FC10A for ; Wed, 8 Jan 2025 13:38:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736343523; cv=none; b=sQdPENuiEdkcH7dqcQ/n1D1xiKYxIrssBgekZiMVZaBXUtspuchXx7lBtpc/yFMA/ipGOsmQqD3CcwxwW+Hf28kw3duV5R7W/uNMcsS+AVVABUsvEiYY4JeJNOsdlr0gI/VVzoDcOR2AAg/NYpf2krsIb4EobdD+wgDdM7T5xsY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736343523; c=relaxed/simple; bh=v1i3LZGDxegDo70qkjz8fMmEq10GKUa5BipY/8Zb4jU=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=dQJ49QwbuNLHHSWGF0rc+o3Ve9/2wTq9NBXwAQDR1qwSU7chiwJcH9U/qlZFwI5EK4ULHNAEwP66+YFA73PYrviMiOjo8dZZnMmjqFbjoNFA4u8yd2tPTKpl88YkhZ6EBqbGb7BmLb4D5uFTa4s3v+ogWc5vtV9WfOzo+p3GA1Q= 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=N44TRbIv; arc=none smtp.client-ip=209.85.214.201 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="N44TRbIv" Received: by mail-pl1-f201.google.com with SMTP id d9443c01a7336-21655569152so228406865ad.2 for ; Wed, 08 Jan 2025 05:38:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1736343520; x=1736948320; 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=w7673IoZMAUWJAQk7JdKPTs3A4XFRDa/9rJ0Dsq7WK4=; b=N44TRbIvIfjDzXOxQVJ3yKQXgK5mBolazLKDyJdKVLSAisw66TMs9WGYB8OoB3Jnzi zg9apeNPqI6g6xrbbK08z2RDqld9KlMdSjL67S3+0UiFtIczxvMS0YmycUDuDcD8M2Jg LeGFmcH0tab5gzHARKxjx4Aj4A1hf6WIAw0fROKt/MtqOrzsdZDhZzW6rI4vbWGPfVr8 RQDIf+sV7H5yUq67KFpJqEtmZFFfLZF1P4udZRZXEcEeVksx3C4I2ho3WGgYMtgWevzG RRhzWS2DaYxNkwv3KEjpoxZuvT5N1vYCOL0a0xrI3+W64t40Kx6/encpGW+wmUiWt6GK 1ckg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736343520; x=1736948320; 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=w7673IoZMAUWJAQk7JdKPTs3A4XFRDa/9rJ0Dsq7WK4=; b=bAjL1SiCjL8q1mP3eLrcYxgiGsjCpZGiPy0I++39TmU18DKv7VZYbB45s+Dvez5Fgg YHTTpv2HT4n7Rz0j6J9nVjxtNKmZTsnH4/QOVZ0t/VU3L/ECS3VPuWb8z5T+zb4MGmTr Cwg6bHdri+9npIHFRcwvB/RkJkh0bclz+f75urBot3MleuHp3VJcu7WJ60MxYdiRPmVw J/IV4+0VPUVNEUg9H7PoCw7wfd/kmTJjkURZpwJGFQur/zWRdQ/9X5tuovT6tAvIRo6+ KmowecFTpALYG4cOU5BMNkwyiBVtg7VSB6kf2sPIXt6i46sQrgaQhpRSA52NwYjq1AHu DHFA== X-Forwarded-Encrypted: i=1; AJvYcCU0CLtIbrnddEVMKGqFQzQaoRZc8nXGBS9dVAQEAtiVDmkscF/SOPLf/QBLZD5mukcft5zM1pIritrvugY=@vger.kernel.org X-Gm-Message-State: AOJu0Yxa6PzxcjsAjsw1XHB5bRfUNErGOgBVWuIoRedMAfy5LSGhFtg3 2sBC8MUqdnI6eJqlgS2cN8/CPrLpPf5Tj4+BR7khsJmBW/O0HQN8a4UAvbjxJxZUOT3lNhY2VM3 jeg== X-Google-Smtp-Source: AGHT+IE662rYKosp+Ytrg40LSm+v+14FNK7tIJlFa6LwAW+vPjEqsvJjXB56x/CoInApRih0gZZdUxpnLbo= X-Received: from pfba2.prod.google.com ([2002:a05:6a00:ac02:b0:725:ee5e:6efd]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a20:1589:b0:1d9:4837:ada2 with SMTP id adf61e73a8af0-1e88d1da95amr5556536637.35.1736343520579; Wed, 08 Jan 2025 05:38:40 -0800 (PST) Date: Wed, 8 Jan 2025 05:38:39 -0800 In-Reply-To: <20241230111456.GBZ3KAsLTrVs77UmxL@fat_crate.local> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20241202120416.6054-1-bp@kernel.org> <20241202120416.6054-4-bp@kernel.org> <20241216173142.GDZ2Bj_uPBG3TTPYd_@fat_crate.local> <20241230111456.GBZ3KAsLTrVs77UmxL@fat_crate.local> Message-ID: Subject: Re: [PATCH v2 3/4] x86/bugs: KVM: Add support for SRSO_MSR_FIX From: Sean Christopherson To: Borislav Petkov Cc: Borislav Petkov , X86 ML , Paolo Bonzini , Josh Poimboeuf , Pawan Gupta , KVM , LKML Content-Type: text/plain; charset="us-ascii" On Mon, Dec 30, 2024, Borislav Petkov wrote: > On Mon, Dec 16, 2024 at 10:51:13AM -0800, Sean Christopherson wrote: > Note the WARN_ON_ONCE bracketing. But I know you're doing this on purpose - to > see if I'm paying attention and not taking your patch blindly :-P LOL, yeah, totally on purpose. > With that fixed, this approach still doesn't look sane to me: before I start > the guest I have all SPEC_REDUCE bits correctly clear: > > # rdmsr -a 0xc001102e | uniq -c > 128 420000 > > ... start a guest, shut it down cleanly, qemu exits properly... > > # rdmsr -a 0xc001102e | uniq -c ... > so SPEC_REDUCE remains set on some cores. Not good since I'm not running VMs > anymore. > > # rmmod kvm_amd kvm > # rdmsr -a 0xc001102e | uniq -c > 128 420000 > > that looks more like it. The "host" value will only be restored when the CPU exits to userspace, so if there are no userspace tasks running on those CPUs, i.e. nothing that forces them back to userspace, then it's expected for them to have the "guest" value loaded, even after the guest is long gone. Unloading KVM effectively forces KVM to simulate a return to userspace and thus restore the host values. It seems unlikely that someone would care deeply about the performance of a CPU that is only running kernel code, but I agree it's odd and not exactly desirable. > Also, this user-return MSR toggling does show up higher in the profile: > > 4.31% qemu-system-x86 [kvm] [k] 0x000000000000d23f > 2.44% qemu-system-x86 [kernel.kallsyms] [k] read_tsc > 1.66% qemu-system-x86 [kernel.kallsyms] [k] native_write_msr > 1.50% qemu-system-x86 [kernel.kallsyms] [k] native_write_msr_safe > > vs > > 1.01% qemu-system-x86 [kernel.kallsyms] [k] native_write_msr > 0.81% qemu-system-x86 [kernel.kallsyms] [k] native_write_msr_safe > > so it really is noticeable. Hmm, mostly out of curiosity, what's the "workload"? And do you know what 0xd23f corresponds to? For most setups, exits all the way to userspace are relatively uncommon. There are scenarios where the number of userspace exits is quite high, e.g. if the guest is spamming its emulated serial console, but I wouldn't expect switching the MSR on user entry/exit to be that noticeable. > So I wanna say, let's do the below and be done with it. My expectation is that > this won't be needed in the future anymore either so it'll be a noop on most > machines... Yeah, especially if this is all an improvement over the existing mitigation. Though since it can impact non-virtualization workloads, maybe it should be a separately selectable mitigation? I.e. not piggybacked on top of ibpb-vmexit?