linux-kernel - Re: [PATCH 11/15] KVM: x86: Add CONFIG_KVM_IOAPIC to allow disabling in-kernel I/O APIC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <58a580b0f3274f6a7bba8431b2a6e6fef152b237.camel@intel.com>
Date: Thu, 29 May 2025 22:51:14 +0000
From: "Huang, Kai" <kai.huang@...el.com>
To: "seanjc@...gle.com" <seanjc@...gle.com>
CC: "kvm@...r.kernel.org" <kvm@...r.kernel.org>, "pbonzini@...hat.com"
	<pbonzini@...hat.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "vkuznets@...hat.com" <vkuznets@...hat.com>
Subject: Re: [PATCH 11/15] KVM: x86: Add CONFIG_KVM_IOAPIC to allow disabling
 in-kernel I/O APIC

On Thu, 2025-05-29 at 07:31 -0700, Sean Christopherson wrote:
> On Thu, May 29, 2025, Kai Huang wrote:
> > On Thu, 2025-05-29 at 23:55 +1200, Kai Huang wrote:
> > > On Mon, 2025-05-19 at 16:28 -0700, Sean Christopherson wrote:
> > > > Add a Kconfig to allowing building KVM without support for emulating an
> > > 		   ^
> > > 		   allow
> > > 
> > > > I/O APIC, PIC, and PIT, which is desirable for deployments that effectively
> > > > don't support a fully in-kernel IRQ chip, i.e. never expect any VMM to
> > > > create an in-kernel I/O APIC.  
> > > 
> > > Do you happen to know what developments don't support a full in-kernel IRQ chip?
> 
> Google Cloud, for one.  I suspect/assume many/most CSPs don't utilize an in-kernel
> I/O APIC.
> 
> > > Do they only support userspace IRQ chip, or not support any IRQ chip at all?
> 
> The former, only userspace I/O APIC (and associated devices), though some VM
> shapes, e.g. TDX, don't provide an I/O APIC or PIC.

Thanks for the info.

Just wondering what's the benefit of using userspace IRQCHIP instead of
emulating in the kernel?  I thought one should either use in-kernel IRQCHIP or
doesn't use any.

> 
> > Forgot to ask:
> > 
> > Since this new Kconfig option is not only for IOAPIC but also includes PIC and
> > PIT, is CONFIG_KVM_IRQCHIP a better name?
> 
> I much prefer IOAPIC, because IRQCHIP is far too ambiguous and confusing, e.g.
> just look at KVM's internal APIs, where these:
> 
>   irqchip_in_kernel()
>   irqchip_kernel()
> 
> are not equivalent.  In practice, no modern guest kernel is going to utilize the
> PIC, and the PIT isn't an IRQ chip, i.e. isn't strictly covered by IRQCHIP either.

Right.

Maybe it is worth to further have dedicated Kconfig for PIC, PIT and IOAPIC?

But hmm, I am not sure whether emulating IOAPIC has more value than PIC.  For
modern guests all emulated/assigned devices should just use MSI/MSI-X?

> So I think/hope the vast majority of users/readers will be able to intuit that
> CONFIG_KVM_IOAPIC also covers the PIC and PIT.

Sure.

Btw, I also find irqchip_in_kernel() and irqchip_kernel() confusing.  I am not
sure the value of having irqchip_in_kernel() in fact.  The guest should always
have an in-kernel APIC for modern guests.  I am wondering whether we can get rid
of it completely (the logic will be it is always be true), or we can have a
Kconfig to only build it when user truly wants it.