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

["Roger Pau Monné" <roger.pau@citrix.com>]

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@oracle.com> wrote:
> >> On 06/07/2016 10:12 AM, Jan Beulich wrote:
> >>>>>> On 07.06.16 at 16:02, <boris.ostrovsky@oracle.com> wrote:
> >>>> On 06/07/2016 02:06 AM, Jan Beulich wrote:
> >>>>>>>> On 06.06.16 at 19:31, <boris.ostrovsky@oracle.com> wrote:
> >>>>>> On 06/06/2016 09:38 AM, Jan Beulich wrote:
> >>>>>>>>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> 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.

Roger.

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