linux-kernel - Re: [Patch v2] x86, ACPI, irq: Add a quirk to override SCI polarity for HyperV

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:	Thu, 20 Aug 2015 17:35:40 +0800
From:	Jiang Liu <jiang.liu@...ux.intel.com>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	"Rafael J. Wysocki" <rafael@...nel.org>,
	"Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
	Nick Meier <nmeier@...rosoft.com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>
Subject: Re: [Patch v2] x86, ACPI, irq: Add a quirk to override SCI polarity
 for HyperV



On 2015/8/20 17:15, Thomas Gleixner wrote:
> On Thu, 20 Aug 2015, Jiang Liu wrote:
>> On 2015/8/19 16:40, Thomas Gleixner wrote:
>>> On Wed, 19 Aug 2015, Thomas Gleixner wrote:
>>>> On Wed, 19 Aug 2015, Jiang Liu wrote:
>>>>> On 2015/8/19 14:45, Rafael J. Wysocki wrote:
>>>>>> Well, the regression at hand has just shown that the assertion in the
>>>>>> changelog of that commit ("no need for for special treatment for GSI
>>>>>> used by ACPI SCI") does not really hold.  So, if the only motivation
>>>>>> for it was to get rid of one extra check in mp_unregister_gsi()
>>>>>> (mp_register_gsi() still needs to check if it is dealing with the SCI
>>>>>> anyway), I'd vote for reverting it.
>>>>> Hi Rafael,
>>>>> 	The motivation is to treat SCI as normal IOAPIC interrupt so
>>>>> we could enforce stricter pin attribute checking. Now it does reveal
>>>>> flaws in ACPI BIOS implementations, but we ran into trouble about how to
>>>>> handle those flaws:(
>>>>
>>>> The intent of this change is entirely correct, though it seems that
>>>> reality of ACPI is just different.
>>>>
>>>> To be on the safe side of things, I agree with Rafael that we should
>>>> revert that patch instead of introducing a single platform quirk.
>>>
>>> Jiang,
>>>
>>> can you please prepare a revert patch for this?
>> Hi Rafael and Thomas,
>> 	I have tried to revert commit cd68f6bd53cf, but found
>> it's not an easy task now.
> 
> That's what I feared
> 
>> 	When converting to hierarchical irqdomain, the IOAPIC
>> internal and interfaces have changed much, and seems no easy
>> way to revert cd68f6bd53cf. There may be three possible solutions
>> here:
>> 1) use quirk to correct SCI polarity, as the patch does.
>> 2) change IOAPIC interfaces to provide a special way to
>>    handle SCI interrupt.
>> 3) change drivers/acpi/pci_link.c to penalize SCI IRQ so it
>>    won't be used for PCI IRQ if SCI polarity conflicts with
>>    PCI IRQ polarity.
> 
> Stupid question. Is the SCI polarity ever the opposite of PCI
> polarity? I.e. is such a ACPI override valid at all? 
Hi Thomas,
	I have analyzed another system which works:
1) SCI(IRQ9) works in level, high mode (so such an ACPI override is valid)
2) there's a flag to detect whether system works in PIC or APIC mode.
3) IRQ9 may be used for PCI IRQ if system works in PIC mode.
4) IRQ9 won't be used for PCI IRQ if system works in APIC mode.
Based on the above observation, I feel solution 3) may be the best one.
Thanks!
Gerry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/