Message ID | 20240215133631.136538-1-max.kellermann@ionos.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-66994-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:b825:b0:106:860b:bbdd with SMTP id da37csp401953dyb; Thu, 15 Feb 2024 05:36:58 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCXx9PGEvqZQDxnhXBScUzOsxMyaia/5v3GyKRcIsRJSDSVT3kjlfDrPBqlQ6vunC/X3zAN7CWjj67ClMwE4owEaAxPg1g== X-Google-Smtp-Source: AGHT+IFOLs2Y0O12ysBNQTX2IesUqxTFN2JNlXZ9Y80rsAfopjq6pHebdWZnIT0Rm4uTWeyQPWMd X-Received: by 2002:a1f:ec41:0:b0:4b6:ea01:f1ce with SMTP id k62-20020a1fec41000000b004b6ea01f1cemr1463974vkh.5.1708004218137; Thu, 15 Feb 2024 05:36:58 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708004218; cv=pass; d=google.com; s=arc-20160816; b=mm8kPLn8bPARBQq4v81gfJsEeLn9gTHVJs/wsR1f6a5Ri4i/UvAlpYLibHeklDKte4 Z2OguuydCGEyEtVVQq+2JQpfHQEGavIil1T0ME744EtYydtW/EE7MHKvbr39tO7NPk7J M3wy2nTTrLYK1OX38+94ovQKOZz3ho3/+0hIxCol3+lgkFIvxeCy97HTGqMyljgNoulz 3w1WyRoA3cRfW9A0/Lc80lm/stdYxC46QpYvBKNyv1hBHeqBuiGX6gLCcDInWf9L927X SiJTzvonmbm3noaljNoP+1iss3JzfAPI501DwGHFFzR0CgH1KBMx12xfMyfKi5GEMrda A+Ig== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=kSAPglM2wZ+xLjfRrMYJKrvwCFVOGwCTlmuHoEDAY3I=; fh=LWSZ/wbcu4BsajS6Bk00WGdNqMG0ZZSL/fTMVNIEjOg=; b=Lr5nA91910BBYVoAXD8iH1AYchK8QlwjHLyAxyQQNQuqyhEdLq1ce/FYhL0TXziRrN sxnF2lMeMf7M6wiLoGXajbaBZ8MJgr8JBPC+Ui0bX8vMU2ziPSZ+JlBXj9MzxyRXG/8T V0OzsaLy/R1qtxc4zAPnX5QMOmaoC7jdC6m/fX8MtZPUYggrcN8cnuvxi/gn/Z+CCGH6 U2KfHcybroTp3ZhbGfBVxIkoJtENZGFMub1GC0Dt6Wuvqy7I3hMUmDBrAtQPJzAcNx5k E0+I6mLs0EbNSUu5JvnR/jmG9/b/Z/bpfYjdUdKKsUWwmYA16LD2Xk+yOvWo5pUNklkR 3nlg==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@ionos.com header.s=google header.b=IY4OVNa0; arc=pass (i=1 spf=pass spfdomain=ionos.com dkim=pass dkdomain=ionos.com dmarc=pass fromdomain=ionos.com); spf=pass (google.com: domain of linux-kernel+bounces-66994-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-66994-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=ionos.com Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id fm8-20020a056122290800b004c0230866f3si200025vkb.126.2024.02.15.05.36.58 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Feb 2024 05:36:58 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-66994-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@ionos.com header.s=google header.b=IY4OVNa0; arc=pass (i=1 spf=pass spfdomain=ionos.com dkim=pass dkdomain=ionos.com dmarc=pass fromdomain=ionos.com); spf=pass (google.com: domain of linux-kernel+bounces-66994-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-66994-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=ionos.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id DEF631C21B8D for <ouuuleilei@gmail.com>; Thu, 15 Feb 2024 13:36:57 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 268F9130E31; Thu, 15 Feb 2024 13:36:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ionos.com header.i=@ionos.com header.b="IY4OVNa0" Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com [209.85.208.51]) (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 A50CB12BF3D for <linux-kernel@vger.kernel.org>; Thu, 15 Feb 2024 13:36:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.51 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708004205; cv=none; b=GdJdXZWueyrRLyLS79JJCJ+i3UebWyvQKVybR70MNEHAXfck9bHBOSdHcRMZzX5ooEjSwz34Xc3tuptKRDwFNwIJgwcqKF0RDLip4LWIqFc+B/NdaAFRCkGDEtbEmAvr2POdfRhvDC9fsd/eMBKj92SSDVwI96wl/XUKu3kIO0k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708004205; c=relaxed/simple; bh=+qesoz2V42RgfnQKUGiS5UYjIIFWsK48uyeINtqXE/A=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=BWDoUwr9QXaCGJxIsGFy8vs3NcaWSR+7xAOosbcf3u6uB5X5JefwLTQGrguHxDiMReihs4mHjQAQx6s9tt7l8nQ9CmNsDy1b3O8b06jxrkCNn6ZUazAUq+2/ueLlL0zpSrwNAuL+cjvMGHPySZOvHvW30X/SMtNUBAxqCLC8CIM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=ionos.com; spf=pass smtp.mailfrom=ionos.com; dkim=pass (2048-bit key) header.d=ionos.com header.i=@ionos.com header.b=IY4OVNa0; arc=none smtp.client-ip=209.85.208.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=ionos.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ionos.com Received: by mail-ed1-f51.google.com with SMTP id 4fb4d7f45d1cf-561f78f1ba1so940146a12.0 for <linux-kernel@vger.kernel.org>; Thu, 15 Feb 2024 05:36:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ionos.com; s=google; t=1708004201; x=1708609001; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=kSAPglM2wZ+xLjfRrMYJKrvwCFVOGwCTlmuHoEDAY3I=; b=IY4OVNa0hihlnbwP70YHsBdcI2BzPlAKrsg/qokuZRhUvP9s82dAMSHruJ2z6p/3GA KV3PD7KImFwQsfHaNMpgdBNZVtVYG7LshSc799Owvsn8V8yzoZBi267aAjG2rsCaE3US mVSlhjM/cDhdG+l139cr4O4sWiS2F67SXD25oL7MHhBW61d7olpTMDmJVVFhHpUovZfO VeeJ9WoIWTRDZ1ngyOqwX/Ia+q7xUZBE0FCWMr77kQx+dsq92Xu5xHVyZvDtJqH+DqVM 959w0q5tBVNY8XOjZjrXtVbbeatTnRNewH6skM1WkZzCJ1sJjNrqXkp/FIXCnAi1MeyS fQCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708004201; x=1708609001; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=kSAPglM2wZ+xLjfRrMYJKrvwCFVOGwCTlmuHoEDAY3I=; b=u3UcQWvshaQNzL+J9VBjyJapqwKnTSbvjxsZ3o8/pv+p9ttJAUF+PbSl3G9gOlIM58 MSCK4xXG+5Gb3ujhLD4ihwE1yh6o+FFbll9TuJzveb0hQArPIf0relvfcsfx/pkAI8dK +EdU/wdI+KDgl5OvmHohZG2HuXtlGxVrYYXEkay6ZqszNhAzMdDWyomcmAuzLPmGUWQs aRDuXdxZetnKPdOpmxJMJG6ScjMPgD8ppmM/0F8QCZj2dur1jQLft+oyQ3bgHM5JCtVX z077GuwoL3NcQnPZ6T/8ymwrlRqYgk1ersxJCpE5ofOd9y6ZoChDEnIMYBRcmhBCj3Yp suyg== X-Forwarded-Encrypted: i=1; AJvYcCWyG0Q0awL0Bz+C7Sh0bUaoVdfYkcK4/9lRHvlp1O8dnHGethKD31VCyhIIbTR+4sw0INEQS900utFiLx0uzoFMCrnziWFQEsXWVB7t X-Gm-Message-State: AOJu0YwzMZPk5zrolNaNJnU3woFqV3fXEgzmAthzhS1tJ1BcjeL4RX8y H9XMXCoam6QUdY1gEcjz/GwQF7yywfIVsCxGa9zCRBBRRA1lPbaL0hrkHPmj3KQ= X-Received: by 2002:a17:907:76e5:b0:a3d:8035:fdd1 with SMTP id kg5-20020a17090776e500b00a3d8035fdd1mr1467797ejc.76.1708004200904; Thu, 15 Feb 2024 05:36:40 -0800 (PST) Received: from raven.blarg.de (p200300dc6f267100023064fffe740809.dip0.t-ipconnect.de. [2003:dc:6f26:7100:230:64ff:fe74:809]) by smtp.gmail.com with ESMTPSA id w24-20020a170906131800b00a3d22f53210sm542350ejb.188.2024.02.15.05.36.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Feb 2024 05:36:40 -0800 (PST) From: Max Kellermann <max.kellermann@ionos.com> To: hpa@zytor.com, x86@kernel.org, linux-kernel@vger.kernel.org Cc: Max Kellermann <max.kellermann@ionos.com> Subject: [PATCH] arch/x86/entry_fred: don't set up KVM IRQs if KVM is disabled Date: Thu, 15 Feb 2024 14:36:31 +0100 Message-Id: <20240215133631.136538-1-max.kellermann@ionos.com> X-Mailer: git-send-email 2.39.2 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1790972231122972763 X-GMAIL-MSGID: 1790972231122972763 |
Series |
arch/x86/entry_fred: don't set up KVM IRQs if KVM is disabled
|
|
Commit Message
Max Kellermann
Feb. 15, 2024, 1:36 p.m. UTC
When KVM is disabled, the POSTED_INTR_* macros do not exist, and the
build fails.
Fixes: 14619d912b65 ("x86/fred: FRED entry/exit and dispatch code")
Signed-off-by: Max Kellermann <max.kellermann@ionos.com>
---
arch/x86/entry/entry_fred.c | 2 ++
1 file changed, 2 insertions(+)
Comments
On 2/15/2024 5:36 AM, Max Kellermann wrote: > When KVM is disabled, the POSTED_INTR_* macros do not exist, and the > build fails. > > Fixes: 14619d912b65 ("x86/fred: FRED entry/exit and dispatch code") > Signed-off-by: Max Kellermann <max.kellermann@ionos.com> > --- > arch/x86/entry/entry_fred.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/x86/entry/entry_fred.c b/arch/x86/entry/entry_fred.c > index ac120cbdaaf2..660b7f7f9a79 100644 > --- a/arch/x86/entry/entry_fred.c > +++ b/arch/x86/entry/entry_fred.c > @@ -114,9 +114,11 @@ static idtentry_t sysvec_table[NR_SYSTEM_VECTORS] __ro_after_init = { > > SYSVEC(IRQ_WORK_VECTOR, irq_work), > > +#if IS_ENABLED(CONFIG_KVM) > SYSVEC(POSTED_INTR_VECTOR, kvm_posted_intr_ipi), > SYSVEC(POSTED_INTR_WAKEUP_VECTOR, kvm_posted_intr_wakeup_ipi), > SYSVEC(POSTED_INTR_NESTED_VECTOR, kvm_posted_intr_nested_ipi), > +#endif > }; > > static bool fred_setup_done __initdata; Hmm, we did test against !CONFIG_KVM. The POSTED_INTR_* macros are under CONFIG_HAVE_KVM, which is 'selected' under CONFIG_X86. Can you please send me your kernel config file?
On Thu, Feb 15, 2024 at 7:23 PM Xin Li <xin@zytor.com> wrote: > The POSTED_INTR_* macros are under CONFIG_HAVE_KVM, which is 'selected' > under CONFIG_X86. Sorry, I should have said that I found this bug on linux-next master, which has this commit: https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next/+/dcf0926e9b899eca754a07c4064de69815b85a38%5E%21/ . which changes CONFIG_HAVE_KVM to CONFIG_KVM. I was not aware that this commit hadn't been merged upstream yet. You can easily reproduce with with "defconfig" plus CONFIG_X86_FRED (on linux-next/master). Max
+Paolo and Stephen FYI, there's a build failure in -next due to a collision between kvm/next and tip/x86/fred. The above makes everything happy. On Thu, Feb 15, 2024, Max Kellermann wrote: > When KVM is disabled, the POSTED_INTR_* macros do not exist, and the > build fails. > > Fixes: 14619d912b65 ("x86/fred: FRED entry/exit and dispatch code") > Signed-off-by: Max Kellermann <max.kellermann@ionos.com> > --- > arch/x86/entry/entry_fred.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/x86/entry/entry_fred.c b/arch/x86/entry/entry_fred.c > index ac120cbdaaf2..660b7f7f9a79 100644 > --- a/arch/x86/entry/entry_fred.c > +++ b/arch/x86/entry/entry_fred.c > @@ -114,9 +114,11 @@ static idtentry_t sysvec_table[NR_SYSTEM_VECTORS] __ro_after_init = { > > SYSVEC(IRQ_WORK_VECTOR, irq_work), > > +#if IS_ENABLED(CONFIG_KVM) > SYSVEC(POSTED_INTR_VECTOR, kvm_posted_intr_ipi), > SYSVEC(POSTED_INTR_WAKEUP_VECTOR, kvm_posted_intr_wakeup_ipi), > SYSVEC(POSTED_INTR_NESTED_VECTOR, kvm_posted_intr_nested_ipi), > +#endif > }; > > static bool fred_setup_done __initdata; > -- > 2.39.2
On 2/15/2024 11:55 AM, Sean Christopherson wrote: > +Paolo and Stephen > > FYI, there's a build failure in -next due to a collision between kvm/next and > tip/x86/fred. The above makes everything happy. > > On Thu, Feb 15, 2024, Max Kellermann wrote: >> When KVM is disabled, the POSTED_INTR_* macros do not exist, and the >> build fails. >> >> Fixes: 14619d912b65 ("x86/fred: FRED entry/exit and dispatch code") >> Signed-off-by: Max Kellermann <max.kellermann@ionos.com> >> --- >> arch/x86/entry/entry_fred.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/arch/x86/entry/entry_fred.c b/arch/x86/entry/entry_fred.c >> index ac120cbdaaf2..660b7f7f9a79 100644 >> --- a/arch/x86/entry/entry_fred.c >> +++ b/arch/x86/entry/entry_fred.c >> @@ -114,9 +114,11 @@ static idtentry_t sysvec_table[NR_SYSTEM_VECTORS] __ro_after_init = { >> >> SYSVEC(IRQ_WORK_VECTOR, irq_work), >> >> +#if IS_ENABLED(CONFIG_KVM) >> SYSVEC(POSTED_INTR_VECTOR, kvm_posted_intr_ipi), >> SYSVEC(POSTED_INTR_WAKEUP_VECTOR, kvm_posted_intr_wakeup_ipi), >> SYSVEC(POSTED_INTR_NESTED_VECTOR, kvm_posted_intr_nested_ipi), >> +#endif >> }; >> >> static bool fred_setup_done __initdata; >> -- >> 2.39.2 > We want to minimize #ifdeffery (which is why we didn't add any to sysvec_table[]), would it be better to simply remove "#if IS_ENABLED(CONFIG_KVM)" around the the POSTED_INTR_* macros from the Linux-next tree? BTW, kvm_posted_intr_*() are defined to NULL if !IS_ENABLED(CONFIG_KVM). diff --git a/arch/x86/include/asm/irq_vectors.h b/arch/x86/include/asm/irq_vectors.h index 3a19904c2db6..d18bfb238f66 100644 --- a/arch/x86/include/asm/irq_vectors.h +++ b/arch/x86/include/asm/irq_vectors.h @@ -84,11 +84,9 @@ #define HYPERVISOR_CALLBACK_VECTOR 0xf3 /* Vector for KVM to deliver posted interrupt IPI */ -#if IS_ENABLED(CONFIG_KVM) #define POSTED_INTR_VECTOR 0xf2 #define POSTED_INTR_WAKEUP_VECTOR 0xf1 #define POSTED_INTR_NESTED_VECTOR 0xf0 -#endif #define MANAGED_IRQ_SHUTDOWN_VECTOR 0xef
On 2/16/24 03:10, Xin Li wrote: > On 2/15/2024 11:55 AM, Sean Christopherson wrote: >> +Paolo and Stephen >> >> FYI, there's a build failure in -next due to a collision between >> kvm/next and >> tip/x86/fred. The above makes everything happy. >> >> On Thu, Feb 15, 2024, Max Kellermann wrote: >>> When KVM is disabled, the POSTED_INTR_* macros do not exist, and the >>> build fails. >>> >>> Fixes: 14619d912b65 ("x86/fred: FRED entry/exit and dispatch code") >>> Signed-off-by: Max Kellermann <max.kellermann@ionos.com> >>> --- >>> arch/x86/entry/entry_fred.c | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/arch/x86/entry/entry_fred.c b/arch/x86/entry/entry_fred.c >>> index ac120cbdaaf2..660b7f7f9a79 100644 >>> --- a/arch/x86/entry/entry_fred.c >>> +++ b/arch/x86/entry/entry_fred.c >>> @@ -114,9 +114,11 @@ static idtentry_t >>> sysvec_table[NR_SYSTEM_VECTORS] __ro_after_init = { >>> SYSVEC(IRQ_WORK_VECTOR, irq_work), >>> +#if IS_ENABLED(CONFIG_KVM) >>> SYSVEC(POSTED_INTR_VECTOR, kvm_posted_intr_ipi), >>> SYSVEC(POSTED_INTR_WAKEUP_VECTOR, kvm_posted_intr_wakeup_ipi), >>> SYSVEC(POSTED_INTR_NESTED_VECTOR, kvm_posted_intr_nested_ipi), >>> +#endif >>> }; >>> static bool fred_setup_done __initdata; >>> -- >>> 2.39.2 > > We want to minimize #ifdeffery (which is why we didn't add any to > sysvec_table[]), would it be better to simply remove "#if > IS_ENABLED(CONFIG_KVM)" around the the POSTED_INTR_* macros from the > Linux-next tree? > > BTW, kvm_posted_intr_*() are defined to NULL if !IS_ENABLED(CONFIG_KVM). It is intentional that KVM-related things are compiled out completely if !IS_ENABLED(CONFIG_KVM), because then it's also not necessary to have # define fred_sysvec_kvm_posted_intr_ipi NULL # define fred_sysvec_kvm_posted_intr_wakeup_ipi NULL # define fred_sysvec_kvm_posted_intr_nested_ipi NULL in arch/x86/include/asm/idtentry.h. The full conflict resultion is diff --git a/arch/x86/entry/entry_fred.c b/arch/x86/entry/entry_fred.c index ac120cbdaaf2..660b7f7f9a79 100644 --- a/arch/x86/entry/entry_fred.c +++ b/arch/x86/entry/entry_fred.c @@ -114,9 +114,11 @@ static idtentry_t sysvec_table[NR_SYSTEM_VECTORS] __ro_after_init = { SYSVEC(IRQ_WORK_VECTOR, irq_work), +#if IS_ENABLED(CONFIG_KVM) SYSVEC(POSTED_INTR_VECTOR, kvm_posted_intr_ipi), SYSVEC(POSTED_INTR_WAKEUP_VECTOR, kvm_posted_intr_wakeup_ipi), SYSVEC(POSTED_INTR_NESTED_VECTOR, kvm_posted_intr_nested_ipi), +#endif }; static bool fred_setup_done __initdata; diff --git a/arch/x86/include/asm/idtentry.h b/arch/x86/include/asm/idtentry.h index 749c7411d2f1..758f6a2838a8 100644 --- a/arch/x86/include/asm/idtentry.h +++ b/arch/x86/include/asm/idtentry.h @@ -745,10 +745,6 @@ DECLARE_IDTENTRY_SYSVEC(IRQ_WORK_VECTOR, sysvec_irq_work); DECLARE_IDTENTRY_SYSVEC(POSTED_INTR_VECTOR, sysvec_kvm_posted_intr_ipi); DECLARE_IDTENTRY_SYSVEC(POSTED_INTR_WAKEUP_VECTOR, sysvec_kvm_posted_intr_wakeup_ipi); DECLARE_IDTENTRY_SYSVEC(POSTED_INTR_NESTED_VECTOR, sysvec_kvm_posted_intr_nested_ipi); -#else -# define fred_sysvec_kvm_posted_intr_ipi NULL -# define fred_sysvec_kvm_posted_intr_wakeup_ipi NULL -# define fred_sysvec_kvm_posted_intr_nested_ipi NULL #endif #if IS_ENABLED(CONFIG_HYPERV) and it seems to be a net improvement to me. The #ifs match in the .h and .c files, and there are no unnecessary initializers in the sysvec_table. Paolo
On 2/15/2024 10:31 PM, Paolo Bonzini wrote: > On 2/16/24 03:10, Xin Li wrote: >> On 2/15/2024 11:55 AM, Sean Christopherson wrote: >>> +Paolo and Stephen >>> >>> FYI, there's a build failure in -next due to a collision between >>> kvm/next and >>> tip/x86/fred. The above makes everything happy. >>> >>> On Thu, Feb 15, 2024, Max Kellermann wrote: >>>> When KVM is disabled, the POSTED_INTR_* macros do not exist, and the >>>> build fails. >>>> >>>> Fixes: 14619d912b65 ("x86/fred: FRED entry/exit and dispatch code") >>>> Signed-off-by: Max Kellermann <max.kellermann@ionos.com> >>>> --- >>>> arch/x86/entry/entry_fred.c | 2 ++ >>>> 1 file changed, 2 insertions(+) >>>> >>>> diff --git a/arch/x86/entry/entry_fred.c b/arch/x86/entry/entry_fred.c >>>> index ac120cbdaaf2..660b7f7f9a79 100644 >>>> --- a/arch/x86/entry/entry_fred.c >>>> +++ b/arch/x86/entry/entry_fred.c >>>> @@ -114,9 +114,11 @@ static idtentry_t >>>> sysvec_table[NR_SYSTEM_VECTORS] __ro_after_init = { >>>> SYSVEC(IRQ_WORK_VECTOR, irq_work), >>>> +#if IS_ENABLED(CONFIG_KVM) >>>> SYSVEC(POSTED_INTR_VECTOR, kvm_posted_intr_ipi), >>>> SYSVEC(POSTED_INTR_WAKEUP_VECTOR, kvm_posted_intr_wakeup_ipi), >>>> SYSVEC(POSTED_INTR_NESTED_VECTOR, kvm_posted_intr_nested_ipi), >>>> +#endif >>>> }; >>>> static bool fred_setup_done __initdata; >>>> -- >>>> 2.39.2 >> >> We want to minimize #ifdeffery (which is why we didn't add any to >> sysvec_table[]), would it be better to simply remove "#if >> IS_ENABLED(CONFIG_KVM)" around the the POSTED_INTR_* macros from the >> Linux-next tree? >> >> BTW, kvm_posted_intr_*() are defined to NULL if !IS_ENABLED(CONFIG_KVM). > > It is intentional that KVM-related things are compiled out completely > if !IS_ENABLED(CONFIG_KVM), In arch/x86/include/asm/irq_vectors.h, most vector definitions are not under any #ifdeffery, e.g., THERMAL_APIC_VECTOR not under CONFIG_X86_THERMAL_VECTOR and IRQ_WORK_VECTOR not under CONFIG_IRQ_WORK. We'd better make all of them consistent, and the question is that should we add #ifdefs or not. > because then it's also not necessary to have > > # define fred_sysvec_kvm_posted_intr_ipi NULL > # define fred_sysvec_kvm_posted_intr_wakeup_ipi NULL > # define fred_sysvec_kvm_posted_intr_nested_ipi NULL > > in arch/x86/include/asm/idtentry.h. The full conflict resultion is > > diff --git a/arch/x86/entry/entry_fred.c b/arch/x86/entry/entry_fred.c > index ac120cbdaaf2..660b7f7f9a79 100644 > --- a/arch/x86/entry/entry_fred.c > +++ b/arch/x86/entry/entry_fred.c > @@ -114,9 +114,11 @@ static idtentry_t sysvec_table[NR_SYSTEM_VECTORS] > __ro_after_init = { > > SYSVEC(IRQ_WORK_VECTOR, irq_work), > > +#if IS_ENABLED(CONFIG_KVM) > SYSVEC(POSTED_INTR_VECTOR, kvm_posted_intr_ipi), > SYSVEC(POSTED_INTR_WAKEUP_VECTOR, kvm_posted_intr_wakeup_ipi), > SYSVEC(POSTED_INTR_NESTED_VECTOR, kvm_posted_intr_nested_ipi), > +#endif > }; > > static bool fred_setup_done __initdata; > diff --git a/arch/x86/include/asm/idtentry.h > b/arch/x86/include/asm/idtentry.h > index 749c7411d2f1..758f6a2838a8 100644 > --- a/arch/x86/include/asm/idtentry.h > +++ b/arch/x86/include/asm/idtentry.h > @@ -745,10 +745,6 @@ DECLARE_IDTENTRY_SYSVEC(IRQ_WORK_VECTOR, > sysvec_irq_work); > DECLARE_IDTENTRY_SYSVEC(POSTED_INTR_VECTOR, > sysvec_kvm_posted_intr_ipi); > DECLARE_IDTENTRY_SYSVEC(POSTED_INTR_WAKEUP_VECTOR, > sysvec_kvm_posted_intr_wakeup_ipi); > DECLARE_IDTENTRY_SYSVEC(POSTED_INTR_NESTED_VECTOR, > sysvec_kvm_posted_intr_nested_ipi); > -#else > -# define fred_sysvec_kvm_posted_intr_ipi NULL > -# define fred_sysvec_kvm_posted_intr_wakeup_ipi NULL > -# define fred_sysvec_kvm_posted_intr_nested_ipi NULL > #endif > > #if IS_ENABLED(CONFIG_HYPERV) > > and it seems to be a net improvement to me. The #ifs match in > the .h and .c files, and there are no unnecessary initializers > in the sysvec_table. > I somehow get an impression that the x86 maintainers don't like #ifs in the .c files, but I could be just wrong. Thanks! Xin
On 2/16/2024 9:41 AM, Xin Li wrote: > On 2/15/2024 10:31 PM, Paolo Bonzini wrote: >> On 2/16/24 03:10, Xin Li wrote: >>> On 2/15/2024 11:55 AM, Sean Christopherson wrote: >>>> +Paolo and Stephen >>>> >>>> FYI, there's a build failure in -next due to a collision between >>>> kvm/next and >>>> tip/x86/fred. The above makes everything happy. >>>> >>>> On Thu, Feb 15, 2024, Max Kellermann wrote: >>>>> When KVM is disabled, the POSTED_INTR_* macros do not exist, and the >>>>> build fails. >>>>> >>>>> Fixes: 14619d912b65 ("x86/fred: FRED entry/exit and dispatch code") >>>>> Signed-off-by: Max Kellermann <max.kellermann@ionos.com> >>>>> --- >>>>> arch/x86/entry/entry_fred.c | 2 ++ >>>>> 1 file changed, 2 insertions(+) >>>>> >>>>> diff --git a/arch/x86/entry/entry_fred.c b/arch/x86/entry/entry_fred.c >>>>> index ac120cbdaaf2..660b7f7f9a79 100644 >>>>> --- a/arch/x86/entry/entry_fred.c >>>>> +++ b/arch/x86/entry/entry_fred.c >>>>> @@ -114,9 +114,11 @@ static idtentry_t >>>>> sysvec_table[NR_SYSTEM_VECTORS] __ro_after_init = { >>>>> SYSVEC(IRQ_WORK_VECTOR, irq_work), >>>>> +#if IS_ENABLED(CONFIG_KVM) >>>>> SYSVEC(POSTED_INTR_VECTOR, kvm_posted_intr_ipi), >>>>> SYSVEC(POSTED_INTR_WAKEUP_VECTOR, >>>>> kvm_posted_intr_wakeup_ipi), >>>>> SYSVEC(POSTED_INTR_NESTED_VECTOR, >>>>> kvm_posted_intr_nested_ipi), >>>>> +#endif >>>>> }; >>>>> static bool fred_setup_done __initdata; >>>>> -- >>>>> 2.39.2 >>> >>> We want to minimize #ifdeffery (which is why we didn't add any to >>> sysvec_table[]), would it be better to simply remove "#if >>> IS_ENABLED(CONFIG_KVM)" around the the POSTED_INTR_* macros from the >>> Linux-next tree? >>> >>> BTW, kvm_posted_intr_*() are defined to NULL if !IS_ENABLED(CONFIG_KVM). >> >> It is intentional that KVM-related things are compiled out completely >> if !IS_ENABLED(CONFIG_KVM), > > In arch/x86/include/asm/irq_vectors.h, most vector definitions are not > under any #ifdeffery, e.g., THERMAL_APIC_VECTOR not under > CONFIG_X86_THERMAL_VECTOR and IRQ_WORK_VECTOR not under CONFIG_IRQ_WORK. > > We'd better make all of them consistent, and the question is that should > we add #ifdefs or not. > >> because then it's also not necessary to have >> >> # define fred_sysvec_kvm_posted_intr_ipi NULL >> # define fred_sysvec_kvm_posted_intr_wakeup_ipi NULL >> # define fred_sysvec_kvm_posted_intr_nested_ipi NULL >> >> in arch/x86/include/asm/idtentry.h. The full conflict resultion is >> >> diff --git a/arch/x86/entry/entry_fred.c b/arch/x86/entry/entry_fred.c >> index ac120cbdaaf2..660b7f7f9a79 100644 >> --- a/arch/x86/entry/entry_fred.c >> +++ b/arch/x86/entry/entry_fred.c >> @@ -114,9 +114,11 @@ static idtentry_t sysvec_table[NR_SYSTEM_VECTORS] >> __ro_after_init = { >> >> SYSVEC(IRQ_WORK_VECTOR, irq_work), >> >> +#if IS_ENABLED(CONFIG_KVM) >> SYSVEC(POSTED_INTR_VECTOR, kvm_posted_intr_ipi), >> SYSVEC(POSTED_INTR_WAKEUP_VECTOR, kvm_posted_intr_wakeup_ipi), >> SYSVEC(POSTED_INTR_NESTED_VECTOR, kvm_posted_intr_nested_ipi), >> +#endif >> }; >> >> static bool fred_setup_done __initdata; >> diff --git a/arch/x86/include/asm/idtentry.h >> b/arch/x86/include/asm/idtentry.h >> index 749c7411d2f1..758f6a2838a8 100644 >> --- a/arch/x86/include/asm/idtentry.h >> +++ b/arch/x86/include/asm/idtentry.h >> @@ -745,10 +745,6 @@ DECLARE_IDTENTRY_SYSVEC(IRQ_WORK_VECTOR, >> sysvec_irq_work); >> DECLARE_IDTENTRY_SYSVEC(POSTED_INTR_VECTOR, >> sysvec_kvm_posted_intr_ipi); >> DECLARE_IDTENTRY_SYSVEC(POSTED_INTR_WAKEUP_VECTOR, >> sysvec_kvm_posted_intr_wakeup_ipi); >> DECLARE_IDTENTRY_SYSVEC(POSTED_INTR_NESTED_VECTOR, >> sysvec_kvm_posted_intr_nested_ipi); >> -#else >> -# define fred_sysvec_kvm_posted_intr_ipi NULL >> -# define fred_sysvec_kvm_posted_intr_wakeup_ipi NULL >> -# define fred_sysvec_kvm_posted_intr_nested_ipi NULL >> #endif >> >> #if IS_ENABLED(CONFIG_HYPERV) >> >> and it seems to be a net improvement to me. The #ifs match in >> the .h and .c files, and there are no unnecessary initializers >> in the sysvec_table. >> > > I somehow get an impression that the x86 maintainers don't like #ifs in > the .c files, but I could be just wrong. > Here is an example, but again my interpretation could just be wrong: #ifdef CONFIG_X86_FRED void fred_install_sysvec(unsigned int vector, const idtentry_t function); #else static inline void fred_install_sysvec(unsigned int vector, const idtentry_t function) { } #endif #define sysvec_install(vector, function) { \ if (cpu_feature_enabled(X86_FEATURE_FRED)) \ fred_install_sysvec(vector, function); \ else \ idt_install_sysvec(vector, asm_##function); \ }
On Fri, Feb 16 2024 at 07:31, Paolo Bonzini wrote: > On 2/16/24 03:10, Xin Li wrote: > > It is intentional that KVM-related things are compiled out completely > if !IS_ENABLED(CONFIG_KVM), because then it's also not necessary to > have That's a matter of taste. In both cases _ALL_ KVM related things are compiled out. #ifdeffing out the vector numbers is silly to begin with because these vector numbers stay assigned to KVM whether KVM is enabled or not. And no, I don't think it's a net win to have the #ifdeffery in that table. Look at apic_idts[] in arch/x86/kernel/idt.c how this ends up looking. It's unreadable gunk. The few NULL defines in a header file next to the real stuff #if IS_ENABLED(CONFIG_KVM) .... #else # define fred_sysvec_kvm_posted_intr_ipi NULL # define fred_sysvec_kvm_posted_intr_wakeup_ipi NULL # define fred_sysvec_kvm_posted_intr_nested_ipi NULL #endif are not hurting at all and they are at a place where #ifdeffery is required anyway. That's a very common pattern all over the kernel and it limits the #ifdef horror to _ONE_ place. With your change you propagate the #ifdefffery to the multiple and the very wrong places for absolutely zero practical value. The resulting binary code is exactly the same for the price of tasteless #ifdeffery in places where it matters. Please get rid of this #ifdef in the vector header and don't inflict bad taste on everyone. Thanks, tglx
+ Arnd for https://lore.kernel.org/r/20240216202527.2493264-1-arnd@kernel.org On Fri, Feb 16, 2024 at 07:31:46AM +0100, Paolo Bonzini wrote: > On 2/16/24 03:10, Xin Li wrote: > > On 2/15/2024 11:55 AM, Sean Christopherson wrote: > > > +Paolo and Stephen > > > > > > FYI, there's a build failure in -next due to a collision between > > > kvm/next and > > > tip/x86/fred. The above makes everything happy. > > > > > > On Thu, Feb 15, 2024, Max Kellermann wrote: > > > > When KVM is disabled, the POSTED_INTR_* macros do not exist, and the > > > > build fails. > > > > > > > > Fixes: 14619d912b65 ("x86/fred: FRED entry/exit and dispatch code") > > > > Signed-off-by: Max Kellermann <max.kellermann@ionos.com> > > > > --- > > > > arch/x86/entry/entry_fred.c | 2 ++ > > > > 1 file changed, 2 insertions(+) > > > > > > > > diff --git a/arch/x86/entry/entry_fred.c b/arch/x86/entry/entry_fred.c > > > > index ac120cbdaaf2..660b7f7f9a79 100644 > > > > --- a/arch/x86/entry/entry_fred.c > > > > +++ b/arch/x86/entry/entry_fred.c > > > > @@ -114,9 +114,11 @@ static idtentry_t > > > > sysvec_table[NR_SYSTEM_VECTORS] __ro_after_init = { > > > > SYSVEC(IRQ_WORK_VECTOR, irq_work), > > > > +#if IS_ENABLED(CONFIG_KVM) > > > > SYSVEC(POSTED_INTR_VECTOR, kvm_posted_intr_ipi), > > > > SYSVEC(POSTED_INTR_WAKEUP_VECTOR, kvm_posted_intr_wakeup_ipi), > > > > SYSVEC(POSTED_INTR_NESTED_VECTOR, kvm_posted_intr_nested_ipi), > > > > +#endif > > > > }; > > > > static bool fred_setup_done __initdata; > > > > -- > > > > 2.39.2 > > > > We want to minimize #ifdeffery (which is why we didn't add any to > > sysvec_table[]), would it be better to simply remove "#if > > IS_ENABLED(CONFIG_KVM)" around the the POSTED_INTR_* macros from the > > Linux-next tree? > > > > BTW, kvm_posted_intr_*() are defined to NULL if !IS_ENABLED(CONFIG_KVM). > > It is intentional that KVM-related things are compiled out completely > if !IS_ENABLED(CONFIG_KVM), because then it's also not necessary to have > > # define fred_sysvec_kvm_posted_intr_ipi NULL > # define fred_sysvec_kvm_posted_intr_wakeup_ipi NULL > # define fred_sysvec_kvm_posted_intr_nested_ipi NULL > > in arch/x86/include/asm/idtentry.h. The full conflict resultion is > > diff --git a/arch/x86/entry/entry_fred.c b/arch/x86/entry/entry_fred.c > index ac120cbdaaf2..660b7f7f9a79 100644 > --- a/arch/x86/entry/entry_fred.c > +++ b/arch/x86/entry/entry_fred.c > @@ -114,9 +114,11 @@ static idtentry_t sysvec_table[NR_SYSTEM_VECTORS] __ro_after_init = { > SYSVEC(IRQ_WORK_VECTOR, irq_work), > +#if IS_ENABLED(CONFIG_KVM) > SYSVEC(POSTED_INTR_VECTOR, kvm_posted_intr_ipi), > SYSVEC(POSTED_INTR_WAKEUP_VECTOR, kvm_posted_intr_wakeup_ipi), > SYSVEC(POSTED_INTR_NESTED_VECTOR, kvm_posted_intr_nested_ipi), > +#endif > }; > static bool fred_setup_done __initdata; > diff --git a/arch/x86/include/asm/idtentry.h b/arch/x86/include/asm/idtentry.h > index 749c7411d2f1..758f6a2838a8 100644 > --- a/arch/x86/include/asm/idtentry.h > +++ b/arch/x86/include/asm/idtentry.h > @@ -745,10 +745,6 @@ DECLARE_IDTENTRY_SYSVEC(IRQ_WORK_VECTOR, sysvec_irq_work); > DECLARE_IDTENTRY_SYSVEC(POSTED_INTR_VECTOR, sysvec_kvm_posted_intr_ipi); > DECLARE_IDTENTRY_SYSVEC(POSTED_INTR_WAKEUP_VECTOR, sysvec_kvm_posted_intr_wakeup_ipi); > DECLARE_IDTENTRY_SYSVEC(POSTED_INTR_NESTED_VECTOR, sysvec_kvm_posted_intr_nested_ipi); > -#else > -# define fred_sysvec_kvm_posted_intr_ipi NULL > -# define fred_sysvec_kvm_posted_intr_wakeup_ipi NULL > -# define fred_sysvec_kvm_posted_intr_nested_ipi NULL > #endif > #if IS_ENABLED(CONFIG_HYPERV) > > and it seems to be a net improvement to me. The #ifs match in > the .h and .c files, and there are no unnecessary initializers > in the sysvec_table. Ok, I'll pick up Max' patch tomorrow and we must remember to tell Linus during the merge window about this. Thx.
On Fri, Feb 16 2024 at 22:46, Borislav Petkov wrote: > On Fri, Feb 16, 2024 at 07:31:46AM +0100, Paolo Bonzini wrote: >> and it seems to be a net improvement to me. The #ifs match in >> the .h and .c files, and there are no unnecessary initializers >> in the sysvec_table. > > Ok, I'll pick up Max' patch tomorrow and we must remember to tell Linus > during the merge window about this. No. Don't. This pointless #ifdeffery in the vector header needs to vanish from the KVM tree. Why would you take the #ifdef mess into tasteful code just because someone decided that #ifdeffing out constants in a header which is maintained by other people is a brilliant idea? The #ifdeffery in the idtentry header is unavoidable and the extra NULL defines are at the right place and not making the actual code unreadable. Thanks, tglx
On Fri, Feb 16, 2024 at 10:45 PM Thomas Gleixner <tglx@linutronix.de> wrote: > #ifdeffing out the vector numbers is silly to begin with because these > vector numbers stay assigned to KVM whether KVM is enabled or not. There could be one non-silly use of this: if the macros are not defined in absence of the feature, any use of it will lead to a compiler error, which is good, because it may reveal certain kinds of bugs. (Though I agree that this isn't worth the code ugliness. I prefer to avoid the preprocessor whenever possible. I hate how much the kernel uses macros instead of inline functions.)
On Sat, Feb 17 2024 at 00:00, Max Kellermann wrote: > On Fri, Feb 16, 2024 at 10:45 PM Thomas Gleixner <tglx@linutronixde> wrote: >> #ifdeffing out the vector numbers is silly to begin with because these >> vector numbers stay assigned to KVM whether KVM is enabled or not. > > There could be one non-silly use of this: if the macros are not > defined in absence of the feature, any use of it will lead to a > compiler error, which is good, because it may reveal certain kinds of > bugs. I generally agree with this sentiment, but for constants like those in the case at hand I really draw the line. > (Though I agree that this isn't worth the code ugliness. I prefer to > avoid the preprocessor whenever possible. I hate how much the kernel > uses macros instead of inline functions.) No argument about that. I'm urging people to use inlines instead of macros where ever possible, but there are things which can only solved by macros. I'm well aware that I wrote some of the more ugly ones myself. Though the end justifies the means. If the ugly macro from hell which you verify once safes you from the horrors of copy & pasta error hell then they are making the code better and there are plenty of options to make them reasonably (type) safe if done right. Thanks, tglx
On Fri, Feb 16, 2024 at 10:45 PM Thomas Gleixner <tglx@linutronix.de> wrote: > > On Fri, Feb 16 2024 at 07:31, Paolo Bonzini wrote: > > On 2/16/24 03:10, Xin Li wrote: > > > > It is intentional that KVM-related things are compiled out completely > > if !IS_ENABLED(CONFIG_KVM), because then it's also not necessary to > > have > > That's a matter of taste. In both cases _ALL_ KVM related things are > compiled out. > > #ifdeffing out the vector numbers is silly to begin with because these > vector numbers stay assigned to KVM whether KVM is enabled or not. No problem---it seems that I misunderstood or read too much into the usage of CONFIG_HAVE_KVM up to 6.8, so I'm happy to follow whatever FRED support did for thermal vector and the like, and remove the #ifdef for the vector numbers. Paolo
On Sat, Feb 17 2024 at 10:52, Paolo Bonzini wrote: > On Fri, Feb 16, 2024 at 10:45 PM Thomas Gleixner <tglx@linutronixde> wrote: >> #ifdeffing out the vector numbers is silly to begin with because these >> vector numbers stay assigned to KVM whether KVM is enabled or not. > > No problem---it seems that I misunderstood or read too much into the > usage of CONFIG_HAVE_KVM up to 6.8, so I'm happy to follow whatever > FRED support did for thermal vector and the like, and remove the > #ifdef for the vector numbers. Thank you! Appreciated! tglx
diff --git a/arch/x86/entry/entry_fred.c b/arch/x86/entry/entry_fred.c index ac120cbdaaf2..660b7f7f9a79 100644 --- a/arch/x86/entry/entry_fred.c +++ b/arch/x86/entry/entry_fred.c @@ -114,9 +114,11 @@ static idtentry_t sysvec_table[NR_SYSTEM_VECTORS] __ro_after_init = { SYSVEC(IRQ_WORK_VECTOR, irq_work), +#if IS_ENABLED(CONFIG_KVM) SYSVEC(POSTED_INTR_VECTOR, kvm_posted_intr_ipi), SYSVEC(POSTED_INTR_WAKEUP_VECTOR, kvm_posted_intr_wakeup_ipi), SYSVEC(POSTED_INTR_NESTED_VECTOR, kvm_posted_intr_nested_ipi), +#endif }; static bool fred_setup_done __initdata;