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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.
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).

Jan


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