From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f201.google.com (mail-pg1-f201.google.com [209.85.215.201]) (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 AA00D3BB5A for ; Wed, 4 Feb 2026 00:00:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770163228; cv=none; b=uv4n/oQVmlles8iiPfid+4Q9YkBpflMFY1YQZvdefcDUGOFDy+EqOM69nNAhto4B1E7bMvuxr0yfCRpHk+z8j1ec1xAmwmPRsXNK3YeHUR1Zh8UOhs7JHyhDv1oneGw+1U0t/UjQ+AbZQd5AOlumwUNILWm5JIxIwSV5TL/w/bo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770163228; c=relaxed/simple; bh=GIxDdFOXqZ0emnzPe4xyIEpY72QJVX4bBP5UXthDkxI=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=pVrOhViwFsjS6SlY3zBEWCHVe+fCeYGKarIri/df5r+9x6aPt2ejMVu3YF1l+HSB41ZJry6g19/jE43h6V0ZXuQOLsOTNCwb8CNQ7Ym4Nk8vrmID4ylf2F2+SPLHctx+r3Qu9I2TFdXhNpb1I4yulArGRRJNmBL6I7LBB0OOOWw= 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=elHSeXsZ; arc=none smtp.client-ip=209.85.215.201 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="elHSeXsZ" Received: by mail-pg1-f201.google.com with SMTP id 41be03b00d2f7-c68b97b7316so2092490a12.3 for ; Tue, 03 Feb 2026 16:00:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1770163226; x=1770768026; 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=SVnZ/cwtK4ji87rGWMAM2IituVZDG+uyyOJMD4ekd58=; b=elHSeXsZozI6aFqSxGGKSRhgT0BZzM2EDdktGJPbSvD1qMpOH2nLBHlrNxpQmE3jpT aqTmyRvR2GD4mhVC7Y2aUQeacKiQFSJVjOwNhktcrb5+SfzbAlo5Yy97c1EVcqWTUoEM LH79bToXbAqDramDLN/X/Uz8Jg59PcrsT+pjIqL5TF7VqTdGeKEbzoI9m4xX1YHxzIrB GsU0hbXr6cF0KbumisAlEOdXktRkf465rbBv+oKA44y1/3CqCAnwrrzdGFI1SXiuFJue OblUnRNIdgnVtGV4VRp4lsysoQAlNsEEYJ6qZL1R4XVEOMJiGMDnSxUCmkT+SsN5mMky yuKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770163226; x=1770768026; 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=SVnZ/cwtK4ji87rGWMAM2IituVZDG+uyyOJMD4ekd58=; b=lkAFkAVblqv1lGxyG5ji2HR7Zx9PPUAk75OpvI8Fiqp+0u96mI6TkmsjzU2TjSLXiP jvedlYvqm5JlzsndGj+dZEacSrvPwEAcV48kHVTQ3gi5CV9eLJ9MJfplPV5TWDCwA1oJ Q6Jws/tQ920PwHb0xKGM+x+sW9yLP/lomdBNrwRPsc4ospd3bRPlcDIvNbE5Be2idlin 39jeubr0FlWtWRESbwhzc6YoA3C11vzRPEMdF9KpBjMTvdGBRQpRLDVJTRDD8ZAxxwUl u7C6SWksCphJCeJsntdZ6RaGw0RDk0wjwRqyS8AUtIIt9ceS5UZkSVxFz6MpGUXZIBHv XU9A== X-Forwarded-Encrypted: i=1; AJvYcCWC+CTp9frfr6YLfzdpA59/Y7HyXhIYsJ/+IlwUq/DGVAwIp5yBShCm1Dda0ftA2nNwBAysGXSdUMVkWgU=@vger.kernel.org X-Gm-Message-State: AOJu0YwDO51OWyFob6A3+zeuK/2mHygwftsVzK65kpzTF5HpsqaxZjCV 5sIPB+Q7yvrixb+fYKt1ufML0NmwDtcEpXZwUVj6hUF8/G4SfRX/wnXwWXuCkXUuIJXIR525dlw 8U0bMpQ== X-Received: from plbkg12.prod.google.com ([2002:a17:903:60c:b0:29f:25b4:4dc4]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a21:1805:b0:38e:87b7:5f88 with SMTP id adf61e73a8af0-3937210bb2emr1114819637.27.1770163225959; Tue, 03 Feb 2026 16:00:25 -0800 (PST) Date: Tue, 3 Feb 2026 16:00:24 -0800 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20251229111708.59402-1-khushit.shah@nutanix.com> <83f9b0a5dd0bc1de9d1e61954f6dd5211df45163.camel@infradead.org> Message-ID: Subject: Re: [PATCH v5 4/3] KVM: selftests: Add test cases for EOI suppression modes From: Sean Christopherson To: David Woodhouse Cc: Khushit Shah , pbonzini@redhat.com, kai.huang@intel.com, mingo@redhat.com, x86@kernel.org, bp@alien8.de, hpa@zytor.com, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, dave.hansen@linux.intel.com, tglx@linutronix.de, jon@nutanix.com, shaju.abraham@nutanix.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 29, 2026, David Woodhouse wrote: > On Thu, 2026-01-29 at 07:19 -0800, Sean Christopherson wrote: > > On Wed, Jan 28, 2026, David Woodhouse wrote: > > > From: David Woodhouse > > >=20 > > > Rather than being frightened of doing the right thing for the in-kern= el > > > I/O APIC because "there might be bugs",=20 > >=20 > > I'm not worried about bugs per se, I'm worried about breaking existing = guests. > > Even if KVM is 100% perfect, changes in behavior can still break guests= , > > especially for a feature like this where it seems like everyone got it = wrong. >=20 > There's the potential for guest bugs when the local APIC actually > starts honouring the DIRECTED_EOI bit in the SPIV register, sure. At > that point, the guest *has* to do the direct EOI (and it has to work). >=20 > But that's why we kept the 'quirk' mode as the default unless userspace > explicitly opts in. And it's true for the split-irqchip too; fixing the > behaviour is the whole point of this exercise. >=20 > I don't see why supporting precisely the same behaviour in the kernel > irqchip is any different in that respect. Conceptually, nothing. But fixing the in-kernel I/O APIC is more invasive,= it's not currently broken (KVM doesn't advertise DIRECTED_EOI or SUPPRESS_EOI_BR= OADCAST), no one is lining up to actually utilizes the functionality, *and* there are= some historical warts in KVM that need to be addressed. Add it all up, and for me at least, the risk vs. reward is very different f= or split vs. fully in-kernel irqchips. > > And as I said before, I'm not opposed to supporting directed EOI in the= in-kernel > > I/O APIC, but (a) I don't want to do it in conjunction with the fixes f= or stable@, > > and (b) I'd prefer to not bother unless there's an actual use case for = doing so. > > The in-kernel I/O APIC isn't being deprecated, but AFAIK it's being de-= prioritized > > by pretty much every VMM.=C2=A0 I.e. the risk vs. reward isn't there fo= r me. >=20 > I tend to favour the simplicity, with _ENABLE and _DISABLE just quietly > doing what their name implies without any of that nonsense about > "except if you have a kernel irqchip". But they _don't_ do what their name implies if there's no in-kernel local A= PIC. I.e. userspace needs to read the docs and do the right thing anyways. > But as you wish. Most of this test case should be fine on v6 of the > patch which dropped in-kernel I/O APIC support. All the tests are > conditional on the corresponding support being advertised, so it just > needs updating to correctly detect the in-kernel _ENABLE support in > case that does get added. How did we say we would advertise that? A doc update plus this: diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 67e666921a12..d711493f9c69 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -4934,7 +4934,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, lon= g ext) break; case KVM_CAP_X2APIC_API: r =3D KVM_X2APIC_API_VALID_FLAGS; - if (kvm && !irqchip_split(kvm)) + if (kvm && !irqchip_in_kernel(kvm)) r &=3D ~KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST; break; case KVM_CAP_NESTED_STATE: