linux-kernel - Re: x86/apic: MSI address malformed for "flat" driver

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]

Message-ID: <f4406990-668d-917e-3880-4cbc71012555@kernkonzept.com>
Date:   Mon, 1 Oct 2018 16:24:27 +0200
From:   Philipp Eppelt <philipp.eppelt@...nkonzept.com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        Cyril Novikov <cnovikov@...x.com>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: x86/apic: MSI address malformed for "flat" driver

On 09/11/2018 02:29 PM, Thomas Gleixner wrote:
> On Mon, 10 Sep 2018, Cyril Novikov wrote:
>> On 9/7/2018 12:11 PM, Thomas Gleixner wrote:
>>> On Thu, 6 Sep 2018, Philipp Eppelt wrote:
>>>>
>>>> The "flat" driver defines the MSI addressing scheme to be used as
>>>> logical addressing in flat mode. The MSI msg address is composed
>>>> accordingly, but sets MSI_ADDR_REDIRECTION_CPU which is a zero at bit[3].
>>>
>>> Correct. That's what it means:
>>>
>>>    * When RH is 0, the interrupt is directed to the processor listed in the
>>>      Destination ID field.
>>>
>>> So for DM:
>>>
>>>    * If RH is 0, then the DM bit is ignored and the message is sent ahead
>>>      independent of whether the physical or logical destination mode is
>>>      used.
>>>
>>> which is means that the delivery does not do any magic redirections,
>>> because the Redirection Hint is off. If RH is set, then the delivery can
>>> redirect according to the rules in the DM section. We are not using that
>>> because we want targeted single CPU delivery.
>>>
>>> The interpretation of the DID field is purely depending on the local APIC
>>> itself by matching the APIC ID against the DID field. And the local APIC ID
>>> of CPU0 is 1 << 0, i.e. 0x1 which matches the MSI message you see.
>>
>> I believe you are wrong here and the local APIC ID of CPU0 is 0.
>>
>> processor       : 0
>> vendor_id       : GenuineIntel
>> ...
>> physical id     : 0
>> siblings        : 8
>> core id         : 0
>> cpu cores       : 4
>> apicid          : 0
>>
>> The fact that the code works means that DM is not ignored when RH is 0. In
>> other words, RH=0 DM=1 means logical destination mode.
> 
> Sorry, I did not explain it very well. Let me try again.
> 
>   * If RH is 0, then the DM bit is ignored and the message is sent ahead
>     independent of whether the physical or logical destination mode is
>     used.
> 
> The PCI device simply writes the message data to that address, it does not
> even know what the individual bits mean. It's a write of data to address.
> 
> The write gets then directed to the APIC bus or the Processor System Bus
> depending on the CPU by a translation unit.

Ah, so there is a translation unit right before the apic/system bus
which translates the MSI address & data to the system bus format.
I missed that bit in the manual. I assumed a connection between RH and
DM when the APIC interprets the message.


> If RH is not set then the logic translates the message without
> modifications including the DM bit.

Albeit RH=0 the DM bit IS interpreted by the local APIC at the end as
the DM bit is part of the system bus message format? Can you point me to
some documentation on the translated message format? I guess it is
similar to the local APIC's Interrupt Command Register?

> 
> Hope that clarifies it.

Yes, thank you very much for the additional explanations.

> 
> Out of curiosity: What kind of problem are you trying to solve?

I am in the process of writing a x86_64 VMM for the L4Re OS with Linux
as a guest and are working on the PCI subsystem/MSI handling of the VMM
for virtual devices.

Cheers,
Philipp