linux-kernel - Re: [PATCH v2 8/8] x86/ioapic: Generate RTE directly from parent irqchip's MSI message

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: <87sga56hes.fsf@nanos.tec.linutronix.de>
Date:   Fri, 23 Oct 2020 00:10:35 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     David Woodhouse <dwmw2@...radead.org>, x86@...nel.org
Cc:     kvm <kvm@...r.kernel.org>, Paolo Bonzini <pbonzini@...hat.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-hyperv@...r.kernel.org
Subject: Re: [PATCH v2 8/8] x86/ioapic: Generate RTE directly from parent irqchip's MSI message

On Thu, Oct 22 2020 at 23:43, Thomas Gleixner wrote:
> On Fri, Oct 09 2020 at 11:46, David Woodhouse wrote:
> Aside of that it works magically because polarity,trigger and mask bit
> have been set up before. But of course a comment about this is
> completely overrated.

Also this part:

> -static void mp_setup_entry(struct irq_cfg *cfg, struct mp_chip_data *data,
> -			   struct IO_APIC_route_entry *entry)
> +static void mp_setup_entry(struct irq_data *irq_data, struct mp_chip_data *data)
>  {
> +	struct IO_APIC_route_entry *entry = &data->entry;
> +
>  	memset(entry, 0, sizeof(*entry));
> -	entry->delivery_mode = apic->irq_delivery_mode;
> -	entry->dest_mode     = apic->irq_dest_mode;
> -	entry->dest	     = cfg->dest_apicid & 0xff;
> -	entry->virt_ext_dest = cfg->dest_apicid >> 8;
> -	entry->vector	     = cfg->vector;
> +
> +	mp_swizzle_msi_dest_bits(irq_data, entry);
> +
>  	entry->trigger	     = data->trigger;
>  	entry->polarity	     = data->polarity;
>  	/*

does not make sense. It did not make sense before either, but now it
does even make less sense.

During allocation this only needs to setup the I/O-APIC specific bits
(trigger, polarity, mask). The rest is filled in when the actual
activation happens. Nothing writes that entry _before_ activation.

/me goes to mop up more