From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f200.google.com (mail-pl1-f200.google.com [209.85.214.200]) (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 88F1C560ADD for ; Tue, 22 Sep 2026 17:36:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.200 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790098613; cv=none; b=myI5C0H/ArXBN6CWoxavENnTs3lwze0PF3ERPCqnsnsEOQgWNdF4h990yJ10G4HYuFdmaPPjnvzpP7sWZXPi3k5zsTmCUu36HIEtJxSWYiuhklKMe5UiAWYXrNKz+4yBoaoGzuMRI3kvPQEWPq+9QoKf4T80KSwJFURd/kvSMuE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790098613; c=relaxed/simple; bh=pqfxOYdbk3G5uQ189p1pwNugqSafNpPZSMqnl+pMNDk=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=Viy0S4Gn9VrhV3IdCjzY/UJpLY0taBaVgQot1Y4A36e23rlfUlCGWb8sLg9Mf1QAIZDNZ2Hu1N/Rppkb1JhOh95og6QpoFu+Ke+CwJXhHa9Klvc9p85y+dGDP/qmqO8K2BOAb1nPvYlYwIlo/A9+wjHuClKt/++JTDIPP+kpCWM= 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=oM1ZLTAy; arc=none smtp.client-ip=209.85.214.200 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="oM1ZLTAy" Received: by mail-pl1-f200.google.com with SMTP id d9443c01a7336-2d7443e0f0bso1364075ad.1 for ; Tue, 22 Sep 2026 10:36:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1790098611; x=1790703411; darn=vger.kernel.org; h=content-type:cc:to:from:subject:message-id:references:mime-version :in-reply-to:date:from:to:cc:subject:date:message-id:reply-to :content-type; bh=gMBUcj03qoQAyG1GKCyEGFSnmBsF37yewOw9nu3IXkc=; b=oM1ZLTAyP/iuDIrEN/1s/ssMc/qjOS4GrxyBzqHMVVERK2b3yj7f1Tyqc9F3udzJ/S h7JBV0Z+qXLBd9KMzr0uhXevBPRDNSTDckL9Af+u99518jNLE3RsiuP9HN9twCvckg3y /qlNsySx2Cm64UCewyIdM93WDi3UsNzXw0RHuGdgb+kvdzh0d5AtZq55ohB6Rqix/Bb7 qOf1EPwQNagvNnKVog9RgJrnzuyVJJ88V2vRLsznimq70j6+OHs62jP9kyp+bHiQNFJ/ PDWwIg3KSqj7aKgpHg2c/DEG9FZnF2wGnq5q5trQjcUc4t8XqEJAtajrmbuGfLkd8cRp I/zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790098611; x=1790703411; h=content-type: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:content-type; bh=gMBUcj03qoQAyG1GKCyEGFSnmBsF37yewOw9nu3IXkc=; b=YtLaIRocopuXEFjA7e/CU2bnrVfcGIEud1kSkzX1ktzF1yUUMh8Ot1XS0pALb8fpl6 ODKs1LfT49ZK49iyF4kE7NH7xqi3dDQzh+bEgEMUy2pGbHXkYkyQCnL0KSQxQhGjdLB7 prqpnH0s6S7yKplYkEzvkDUmBnoIN4U8c0qT+faoFZUU5jl+UvKb3a+UulcY4R4V1VFY hOiaZGVdyoiA0u4t61WVGa5QSKuGuOn/F1vy0jceIsnCLrRB49UOCU4px6TTkgnbBn6e dtOIFsIF9XPHyDor9rqDXV5KRslzG+9v2Crg55cBxx/57NF+SRETZpCV94luMh59eifE YCdg== X-Forwarded-Encrypted: i=1; AKwUvBx6Q6u6Ft5+Kmxr/EKnJe1lBAoo3/WHvHCiBrkU5lt+2jQWLspCTJgMPAX5cxxAgJllJxwaHltK6S0=@vger.kernel.org X-Gm-Message-State: AFuF++lV2/hBJv8S090R38vGq+lrxBfe2NBIhTj+VOTS81kWTB7fDJ7Q 6eyQQpIhAeXJanyLXNn1XOS1mJVoYCd4RLIgFPLZC5wEGj6znxtHRnfwjp/UKkZ/zjJrnyRDSLC v27S5sg== X-Received: from plhz10.prod.google.com ([2002:a17:902:d9ca:b0:2df:4a0d:5ac]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:903:4b27:b0:2dd:c100:a5d9 with SMTP id d9443c01a7336-2df69df7453mr924125ad.45.1790098610429; Tue, 22 Sep 2026 10:36:50 -0700 (PDT) Date: Tue, 22 Sep 2026 10:36:49 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260922-kvm-arm-prefault-v3-0-787bd3bc7e3f@kernel.org> <20260922-kvm-arm-prefault-v3-1-787bd3bc7e3f@kernel.org> Message-ID: Subject: Re: [PATCH v3 01/14] KVM: Allow architectures to disallow pre-fault From: Sean Christopherson To: "Lorenzo Stoakes (ARM)" Cc: Oliver Upton , Catalin Marinas , Will Deacon , Marc Zyngier , Joey Gouly , Steffen Eiden , Suzuki K Poulose , Zenghui Yu , Paolo Bonzini , Jonathan Corbet , Mark Rutland , Fuad Tabba , Randy Dunlap , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, Jack Thomson , Jack Thomson , Alexandru Elisei , Vincent Donnefort , "Aneesh Kumar K.V" , Claudio Imbrenda , Leo Soares Passos , Wei-Lin Chang Content-Type: text/plain; charset="us-ascii" On Tue, Sep 22, 2026, Lorenzo Stoakes (ARM) wrote: > On Tue, Sep 22, 2026 at 10:23:43AM -0700, Sean Christopherson wrote: > > Rather than have kvm_arch_vcpu_allow_pre_fault_memory(), what if we add a more > > generic kvm_is_vcpu_loadable()? That way we don't need to worry as much about > > the return value, the connection to vcpu_load() is obvious, and we don't need to > > add another pre-check if future (or cleaned-up existing?) ioctls want to do > > vcpu_load() in common code. > > ...this is exactly what I started out with. > > But then you are in a pickle, because _really_ you need to do that check in > vcpu_load(). Which is a void function. Which is called by every single > architecture all over the place. > > So you'd have actually no way of signalling the error back. > > Of course those places are arch code and you could say 'arches should know > better and if they call it it's fine not to call the arch 'can you load' > function. Yes, that's my vote. It'd be easy enough to clarify that "rule" with a comment in linux/kvm_host.h. > But you're still stuck with the problem of where exactly you put this check. > > So then do you put that check in a wrapper around it? > > Instead you can make the predicate 'don't prefault on a not-yet-initialised > vCPU' which is pretty sensible I think, have a specific place to put it and > all's well with the world. But look at it from an x86 perspective. Pretty much everyone will look at this and expect: bool kvm_arch_vcpu_allow_pre_fault_memory(struct kvm_vcpu *vcpu) { return vcpu->kvm->arch.pre_fault_allowed; } > > I'd also be tempted to say it can be a macro, not a __weak function. E.g. > > Yeah it can be many things but why would you want a macro if you could possibly > avoid it? :) Because it allows arch code to dererefence "struct kvm_vcpu" in kvm_host.h, i.e. allows "inlining" the check.