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 06CF640B374 for ; Mon, 15 Jun 2026 16:24:11 +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=1781540653; cv=none; b=QiW+yyK57vbfBvtGxrldJlJ1xsPjY8p/KWQSwrooSrjR5tf0fq4A1dt8AgXbwJymW5cCgfT0fyg2maewenkxhcAvtlQLjpuo1Ug/5PM0Nnbl2064IljvMeBgbFasjr+qPk3+3/n2uDiQwzzh6hD87C6WNGtvEnc84T54e4IYoe8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781540653; c=relaxed/simple; bh=EVt56oAjTD6wNFwS9tRM+Jo2ox+dBTYN6dvu6U4tLsw=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=usqvYNedXb/7RDn7woAEKWAs43mry4DawaS2PDV8ryNGeE0DsX8ntVWuc/BKvkF0auR+snwyIWnefyjUPTeULfAGDHda1f/mQRQUdonUlsfm99G+Ls0Q2ZtPFSZm1ZKByfktHKd0HhnKNkWOykM+kU5QeZ4Gyc9qTZG3Bm/8+Is= 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=GSPvKnPe; 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="GSPvKnPe" Received: by mail-pj1-f73.google.com with SMTP id 98e67ed59e1d1-36d97415004so6683495a91.2 for ; Mon, 15 Jun 2026 09:24:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1781540651; x=1782145451; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=EVt56oAjTD6wNFwS9tRM+Jo2ox+dBTYN6dvu6U4tLsw=; b=GSPvKnPeRUXzyJYLwHaB0jP2RdsU2T7CGqeKKo/n7gPo7FHFAo+Q1lDwcJU4TEgUvq sQzE4ATM5MI4T9DxtyPosiLIhKJxQyBKP8xQh/NoVESYWsWwbISAP3aSCw+XykDTitwz cqP4bqSkmX7U5/eRwWESWqmQcWoD30/WIPSBta71qU6GuwC/6yiANPldMM1ddvk3Ukjs RJbDVECk6uxEjLNNosGhUTwzAqHqbPSb4iGcOl0RCRnKpYPwcqUmZjVmricCTQykmT37 2ucoKZeB9/dvNd0u9FVOOm67DxK74Oe7NJ4MRWijAcv4QvzveKlMVTygx6+ynVXkMDxd Z5kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781540651; x=1782145451; h=content-transfer-encoding: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=EVt56oAjTD6wNFwS9tRM+Jo2ox+dBTYN6dvu6U4tLsw=; b=eSvC0Tu83u3bHJ0z5c1ii35FKIXejC4iDuuuJqsLfj8QdpynMGsQ7hyN0zBzTQ1ozo IwbXAIP5aphDlSO0/vrTNMk7Yf9YtiMdNu3DbAtw6E8gnyp7sJpB03+YHQYOwxH+7jl7 Ocq8M3/l6a07/rESfQpSROZlcB63PrYS2aqEew+JRaG/d342RpVQDl8HkbFIEiDPN58+ sQv46oLjyKN7klwfckDxeEmR+iU3DBXmcegPU8NonrGrZyxLQUC47bgcYD7fxQG0v3AQ 6RDze0KQFYwdLsBaXpmDyTUyiVuQUdJViGeBTv5RZvYJwH1chNkjo39NlkT22ojlOgou DxMw== X-Forwarded-Encrypted: i=1; AFNElJ+TWP9oyYy0/mU8qtGfzSEUuoE1vPPlkrZIIqrS/J2xtGUMUQewW635Ew/B5IuFm9exvKUSMPyvFTmsJVY=@vger.kernel.org X-Gm-Message-State: AOJu0Yw9RImFXbTmXpQovtYjl2Zl9sx0FNhHPC4FLAOFBFXVLAJ1N1bO pkdnEGReWtnM+eCIBtAFq0ZWqBrRkefff0rm2h/KjgJ+B74H2sH89rLERiwGxXZel2qHXokF2yb soF0z+Q== X-Received: from pjbrr7.prod.google.com ([2002:a17:90b:2b47:b0:36a:7bd1:2d9c]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90a:d006:b0:36a:8ce7:b879 with SMTP id 98e67ed59e1d1-37a018486cdmr14629534a91.5.1781540651113; Mon, 15 Jun 2026 09:24:11 -0700 (PDT) Date: Mon, 15 Jun 2026 09:24:10 -0700 In-Reply-To: <69019093-fed6-4cb1-b3b5-a62a3a46578c@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260613000329.732085-1-seanjc@google.com> <20260613000329.732085-7-seanjc@google.com> <69019093-fed6-4cb1-b3b5-a62a3a46578c@linux.intel.com> Message-ID: Subject: Re: [PATCH v4 06/30] KVM: x86: Move kvm_caps and kvm_host_values to asm/kvm_host.h From: Sean Christopherson To: Binbin Wu Cc: Xiaoyao Li , Paolo Bonzini , Vitaly Kuznetsov , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Yosry Ahmed , Kai Huang Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Mon, Jun 15, 2026, Binbin Wu wrote: > On 6/13/2026 5:01 PM, Xiaoyao Li wrote: > > On 6/13/2026 8:03 AM, Sean Christopherson wrote: > >> Relocate the kvm_caps and kvm_host_values struct definitions and their > >> associated global variable declarations to asm/kvm_host.h to allow for= a > >> variety of cleanups in x86.h and mmu.h, and to establish a (hopefully) > >> maintainable rule that asm/kvm_host.h's role is to define common > >> structures (and declare any associated globals), and anything needed b= y > >> arch-neutral KVM. > >> > >> While it would be lovely to trim kvm_host.h down to the point where it > >> *only* holds things needed by arch-neutral and/or non-KVM code, multip= le > >> attempts to do just that have failed miserably.=C2=A0 Trying to "hide"= code > >> from arch-neutral KVM is too restrictive (and ultimately pointless), a= nd > >> KVM x86 itself also needs a place to define common structures and thei= r > >> globals, e.g. to avoid inconsistent header include chains and/or mispl= aced > >> helpers. > >> > >> E.g. as pointed out by Kai, it's weird that x86.h, which is a kitchen = sink > >> of sorts, includes regs.h, but not mmu.h.=C2=A0 Literally the only rea= son that > >> x86.h doesn't include mmu.h is that mmu.h references kvm_host, which i= s > >> currently defined in x86.h.=C2=A0 As a result of odd include ordering,= the > >> very clearly MMU-specific helper mmu_is_nested() lives in x86.h, not m= mu.h > >> > >> "Fix" the kvm_host dependency so that x86.h can be the "central" inclu= de > >> everyone expects it to be, and set KVM x86 on the path to having somew= hat > >> sensible "rules" for what goes where: > >> > >> =C2=A0=C2=A0 - asm/kvm_host.h holds "common" structure definitions and= associated key > >> =C2=A0=C2=A0=C2=A0=C2=A0 global variables, and things that are referen= ced by arch-neutral KVM. > >=20 > > I'm confused by the term "arch-neutral" all over the changelog. I suppo= se "arch-neutral" refers to virt/kvm code and other code that isn't arch speci= fic. I used arch-neutral here, e.g. instead of "common code", to differentiate b= etween arch-neutral (virt/kvm) code and common x86 (arch/x86/kvm) code. > > include/linux/kvm_host.h is arch-neutral while asm/kvm_host.h is > > arch-specific but not KVM internal only. >=20 > IIUC, it's the situation where asm/kvm_host.h for x86 provides the > x86-specific pieces that the generic/arch-neutral KVM depends on. > E.g. struct kvm_arch is defined in asm/kvm_host.h, which is x86-specific,= but > the generic KVM embeds it in struct kvm as 'struct kvm_arch arch' in > include/linux/kvm_host.h, i.e. "referenced by arch-neutral KVM". Yep, exactly.