[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On 06/09/2016 04:41 AM, Jan Beulich wrote:
>>>> On 09.06.16 at 10:13, <roger.pau@xxxxxxxxxx> wrote:
>> On Wed, Jun 08, 2016 at 06:04:01PM -0400, Boris Ostrovsky wrote:
>>> 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).
>> I will have to check this, but AFAICT, setting the Hardware-Reduced ACPI 
>> make sense IMHO for DomU, since we are not providing a PM timer, RTC, SCI or 
>> any of those PMx and GPEx registers. Not setting it would mean that we would 
>> have to provide all those in order to comply with the ACPI specification.
> That's true for the current black-or-white model, but won't be
> true anymore as soon as we allow other than emulate-all and
> emulate-nothing.

We probably don't want to be too fine-grained about what we emulate. So
one option could be that we either emulate all devices that Roger listed
above or none.

Also, there is a more definitive answer in the spec about what
HW-reduced mode means as far as SCI (and other features) is concerned:
"5.2.9 Fixed ACPI Description Table (FADT)", Note above table 5-34.


-boris


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.