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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

Jan

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