[PATCH 19/19] Documentation: ACPI for ARM64

[Christoffer Dall]

On 29 July 2014 13:28, Mark Rutland <mark.rutland at arm.com> wrote:
> On Tue, Jul 29, 2014 at 11:55:43AM +0100, Mark Rutland wrote:
>> On Tue, Jul 29, 2014 at 11:29:40AM +0100, Christoffer Dall wrote:
>> > On Mon, Jul 28, 2014 at 09:44:59AM -0700, Olof Johansson wrote:
>> > > On Mon, Jul 28, 2014 at 11:06:54AM +0100, Mark Rutland wrote:
>> >
>> > [...]
>> >
>> > > > >
>> > > > > > +Relationship with Device Tree
>> > > > > > +-----------------------------
>> > > > > > +
>> > > > > > +ACPI support in drivers and subsystems for ARMv8 should never be mutually
>> > > > > > +exclusive with DT support at compile time.
>> > > > > > +
>> > > > > > +At boot time the kernel will only use one description method depending on
>> > > > > > +parameters passed from the bootloader.
>> > > > >
>> > > > > Possibly overriden by kernel bootargs. And as debated for quite a
>> > > > > while earlier this year, acpi should still default to off -- if a DT
>> > > > > and ACPI are both passed in, DT should at this time be given priority.
>> > > >
>> > > > Why? I really don't see the logic in doing that.
>> > >
>> > > Seems like I am replying to your emails in reverse order.
>> > >
>> > > > Currently the kernel can only boot using DT, so DT will be used even if
>> > > > ACPI is present. In the presence of ACPI support in the kernel, ACPI
>> > > > would be used on said systems.
>> > >
>> > > For all the reasons we hashed out earlier this year: We can't trust that
>> > > vendors will know how to do ACPI from day one, so instead of loading up the
>> > > kernel with lots of quirks and workarounds, we'll default to not using it until
>> > > we're at a point where things look mature enough.
>> > >
>> > > The alternative is to keep this patch set out of the kernel. We can do that
>> > > too, but I don't think that really helps anyone.
>> > >
>> > > > From the discussions at the last Linaro Connect, this was seen as
>> > > > important for virtual machines which want to provide ACPI services to
>> > > > guests while still being able to boot DT-only kernels. I'll leave it to
>> > > > Grant, Rob, and Christoffer to cover that.
>> > >
>> > > Ok, waiting to see what they have to say then.
>> > >
>> >
>> > Hmm, a virtual machine implementaion may provide either a DT or ACPI (or
>> > both).  I think the point at Linaro Connect was that for a first cut,
>> > there is no obvious need to provide ACPI to VMs and to be spec
>> > compliant, server kernels must be able to boot with DT-only.  In most
>> > cases such systems will only access a few limited emulated devices
>> > (UART, GIC, RTC, flash controller) and VirtIO devices, which should just
>> > work using DT only.
>> >
>> > People are talking about adding ACPI for VM guests as well for various
>> > reasons (device passthrough for example) in which case I would always
>> > expect people to run UEFI inside their guests too (perhaps this is not
>> > 100% true in the case of Xen fast-boot scenarios though) and I would
>> > expect Linux to only see the little stub DT and ACPI.
>> >
>> > Does this clarify anything or add futher to the confusion?
>>
>> I was under the impression that there was a case where we'd have a DT
>> with HW description in a VM which also had ACPI tables, to enable a
>> kernel without ACPI support to boot in said VM (albeit with reduced
>> functionality).
>>
>> I may have got confused since the VM standards discussion at LCA-14.
>
> I took a look at the video [1,2] of said session [3], and it looks like
> I was the one arguing for the case of full description in both DT and
> ACPI, so either I was confused or I've forgotten some hallway
> discussion.
>
> I think my reasoning was somewhat flawed; if the hypervisor defaults to
> providing DT, with an option to use ACPI in certain cases (where not all
> guests would be expected to work), then that would cover the "grab an
> iso, it just works™" use case for Linux images while allowing for
> the cases where people want ACPI in the VM.
>
> The only issue with that would be catering for OSs which support ACPI
> but not DT or whose DT support is not Linux-compatible.
>
So I think this is where the spec is really useful.  Either you're
spec compliant or you're not.  Distro images will need to support DT
if they're spec compliant to v1 of the spec (yes, it's on my todo list
to publish this properly, but the hold up is not all my fault).

A v2 of the spec may mention ACPI, and it may not, and we can deal
with that problem then.

For reference, Red Hat's current arguing point for ACPI in VMs is
hotplug of things like CPUs and memory for very large VMs, but I
haven't thought too carefully about this just yet, as I don't have a
100+ core ARM 64-bit hardware lying around...

-Christoffer