From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f199.google.com (mail-pl1-f199.google.com [209.85.214.199]) (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 324C64B129F for ; Thu, 3 Sep 2026 15:54:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.199 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788450879; cv=none; b=ln68Gb9U5wbgslKJBV0b8ZGBdr1XhOoGcb7GrAbDOR+kbhLOZb+B4+IwKuvWiMS2lEei1QCeLvxt4bClR6ztXD4+ZOo64A6NcLH5ABBiBRkb4vZfrp16AblgIinGneKG6kWsg8BCN9DCl+GJHjQCyFJu6zD5+tdQVv+iq9bup48= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788450879; c=relaxed/simple; bh=Kk2AD3UOwPSnwmgTVWy6P/2K5EFdMfMyACv+LM8k68Y=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=M81C3tbdQvjzhkFhRvppvrYZp9jfvRgVa5/evCAXD9AtFespe5ryh1m+5kVZ9wy09JCXO8XwfmuJ/1MrtTHrcOwgsbUz/82IuXdKZNPFnFZzDCb/CCP+Bhc5Bp21gkvBUQESyDAbcTKLdlFWouIO0ZZs3/2eYauiHFyYeIqs1Ww= 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=orQHUJsF; arc=none smtp.client-ip=209.85.214.199 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="orQHUJsF" Received: by mail-pl1-f199.google.com with SMTP id d9443c01a7336-2d54187d8b0so68898165ad.0 for ; Thu, 03 Sep 2026 08:54:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1788450878; x=1789055678; 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=8mGifk9h8LIddg9L9JpNR126tGysvi+0g41edfZ4g+M=; b=orQHUJsFfJFwE/Er9oXA+g8Cq4LzA9jiSBhLUrxndI8d+df5PPzDJ9Q9lQ1p+Jid6l uyPv+Fnv7/V9P/hT/ucg0jVefOoZe/PIedqpR7UpEzqobb+Rt+eAYoQAXeEYJy8zJobV DulMuDG7twFIn4tpRFKXBMQ5CVsGPqklTTjha7DZGuqYmRN4xCIjHPNZYJ4zCu+axsPK hYRxjCjm6yN+Fa9MxcoqY3xt/WtRLp6ob2u7Shg2UKjLgnUIj9GxssknS7b2Qpl7joCv mQgWHvEKHUFpzWFQQheg9fl5za+ggQVGCV+Q5laT5NVyXcnPm/hWEHZiMdK2NF5ypJEh ehzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788450878; x=1789055678; 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=8mGifk9h8LIddg9L9JpNR126tGysvi+0g41edfZ4g+M=; b=I2PqOS4JQFlP64QApmkdZ1RPB88+bP3z43tbsp71CAlU2RxS9DQAJp938ITlmZ6jwe /UvHlaRX/feZgtUdw6rU5bSahpAhTSZz6VMXmYzfO69oiGtvsdQfjWSMQ/8fG8fLJEie QZKKVbYdWBMjYe5kCl06nM8SSc+0pUd56aBVaJojFBKBvZoxEKvLZdd5QbVqxIlVYPG5 toWQnDAk+1771fujgNLxqfiJoAnhpmzYDsQQuB9IwAc09QfqQf1yMIVfE3ARmKzT79uk pJkeBUOE35y3Zsun4uSvOfK2U//pw4ltaZXzOjAXvpo3heXFGPUe/pSjhREn26GrdhJK PNtg== X-Forwarded-Encrypted: i=1; AKwUvBxIex+HMtAtKlg7iehwce4ilBF5qeFHoWFFZRU1PlvkElJd6djDipV3qVBX82tkPZG1pmmD+IiRhGw/AvY=@vger.kernel.org X-Gm-Message-State: AFuF++nhCZD+vN2qzpZYPG065NbLDJjgOEWdoi3kb//bKjdi14ppi/n9 TADXi6Woy8VH+5rn/wphE9Mza4vME6Q1xyqebiEozaLWprkgOsEnN2d0pyFgJH6unL+HAydSHvy 2wchemw== X-Received: from pgp23-n2.prod.google.com ([2002:a05:6a02:62d7:20b0:cb2:563f:d136]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a21:7d02:b0:3d3:ae50:97cb with SMTP id adf61e73a8af0-3da35f9b1e3mr1317921637.24.1788450877399; Thu, 03 Sep 2026 08:54:37 -0700 (PDT) Date: Thu, 3 Sep 2026 08:54:36 -0700 In-Reply-To: <19d4feb1-d703-4c62-8622-a6d5e9d6394c@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260831144802.834315-1-seiden@linux.ibm.com> <20260831144802.834315-3-seiden@linux.ibm.com> <20260902075028.231001-D-seiden@linux.ibm.com> <20260903114241.33034-C-seiden@linux.ibm.com> <19d4feb1-d703-4c62-8622-a6d5e9d6394c@redhat.com> Message-ID: Subject: Re: [PATCH v7 02/23] KVM: Make device name configurable From: Sean Christopherson To: Paolo Bonzini Cc: Steffen Eiden , kvm@vger.kernel.org, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org, Alexander Gordeev , Andreas Grapentin , Arnd Bergmann , Catalin Marinas , Christian Borntraeger , Claudio Imbrenda , David Hildenbrand , Friedrich Welter , Fuad Tabba , Gautam Gala , Hariharan Mari , Heiko Carstens , Hendrik Brueckner , Ilya Leoshkevich , Janosch Frank , Joey Gouly , Marc Zyngier , Nico Boehr , Nina Schoetterl-Glausch , Oliver Upton , Suzuki K Poulose , Sven Schnelle , Ulrich Weigand , Vasily Gorbik , Will Deacon , Zenghui Yu Content-Type: text/plain; charset="us-ascii" On Thu, Sep 03, 2026, Paolo Bonzini wrote: > On 9/3/26 16:45, Sean Christopherson wrote: > > > > Actually, thinking about this more, what I've proposed here, plus the pattern of > > > > #define-ing macros in arch-specific kvm_host.h files, should suffice. For things > > > > like __KVM_HAVE_ARCH_VM_FREE, it absolutely makes sense to #define the macro in > > > > kvm_host.h since it's very directly tied to an arch callback. Whereas with KVM_MIO > > > > and KVM_ASYNC_PF, because they enable compilation of C files, it makes sense to > > > > define them in Makefiles. > Ugh, defining CONFIG symbols in Makefiles sucks. Sure, but IMO wrapping entire files in an #ifdef that comes from an arch header sucks more. And technically, these aren't CONFIG symbols. > I don't want KVM to be the. one that does things differently *once more*. Too late :-D arch/arm64/kvm/hyp/nvhe/Makefile:ccflags-y := -D__KVM_NVHE_HYPERVISOR__ -D__DISABLE_EXPORTS -D__DISABLE_TRACE_MMIO__ arch/arm64/kvm/hyp/vhe/Makefile:ccflags-y := -D__KVM_VHE_HYPERVISOR__ And I think there's value in deliberately being different, because CONFIGs are kernel-wide things, whereas the thingies in question are KVM-local macros. I.e. IMO, having the behavior stand out is a good thing. > I'd prefer to stub out the contents of the .c files instead.