linux-kernel - Re: [RFC 0/2] irqchip/gic-v3-its: Introduce virtual 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] [day] [month] [year] [list]

Date:   Tue, 22 Jun 2021 18:32:47 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     Boqun Feng <boqun.feng@...il.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org,
        Arnd Bergmann <arnd@...db.de>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>
Subject: Re: [RFC 0/2] irqchip/gic-v3-its: Introduce virtual ITS

On Tue, 22 Jun 2021 16:53:11 +0100,
Boqun Feng <boqun.feng@...il.com> wrote:
> 
> Hi Marc,
> 
> Here is an RFC for supporting platforms having LPI supported but without
> ITS. And this is for the virtual PCI support for ARM64 Hyper-V guests.
> We currently choose this approach (LPI w/o ITS) because a) it's allowed
> for GICv3 and b) ITS may not be a more efficient way to configure LPIs
> compared to hypercalls, but we'd like to get feedbacks from the
> community.
> 
> Besides, patch #1 fixes a bug which I found while I was at it.
> 
> Looking forwards to any comment and suggestion!

My suggestion is to not do that. The ITS driver is used to drive an
ITS. That, and only that. The simple fact that you mention hypercalls
shows that this is *not* what the architecture allows.

So if you are going to implement something that is evidently outside
of the scope of the architecture, keep it in some Hyper-V specific
code that doesn't involve the ITS driver.

All you need is something that will piggy-back on top of the GIC
driver using a hierarchical driver. We support that today. Of course,
you'll have to invent your own firmware interface for discovery.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.