linux-kernel - Re: [RFC 2/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] [thread-next>] [day] [month] [year] [list]

Message-ID: <87tulpbyyk.wl-maz@kernel.org>
Date:   Tue, 22 Jun 2021 18:17:55 +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>,
        Sunil Muthuswamy <sunilmut@...rosoft.com>
Subject: Re: [RFC 2/2] irqchip/gic-v3-its: Introduce virtual ITS

On Tue, 22 Jun 2021 16:53:13 +0100,
Boqun Feng <boqun.feng@...il.com> wrote:
> 
> GICv3 allows supporting LPI without an ITS, and in order to support
> such a platform, a virtual ITS is introduced. The virtual ITS has the
> same software part as a real ITS: having an irq domain, maintaining
> ->collections and maintaining the list of devices. The only difference
> is the virtual ITS doesn't have a backed ITS therefore it cannot issue
> ITS commands nor set up device tables. The virtual ITS only manages LPIs
> and the LPIs are configured via DirectLPI interfaces.

That's not a virtual ITS. Not at all. It isn't even the shadow of an
ITS. This is... something else.

> 
> And currently the virtual ITS is initialized only if there is no ITS in
> the system and yet DirectLPI is support.
> 
> The virtual ITS approach provides the support for LPI without an ITS and
> reuses as much exisiting code as possible, and is the preparation for
> virtual PCI support on ARM64 Hyper-V guests.

<rant>
There is no translation, no isolation. This is a yet another
sorry excuse for a hack. Why can't the Hyper-V folks implement the
architecture, only the architecture, and all of it?
</rant>

> 
> Co-developed-by: Sunil Muthuswamy <sunilmut@...rosoft.com>
> Signed-off-by: Boqun Feng <boqun.feng@...il.com>
> ---
>  drivers/irqchip/irq-gic-v3-its.c | 114 ++++++++++++++++++++++++++++---
>  1 file changed, 106 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index 1916ac5d6371..4f2600377039 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -117,9 +117,16 @@ struct its_node {
>  	int			vlpi_redist_offset;
>  };
>  
> +/*
> + * LPI can be supported without ITS, in which case, a virtual its_node is
> + * initialized to allow configuring LPI with the DirectLPI approach.
> + */
> +static struct its_node *virtual_its_node;
> +
>  #define is_v4(its)		(!!((its)->typer & GITS_TYPER_VLPIS))
>  #define is_v4_1(its)		(!!((its)->typer & GITS_TYPER_VMAPP))
>  #define device_ids(its)		(FIELD_GET(GITS_TYPER_DEVBITS, (its)->typer) + 1)
> +#define is_virtual(its)		((its) == virtual_its_node)

And you can only have one?

>  
>  #define ITS_ITT_ALIGN		SZ_256
>  
> @@ -1096,6 +1103,10 @@ void name(struct its_node *its,						\
>  	unsigned long flags;						\
>  	u64 rd_idx;							\
>  									\
> +	/* Virtual ITS doesn't support ITS commands */			\
> +	if (is_virtual(its))						\
> +		return;							\
> +									\

Oh gawd...

>  	raw_spin_lock_irqsave(&its->lock, flags);			\
>  									\
>  	cmd = its_allocate_entry(its);					\
> @@ -1464,7 +1475,8 @@ static void lpi_update_config(struct irq_data *d, u8 clr, u8 set)
>  
>  	lpi_write_config(d, clr, set);
>  	if (gic_rdists->has_direct_lpi &&
> -	    (is_v4_1(its_dev->its) || !irqd_is_forwarded_to_vcpu(d)))
> +	    (is_v4_1(its_dev->its) || !irqd_is_forwarded_to_vcpu(d) ||
> +	     is_virtual(its_dev->its)))
>  		direct_lpi_inv(d);
>  	else if (!irqd_is_forwarded_to_vcpu(d))
>  		its_send_inv(its_dev, its_get_event_id(d));
> @@ -1690,6 +1702,10 @@ static void its_irq_compose_msi_msg(struct irq_data *d, struct msi_msg *msg)
>  	u64 addr;
>  
>  	its = its_dev->its;
> +
> +	/* Virtual ITS doesn't have ->get_msi_base function, skip */
> +	if (!its->get_msi_base)
> +		return;

So how do you target a redistributor? If you are going to use
DirectLPI, this should hit the GICR_SETLPIR for the relevant
redistributor.

Actually, how do you target another redistributor? You can't send a
MOVI, and you don't change the target address. And even if you could,
how do you move the pending state from one pending table to another?

Which means you probably have some other, non architectural stuff
somewhere else.

[...]

I'll stop here. I'm not taking this hack built on top of the ITS
code. Not now, not ever. If you really want to implement something
that is outside of the scope of the architecture, do it outside of the
GICv3 code, because this is just pretending to follow the architecture.

Or even better, get the Hyper-V folks to implement a *real* virtual
ITS, in the hypervisor. Yes, this is hard.

	M.

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