linux-kernel - Re: [RFC PATCH v3 00/12] Unify interrupt mode and setup it as soon as possible

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]

Date:   Tue, 6 Jun 2017 14:50:19 +0800
From:   Dou Liyang <douly.fnst@...fujitsu.com>
To:     Thomas Gleixner <tglx@...utronix.de>
CC:     <x86@...nel.org>, <linux-kernel@...r.kernel.org>,
        <mingo@...nel.org>, <hpa@...or.com>, <ebiederm@...ssion.com>,
        <bhe@...hat.com>, <izumi.taku@...fujitsu.com>
Subject: Re: [RFC PATCH v3 00/12] Unify interrupt mode and setup it as soon as
 possible

Hi Thomas,

At 05/23/2017 09:29 AM, Dou Liyang wrote:
> Dear Thomas,
>
> At 05/23/2017 04:23 AM, Thomas Gleixner wrote:
>> Dou,
>>
>> On Wed, 10 May 2017, Dou Liyang wrote:
>>
>>> According to Ingo's and Eric's advice[1,2], Try my best to optimize the
>>> init of interrupt delivery mode for x86.
>>
>> sorry for replying late. The patchset is not forgotten, it's on my todo
>> list and I'll tend to it latest next week.
>>
>
> I am very glad to hear that. :)
>
> I will check it again and wait for your advice.

I have come to a code bottleneck. Hope to spend your precious time and
let me move on.

Following is some test results for that patchset.

In a theoretical code analysis, the patchset can wrap the original
logic.

1) The original logic of the interrupt delivery mode setup：

-Step O_1) Keep in PIC mode or virtual wire mode:

   Check (smp_found_config || !boot_cpu_has(X86_FEATURE_APIC))
     true:  PIC mode
     false: virtual wire mode

-Step O_2) Try to switch to symmetric IO mode:
   O_2_1) In up system:

     -Check disable_apic
       ture: *O_S_1* (original situation 1)
     -Check whether there is a separate or integrated chip
       don't has: *O_S_2*
     -Check !smp_found_config
       ture: *O_S_3*
     -Others:
       *O_S_4*

   O_2_2) In smp-capable system:

     -Check !smp_found_config && !acpi_lapic
       true: goto *O_2_1)*
     -Check if it is LAPIC
       don't has: *O_S_5*
     -Check !max_cpus
       true: *O_S_6*
     -read_apic_id() != boot_cpu_physical_apicid
       true: *O_S_7*
     -Others:
             *O_S_8*

2) After that patchset, the new logic:

-Step N_1) Skip step O_1 and try to switch to the final interrupt mode
    -Check disable_apic
      ture: *N_S_1* (New situation 1)
    -Check whether there is a separate or integrated chip
      ture: *N_S_2*
    -Check if (!smp_found_config)
      ture: *N_S_3*
    -Check !setup_max_cpus
      ture: *N_S_4*
    -Check read_apic_id() != boot_cpu_physical_apicid
      ture: *N_S_5*
    -Others:
            *N_S_6*

O_S_1 is covered in N_S_1
O_S_2 is covered in N_S_2
O_S_3 is covered in N_S_3
O_S_4 is covered in N_S_6
O_S_5 is covered in N_S_2
O_S_6 is covered in N_S_4
O_S_7 is covered in N_S_5
O_S_8 is covered in N_S_6

--------------------------------------------

In the actual test, It also can work well in the situations of my test
matrix

The factors of test matrix:

  X86  | SMP |LOCAL APIC|I/O APIC|UP_LATE_INIT|
----- |-----|----------|--------|------------|
32-bit|  Y  |     Y    |    Y   |     Y      |
64-bit|  N  |     N    |    N   |     N      |

disable_apic|X86_FEATURE_APIC|smp_found_config|
------------|----------------|----------------|
       0     |        0       |        0       |
       1     |        1       |        1       |

acpi_lapic|acpi_ioapic|setup_max_cpus|
----------|-----------|--------------|
      0    |     0     |      =0      |
      1    |     1     |      >0      |
>
> Thanks,
>   Liyang.
>
>> Thanks,
>>
>>     tglx
>>
>>
>>