linux-kernel - Re: [PATCH 5/5] x86/kvm: Add KVM_FEATURE_MSI_EXT_DEST

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: <f27b17cf4ab64fdb4f14a056bd8c6a93795d9a85.camel@infradead.org>
Date:   Thu, 08 Oct 2020 13:55:10 +0100
From:   David Woodhouse <dwmw2@...radead.org>
To:     Thomas Gleixner <tglx@...utronix.de>, x86@...nel.org
Cc:     kvm <kvm@...r.kernel.org>, Paolo Bonzini <pbonzini@...hat.com>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 5/5] x86/kvm: Add KVM_FEATURE_MSI_EXT_DEST_ID

On Thu, 2020-10-08 at 14:05 +0200, Thomas Gleixner wrote:
> Why MSI_EXT_DEST_ID? It's enabling that for MSI and IO/APIC. The
> underlying mechanism might be the same, but APIC_EXT_DEST_ID is more
> general and then you might also make the explanation of that bit
> match the changelog.

It's enabling it for *everything* that generates MSI cycles — which
includes IOAPIC, HPET, and MSI-capable PCI devices. Hell, and anything
else which feels like generating a physical address cycle to 0xFEExxxxx
addresses.

Again, the IOAPIC is just a device for turning pin-based interrupts
into MSIs. Bits 19-4 of the address it writes to are taken directly
from bits 63-48 of the IOAPIC RTE. There's complexity elsewhere but for
*those* bits, It just uses the bits it's given, just like a PCI device
or an HPET would. 

When I implemented this in qemu I didn't even *touch* the IOAPIC
support; it doesn't affect the IOAPIC at all, just like it doesn't
affect the HPET or any of the MSI-capable PCI devices that qemu
emulates. They just put the bits on the bus that they're told to, when
they want to generate an interrupt.

This feature is an MSI feature.

Not an HPET feature.

Not a PCI feature.

Not an IOAPIC feature.

The fact that a *Linux* guest has special-case knowledge in its IOAPIC
driver that duplicates what the MSI message composition does, is not a
good justification for naming the feature bit bizarrely.

In fact I'm really tempted to make Linux's io_apic.c just use
irq_chip_compose_msi_msg() and swizzle the bits out of the message
identically for IR and non-IR alike (modulo the pin hack), and delete
the IR_IO_APIC_route_entry struct completely. 

That also completely removes the ext_dest_id trick from visibility in
io_apic.c. And might avoid further confusion.

Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5174 bytes)