Re: [Xen-devel] [PATCH RFC 19/20] acpi: Set HW_REDUCED_ACPI in FADT if IOAPIC is not supported

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 06/07/2016 11:41 AM, Jan Beulich wrote:
>>>> On 07.06.16 at 17:17, <boris.ostrovsky@xxxxxxxxxx> wrote:
>> On 06/07/2016 10:12 AM, Jan Beulich wrote:
>>>>>> On 07.06.16 at 16:02, <boris.ostrovsky@xxxxxxxxxx> wrote:
>>>> On 06/07/2016 02:06 AM, Jan Beulich wrote:
>>>>>>>> On 06.06.16 at 19:31, <boris.ostrovsky@xxxxxxxxxx> wrote:
>>>>>> On 06/06/2016 09:38 AM, Jan Beulich wrote:
>>>>>>>>>> On 06.04.16 at 03:25, <boris.ostrovsky@xxxxxxxxxx> wrote:
>>>>>>>> With this flags set guests will not try to set up SCI.
>>>>>>> I've just read through the respective ACPI spec section again, and
>>>>>>> I couldn't find a reference to SCI from there ("Hardware-Reduced
>>>>>>> ACPI"). Can you clarify this connection please. Also there are other
>>>>>>> consequences of setting that flag, so in order to understand the
>>>>>>> reasons behind this change in case of future problems I think the
>>>>>>> description here will need to be significantly extended, despite the
>>>>>>> change being so small.
>>>>>> My understanding is that hardware-reduced platforms don't use ACPI
>>>>>> Platform Event Model (Sec. 4.1.1) and that model requires SCI (and vice
>>>>>> versa --- SCI is present when ACPI Platform Event Model is in use). The
>>>>>> (somewhat indirect) evidence of this is in section 4.6 "The ACPI
>>>>>> Hardware Model" where is says: "In the ACPI Legacy state, the ACPI event
>>>>>> model is disabled (no SCIs are generated) ..."
>>>>> In the sum of all the non-explicit wording I can only convince myself
>>>>> that SCI is a prereq for the event model. Yet I could see this being
>>>>> an if-and-only-if, just that I couldn't find any place saying so.
>>>> Not sure how I should interpret this: do you (reluctantly, possibly)
>>>> agree that we can use HW-reduced flag to indicate that SCI is not there?
>>> I really think we need to get confirmation on this from ACPI folks.
>> Who should those people be? linux-acpi?
> That may yield valuable, but not dependable input. I'd rather think of
> folks actually working on / contributing to the spec. I'm sure Intel can
> name a few of their employees ...
>
>>> And I think (and I said so before) we need to understand all the
>>> other implications from setting that flag (i.e. we _cannot_ use this
>>> flag _just_ to indicate there's no SCI).
>> FWIW, the Microsoft's reading is
>> https://msdn.microsoft.com/en-us/windows/hardware/drivers/bringup/hardware-req
>>  
>> uirements-for-soc-based-platforms
>>
>> ACPI fixed hardware features such as the following are not required:
>>     Power Management (PM) timer
>>     Real Time Clock (RTC) wake alarm
>>     System Control Interrupt (SCI)
>>     Fixed Hardware register set (PMx_* event/control/status registers)
>>     GPE block registers (GPEx_* event/control/status registers)
>>     Embedded controller
>>
>> Also, from ACPICA perpective, HW-reduced mode appears to be the only way
>> to prevent initialization of SCI.
> Well, we could of course start out with HW-reduced mode, but we'd
> then need to settle on all aspects before any of this becomes fully
> supported.

So it looks like we can avoid needing this mode in Linux by simply
allocating an irq descriptor for the SCI. We shouldn't receive anything
on that interrupt in PVH anyway.

I don't know whether this will work for other OSs (i.e. FreeBSD).

-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel