From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: "Jan Beulich" <JBeulich@suse.com>,
"Roger Pau Monné" <roger.pau@citrix.com>
Cc: Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>,
Ian Jackson <ian.jackson@eu.citrix.com>,
xen-devel@lists.xen.org
Subject: Re: [PATCH RFC 19/20] acpi: Set HW_REDUCED_ACPI in FADT if IOAPIC is not supported
Date: Thu, 9 Jun 2016 10:09:45 -0400 [thread overview]
Message-ID: <575978A9.4060409@oracle.com> (raw)
In-Reply-To: <575947DA02000078000F34F5@prv-mh.provo.novell.com>
On 06/09/2016 04:41 AM, Jan Beulich wrote:
>>>> On 09.06.16 at 10:13, <roger.pau@citrix.com> 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@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.
> 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@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-06-09 14:09 UTC|newest]
Thread overview: 91+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-06 1:25 [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
2016-04-06 1:25 ` [PATCH RFC 01/20] hvmloader: Provide hvmloader_acpi_build_tables() Boris Ostrovsky
2016-06-02 12:42 ` Jan Beulich
2016-06-02 16:39 ` Boris Ostrovsky
2016-04-06 1:25 ` [PATCH RFC 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code Boris Ostrovsky
2016-06-02 12:54 ` Jan Beulich
2016-06-02 16:54 ` Boris Ostrovsky
2016-06-03 12:13 ` Jan Beulich
2016-06-03 14:42 ` Boris Ostrovsky
2016-06-03 14:55 ` Jan Beulich
2016-06-03 15:29 ` Boris Ostrovsky
2016-04-06 1:25 ` [PATCH RFC 03/20] acpi/hvmloader: Initialize vm_gid data outside " Boris Ostrovsky
2016-06-02 13:03 ` Jan Beulich
2016-06-02 17:01 ` Boris Ostrovsky
2016-04-06 1:25 ` [PATCH RFC 04/20] acpi/hvmloader: Decide which SSDTs to build in hvmloader Boris Ostrovsky
2016-06-02 13:07 ` Jan Beulich
2016-04-06 1:25 ` [PATCH RFC 05/20] acpi/hvmloader: Move passthrough initialization from ACPI code Boris Ostrovsky
2016-06-02 13:52 ` Jan Beulich
2016-04-06 1:25 ` [PATCH RFC 06/20] acpi/hvmloader: Collect processor and NUMA info in hvmloader Boris Ostrovsky
2016-06-02 14:05 ` Jan Beulich
2016-06-02 17:18 ` Boris Ostrovsky
2016-06-03 12:16 ` Jan Beulich
2016-06-03 14:49 ` Boris Ostrovsky
2016-04-06 1:25 ` [PATCH RFC 07/20] acpi/hvmloader: Set TIS header address " Boris Ostrovsky
2016-06-02 14:09 ` Jan Beulich
2016-04-06 1:25 ` [PATCH RFC 08/20] acpi/hvmloader: Make providing IOAPIC in MADT optional Boris Ostrovsky
2016-04-06 1:25 ` [PATCH RFC 09/20] acpi/hvmloader: Build WAET optionally Boris Ostrovsky
2016-06-02 14:32 ` Jan Beulich
2016-04-06 1:25 ` [PATCH RFC 10/20] acpi/hvmloader: Provide address of acpi_info as an argument to ACPI code Boris Ostrovsky
2016-06-03 16:03 ` Jan Beulich
2016-04-06 1:25 ` [PATCH RFC 11/20] acpi/hvmloader: Translate all addresses when assigning addresses in ACPI tables Boris Ostrovsky
2016-06-06 10:48 ` Jan Beulich
2016-04-06 1:25 ` [PATCH RFC 12/20] acpi/hvmloader: Link ACPI object files directly Boris Ostrovsky
2016-06-06 11:04 ` Jan Beulich
2016-06-06 14:20 ` Boris Ostrovsky
2016-06-06 14:29 ` Jan Beulich
2016-06-06 14:49 ` Boris Ostrovsky
2016-06-06 14:57 ` Jan Beulich
2016-06-06 15:31 ` Andrew Cooper
2016-06-06 15:41 ` Jan Beulich
2016-04-06 1:25 ` [PATCH RFC 13/20] acpi/hvmloader: Add stdio.h, string.h and x86.h Boris Ostrovsky
2016-06-06 11:31 ` Jan Beulich
2016-06-06 15:08 ` Boris Ostrovsky
2016-06-06 15:22 ` Jan Beulich
2016-04-06 1:25 ` [PATCH RFC 14/20] acpi/hvmloader: Replace mem_alloc() and virt_to_phys() with memory ops Boris Ostrovsky
2016-06-06 12:58 ` Jan Beulich
2016-06-06 15:46 ` Boris Ostrovsky
2016-04-06 1:25 ` [PATCH RFC 15/20] acpi: Move ACPI code to xen/common/libacpi Boris Ostrovsky
2016-06-06 13:05 ` Jan Beulich
2016-06-06 16:09 ` Boris Ostrovsky
2016-06-07 6:20 ` Jan Beulich
2016-06-07 12:24 ` Roger Pau Monné
2016-06-07 14:32 ` Boris Ostrovsky
2016-04-06 1:25 ` [PATCH RFC 16/20] x86/vlapic: Don't try to accept 8259 interrupt if !has_vpic() Boris Ostrovsky
2016-06-03 16:14 ` Jan Beulich
2016-06-03 17:50 ` Boris Ostrovsky
2016-04-06 1:25 ` [PATCH RFC 17/20] x86: Allow LAPIC-only emulation_flags for HVM guests Boris Ostrovsky
2016-06-03 16:18 ` Jan Beulich
2016-04-06 1:25 ` [PATCH RFC 18/20] libxc/acpi: Build ACPI tables for HVMlite guests Boris Ostrovsky
2016-06-02 16:26 ` Roger Pau Monné
2016-06-06 12:03 ` Wei Liu
2016-06-06 15:15 ` Boris Ostrovsky
2016-06-16 8:54 ` Wei Liu
2016-06-16 13:07 ` Boris Ostrovsky
2016-06-06 13:29 ` Jan Beulich
2016-06-06 16:59 ` Boris Ostrovsky
2016-06-07 6:17 ` Jan Beulich
2016-06-07 13:59 ` Boris Ostrovsky
2016-06-07 14:10 ` Jan Beulich
2016-06-07 14:47 ` Boris Ostrovsky
2016-06-07 15:00 ` Jan Beulich
2016-04-06 1:25 ` [PATCH RFC 19/20] acpi: Set HW_REDUCED_ACPI in FADT if IOAPIC is not supported Boris Ostrovsky
2016-06-06 13:38 ` Jan Beulich
2016-06-06 17:31 ` Boris Ostrovsky
2016-06-07 6:06 ` Jan Beulich
2016-06-07 14:02 ` Boris Ostrovsky
2016-06-07 14:12 ` Jan Beulich
2016-06-07 15:17 ` Boris Ostrovsky
2016-06-07 15:41 ` Jan Beulich
2016-06-08 22:04 ` Boris Ostrovsky
2016-06-09 8:13 ` Roger Pau Monné
2016-06-09 8:41 ` Jan Beulich
2016-06-09 14:09 ` Boris Ostrovsky [this message]
2016-04-06 1:25 ` [PATCH RFC 20/20] acpi: Make ACPI builder available to hypervisor code Boris Ostrovsky
2016-06-06 13:48 ` Jan Beulich
2016-05-09 20:10 ` [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
2016-05-10 7:25 ` Jan Beulich
2016-06-02 12:40 ` Jan Beulich
2016-06-02 16:37 ` Boris Ostrovsky
2016-06-03 7:18 ` Roger Pau Monné
2016-06-03 10:08 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=575978A9.4060409@oracle.com \
--to=boris.ostrovsky@oracle.com \
--cc=JBeulich@suse.com \
--cc=ian.jackson@eu.citrix.com \
--cc=keir@xen.org \
--cc=roger.pau@citrix.com \
--cc=tim@xen.org \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).