linux-kernel - Re: [RFC PATCH 0/6] Unify the 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] [day] [month] [year] [list]

Message-ID: <71b049b0-1e4d-a885-91d3-03328cafb65f@cn.fujitsu.com>
Date:   Fri, 7 Apr 2017 17:39:04 +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>, <ebiederm@...ssion.com>, <bhe@...hat.com>,
        <hpa@...or.com>, <izumi.taku@...fujitsu.com>
Subject: Re: [RFC PATCH 0/6] Unify the Interrupt Mode and setup it as soon as
 possible

Hi Thomas,

At 04/06/2017 04:43 PM, Thomas Gleixner wrote:
> On Wed, 29 Mar 2017, Dou Liyang wrote:
>> The purpose of this patchset is Unifing these setup steps and executing as
>> soon as possible as follows:
>>
>>    start_kernel
>> ---------------+
>> |
>> |
>> |
>> |     init_IRQ
>> +---->---+----+
>> |        |
>> |        |      +--------------------+
>> |        +----> | 4. init_bsp_APIC   |
>> |               +--------------------+
>> v
>>
>> By the way, Also fix a bug about kexec[3].
>>
>>
>> Some doubts, need help:
>>
>> 1. Patchset has influence on IOMMU in enable_IR_x2apic(). Not sure
>> it can be in advance?
>
> That should work.
>

Got it. Thanks very much.

>> 2. Due to
>>
>> Commit 8c3ba8d04924 ("x86, apic: ack all pending irqs when crashed/on kexec")
>>
>>  ..., patchset also needs TSC and uses the "cpu_khz" in setup_local_APIC().
>> And a warning[4] will be triggered when crashed/on kexec. Not sure how to
>> modify?
>
> The local APIC timer initialization cannot be run from init_IRQ().
>

Yes, I think so.

> The problem here is that CPU and TSC frequency calibration depends on the
> PIT/HPET interrupt (irq 0) working for machines which cannot calibrate via
> MSR/CPUID or if fast calibration via PIT fails.
>

Yes, we use the CPU frequency and tsc before we calibrate them.

> So we need to split that initialization into several parts:
>
> 1) Set up the APIC/IOAPIC (including testing whether the timer interrupt
>    works)
>
> 2) Calibrate TSC
>
> 3) Set up the local APIC timer
>

Yes, correct. the patchset has splited the initialization like that.
And I don't change anything in part 2 to reduce the impact.

For the problem above, the reason is:

When do part 1 in dump-capture kernel, need clear ISR for the pending
interrupt from previous kernel, and use CPU frequency and TSC for
calculating the maximum number of cycles.

But, the CPU frequency and TSC is calibrated in part 2 late than part 1.

So, in part 1, the CPU frequency is 0, and calibrate a wrong maximum
loops.

I try to replace the loops calibration with a new way, which has
nothing to do with TSC, such as set a fixed value for max_loops. Is
that OK?

Or, may need do some work in part 1, 2, re-split the initialization.


Here is the code for clearing ISR:

unsigned long long tsc = 0, ntsc;
	long long max_loops = cpu_khz ? cpu_khz : 1000000;

	if (boot_cpu_has(X86_FEATURE_TSC))
		tsc = rdtsc();
......
......

	do {
		queued = 0;
		for (i = APIC_ISR_NR - 1; i >= 0; i--)
			queued |= apic_read(APIC_IRR + i*0x10);

		for (i = APIC_ISR_NR - 1; i >= 0; i--) {
			value = apic_read(APIC_ISR + i*0x10);
			for (j = 31; j >= 0; j--) {
				if (value & (1<<j)) {
					ack_APIC_irq();
					acked++;
				}
			}
		}
		if (acked > 256) {
			printk(KERN_ERR "LAPIC pending interrupts after %d EOI\n",
			       acked);
			break;
		}
		if (queued) {
			if (boot_cpu_has(X86_FEATURE_TSC) && cpu_khz) {
				ntsc = rdtsc();
				max_loops = (cpu_khz << 10) - (ntsc - tsc);
			} else
				max_loops--;
		}
	} while (queued && max_loops > 0);
	WARN_ON(max_loops <= 0);
... ...


Thanks,
	Liyang.

> Thanks,
>
> 	tglx
>
>
>