linux-kernel - RE: [EXTERNAL] Re: [RFC 1/1] irqchip/gic-v3-its: Add irq domain and chip for Direct LPI without ITS

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: <MW4PR21MB2002ABD170CC9786CDF5D493C0F39@MW4PR21MB2002.namprd21.prod.outlook.com>
Date:   Fri, 6 Aug 2021 19:14:13 +0000
From:   Sunil Muthuswamy <sunilmut@...rosoft.com>
To:     Marc Zyngier <maz@...nel.org>
CC:     Robin Murphy <robin.murphy@....com>,
        Thomas Gleixner <tglx@...utronix.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "catalin.marinas@....com" <catalin.marinas@....com>,
        "will@...nel.org" <will@...nel.org>,
        Michael Kelley <mikelley@...rosoft.com>,
        Boqun Feng <Boqun.Feng@...rosoft.com>,
        KY Srinivasan <kys@...rosoft.com>,
        Arnd Bergmann <arnd@...db.de>
Subject: RE: [EXTERNAL] Re: [RFC 1/1] irqchip/gic-v3-its: Add irq domain and
 chip for Direct LPI without ITS

On Thursday, August 5, 2021 1:35 AM,
Marc Zyngier <maz@...nel.org> wrote:
[...]
> > Hey Mark
> 
> I assume this is for me?
> 
Yes, sorry.

> > would you be willing to consider a scoped down implementation of GIC
> > Direct LPI with just an IRQ chip implementation and no Direct LPI
> > PCI-MSI IRQ chip.
> 
> Could you please clarify? If you are not implementing MSIs, how can a
> device signal LPIs? At the end of the day, something has to write into
> the RD, and it isn't going to happen by sheer magic.
> 
> > This will allow a MSI provider (such as Hyper-V vPCI) to provide a
> > PCI-MSI IRQ chip on top of the Direct LPI IRQ chip and enable
> > PCI-MSI scenarios, and avoid building in assumptions in other cases
> > (like PCI) where firmware specification is not available.
> 
> I really don't get what you are suggesting. Could you please describe
> what you have in mind?
> 
The suggestion was to *not* implement the PCI-MSI IRQ chip in the
Direct LPI GIC implementation, but let the endpoint/specific
implementation provide for the MSI IRQ chip.

For example, the Hyper-V vPCI module does implement a PCI-MSI IRQ
chip (refer to 'hv_pcie_init_irq_domain'). Microsoft Hypervisor
provides/virtualizes the MSI address to be used for Hyper-V vPCI. The
Hypervisor might be using the ITS in the background, but it expects
the device to be programmed with the MSI address that it provides.
And, the Hypervisor takes care of routing the interrupt to the guest.
This is done by the Hyper-V vPCI MSI IRQ chip (refer to
hv_msi_irq_chip) compose MSI message.

Today, for X64, Hyper-V vPCI PCI-MSI irq chip parents itself to the
architectural 'x86_vector_domain'. The suggestion here was to see
if we can support a similar setup for ARM, where the Hyper-V vPCI
PCI-MSI irq chip can parent itself to the 'Direct LPI arch IRQ chip'
(to be implemented).

The arch Direct LPI arch IRQ chip is needed to enable LPIs, invalidate
the LPI configuration (GICR_INVLPIR et. al. ) and allocate LPI IRQs from
the LPI interrupt namespace (i.e. 8192-<num LPIS>).

Happy to expand on this further, if the above is not clear.

Thanks,
Sunil