From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f74.google.com (mail-pj1-f74.google.com [209.85.216.74]) (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 D32FC143C72 for ; Wed, 15 Jan 2025 03:06:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.74 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736910384; cv=none; b=G8+3gTXMvI7lCu7IO08t6cqN9QDKBGfmFenAcf5JeHKDafNBX+bnY8xsBpL8wRz6P2kIoZ2lhlWeQr9wHy+7qWFcFG7ZC9bXgAQPildnPx0Ydby90tqbEH3xmfhb57v1Ra+wnUFkQEsOez9STwEV/uEkkN0oL7+5Y5cnU5POwGE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736910384; c=relaxed/simple; bh=EEC74rFlUByCYtLzJ41uJsbUpp21IUPfG5TyTOrVuV4=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=p6exptp6Q3NQD99VQaiQdXzlGC3xSvQxrhKX8YH5eVa82ciyM6zeV6CC5LytCXNmxbcDWa4mHcPX6plIhHPoPTxIiTDtukteVMITJqq9RXC4AZfdog4Nn+pzVN9RqCafelcjHPVY13uem3jb/PtfBJV25UkIavXEzR5z1sQHq6I= 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=l1W/s/p0; arc=none smtp.client-ip=209.85.216.74 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="l1W/s/p0" Received: by mail-pj1-f74.google.com with SMTP id 98e67ed59e1d1-2ef9864e006so17391890a91.2 for ; Tue, 14 Jan 2025 19:06:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1736910382; x=1737515182; 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=0IgGXI2mM2uHHPaOdnwW+AtakjIGYBXWPGxxnTIex44=; b=l1W/s/p01TYpxdFzVeFRoUo6ZRocAa26dPJyhm4fUS4xg6V8/Ez8JImNyICUSkPIWe CxQdi0uIvQNLkmb0UfzlGzmwIzeMpVTjWF5jQNW1Y3qpLH/qto5m8XKNHVyselp1vXEp Kd6kNNMc0E9iLvnMqRpa6+LNcsfxYTWQhAjm+dmc6/FQ7UlP1OR8Tm0meK3qSKaiHdDx E2PuC7elh548wB7PtHIe45z/12aTwQh156g4b6qbC84Vj7Y6MZnYwPGSqJ/+WCPggWWl w/lUqKerJf5ZYK/Qcl794tM8hg0sdJDY/jlx6/6TqzyDCP35prOZ6KAOhrnPfQ4sOuXO oyWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736910382; x=1737515182; 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=0IgGXI2mM2uHHPaOdnwW+AtakjIGYBXWPGxxnTIex44=; b=OCiJQIIPWNzoLrcu0HBso8M3uKMvbwRbSR+9azrDNlBpFIfjylwJScgQajFjDcYpVs NfTIzf/ZZtyyCoclPg9WpMh/oiagRWmBOE9mBE3QeqhdQC8BOuJH4DUXPYZeJV+FJr1b 7pE25SBPTWkJLq61ui+fIJTiYVyP/ZNKoCbxRC99s9iJidw5WxrEIqQ3PUK6QMt9hdGx PmGP04ftXcFpzKkTz4ZBhBwXKZAKDOonYRfS43W0KOOaSx+QIgvQyH2s94zRa6Tbsk41 odZfK0trZ6N7a6+LdnWtyREshaAfnFZRBoxhRxDRa9NnnDfHFhee4mwjS6ICn3gdBfZG OAXg== X-Forwarded-Encrypted: i=1; AJvYcCXFCclKPyACHFAHThNfIb8rQGjYHLodvLyh89Py1pLwai0KCFwIZMeRhsmdhcdge3IGbyUpV3hkU6jVQ8g=@vger.kernel.org X-Gm-Message-State: AOJu0Yxkn8SXxTAMNK6XzJYxozJVG4fb3cT8NCdq4S8VpNAcdZiT9HBH m4JOZ8Xg9GVVLIhPOkKmSFOQMGd8NGF8DV551vob5fL9x3ckk46mS7Z7msXf4OYAKEweB2Eta/k q5Q== X-Google-Smtp-Source: AGHT+IHtpD0Tau+LdhYqQEB+5TGJMm1AvQPFGKVD1x6X+saCf4pKDrwRrPk1PzPjdS6sxPJm87sX0iY2YPg= X-Received: from pja13.prod.google.com ([2002:a17:90b:548d:b0:2ef:9ef2:8790]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:538e:b0:2ee:c4f2:a76d with SMTP id 98e67ed59e1d1-2f548f59a46mr36072918a91.21.1736910382268; Tue, 14 Jan 2025 19:06:22 -0800 (PST) Date: Tue, 14 Jan 2025 19:06:20 -0800 In-Reply-To: <0862979d-cb85-44a8-904b-7318a5be0460@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20241108130737.126567-1-pbonzini@redhat.com> <0862979d-cb85-44a8-904b-7318a5be0460@redhat.com> Message-ID: Subject: Re: [PATCH] KVM: x86: switch hugepage recovery thread to vhost_task From: Sean Christopherson To: Paolo Bonzini Cc: Keith Busch , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, michael.christie@oracle.com, Tejun Heo , Luca Boccassi Content-Type: text/plain; charset="us-ascii" On Tue, Jan 14, 2025, Paolo Bonzini wrote: > On 1/13/25 16:35, Keith Busch wrote: > > > Ok, I found the code and it doesn't exec (e.g. > > > https://github.com/google/crosvm/blob/b339d3d7/src/crosvm/sys/linux/jail_warden.rs#L122), > > > so that's not an option. Well, if I understand correctly from a > > > cursory look at the code, crosvm is creating a jailed child process > > > early, and then spawns further jails through it; so it's just this > > > first process that has to cheat. > > > > > > One possibility on the KVM side is to delay creating the vhost_task > > > until the first KVM_RUN. I don't like it but... > > > > This option is actually kind of appealing in that we don't need to > > change any application side to filter out kernel tasks, as well as not > > having a new kernel dependency to even report these types of tasks as > > kernel threads. > > > > I gave it a quick try. I'm not very familiar with the code here, so not > > sure if this is thread safe or not, It's not. > > but it did successfully get crosvm booting again. > > That looks good to me too. Would you like to send it with a commit message > and SoB? > > --- > > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c > > index 2401606db2604..422b6b06de4fe 100644 > > --- a/arch/x86/kvm/mmu/mmu.c > > +++ b/arch/x86/kvm/mmu/mmu.c > > @@ -7415,6 +7415,8 @@ int kvm_mmu_post_init_vm(struct kvm *kvm) > > { > > if (nx_hugepage_mitigation_hard_disabled) > > return 0; > > + if (kvm->arch.nx_huge_page_recovery_thread) > > + return 0; ... > > kvm->arch.nx_huge_page_last = get_jiffies_64(); > > kvm->arch.nx_huge_page_recovery_thread = vhost_task_create( > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > > index c79a8cc57ba42..263363c46626b 100644 > > --- a/arch/x86/kvm/x86.c > > +++ b/arch/x86/kvm/x86.c > > @@ -11463,6 +11463,10 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu) > > struct kvm_run *kvm_run = vcpu->run; > > int r; > > + r = kvm_mmu_post_init_vm(vcpu->kvm); > > + if (r) > > + return r; The only lock held at this point is vcpu->mutex, the obvious choices for guarding the per-VM task creation are kvm->lock or kvm->mmu_lock, but we definitely don't want to blindly take either lock in KVM_RUN.