ACPI

[Matt Sealey]

On Tue, Nov 26, 2013 at 5:32 PM, Matthew Garrett <mjg59 at srcf.ucam.org> wrote:
> On Tue, Nov 26, 2013 at 05:11:23PM -0600, Matt Sealey wrote:
>
>> Before stabbing around adding ACPI and then having DT-in-ACPI isn't
>> there a use case for an an ARM Linux kernel actually being a good
>> citizen of UEFI?
>
> That's work in progress. Patches have been posted and are getting pretty
> close to being mergeable. You can already run VExpress with UEFI.
>
>> Having UEFI pass along the DT as a configuration table as well as ACPI
>> tables should be the first order of business. It needn't be
>> DT-specific either - there's no reason that specific configuration
>> table can't define a thousand ways to boot Linux on ARM. But one or
>> two might be better for the sanity of the Linux kernel guys. In fact,
>> because UEFI hands information in the early boot process to the
>> 'application' (being the kernel), and has a very well defined API, it
>> would remove the need for weird out of band stuff like /memreserve/
>> entries in the DT and simplify and make the Linux early boot process
>> more robust and debuggable.
>
> Passing both is somewhat problematic - if one is supposed to be
> sufficient, why pass the other? It'd be pretty easy to end up with skew
> between them, and unless we're clear on what happens in the event of
> conflicting information then it's going to end badly.

Here's a theory; always pass a basic device tree that describes a
system. You know it *is* possible to get something running simply by
having

/ {
 model = "ACPI";
 cpu {
    cpu at 0 {
      device_type = "cpu";
      compatible = "arm,armv7";
    };
 };
 memory at 0 {
     device_type = "memory";
     reg = <0x0000000 0x20000000>;
 };
};

Give or take some address-cells, size-cells.. what you've lost is
interrupt controllers and whatever else, but then what you need is
some way of having a system that boots with DT somehow break into
loading ACPI information.

Right now the best way of doing that - if you're in a server
environment anyway and dictate UEFI - is the ACPI configuration table
off the System Table.

>> 2) Because you can do fancy 'scripting' as well as bus and device
>> configuration abstraction on top of description.
>
> Sure.
>
>> 3) Because there seems to be an absolutely moronic assumption that the
>> best way to get an ARMv8 server box on the market is take an existing
>> server design and just drop an ARM SoC into it and the above existing
>> code should "drop in" in that case.
>
> Well, so far we had any indication as to whether or not anyone's
> planning on doing that. I suspect it could be made to work, the question
> is how invasive the kernel changes would be.

It could be made to work; it's a stupid, stupid idea that throws any
of the benefits of using ARM in the first place out of the window. Why
would anyone do that?

>> But I can't think of a reason why an extension or companion to PSCI
>> couldn't do it, and why you WOULDN'T want to do this as an API
>> implemented via a secure monitor interface which is architecturally
>> defined on ARM where security extensions are present. I can't imagine
>> a reason why it couldn't be done over IPMI to some microcontroller or
>> dedicated external component, for the case of fans and chassis
>> components and tedious other stuff.
>
> Primarily because people want solutions that aren't tied to having an
> entirely separate computer running its own embedded OS.

Even though it is almost an absolutely hard requirement for a
production server environment to have some kind of out of band,
lights-out management implementation?

> alternative to doing things in ACPI would be to do them in TrustZone,
> and let's not encourage that.

Why not? It's the best method. Every platform has some teething
issues.. needing some time to mature. What might be a reasonable
method, and I can guarantee these will exist (Calxeda..?) is to
implement a tiny shim in TrustZone which gives an internal OOB
processor a kick to do the real work. It may have a highly restricted
address space (power control, DRAM, peripherals that it shares with
the apps processor) and be doing thermal management and whatever else,
too.. it is a solution that every server (x86, SPARC, etc.) I've ever
bought, sold or maintained for customers and in-house everywhere I've
worked has had.

What makes ARM servers so different?

> see on x86 are down to SMM code that we can't see, let alone debug. It's
> much easier to handle bugs in code that runs in the same context as the
> OS.

It really depends what the use case is... so far, none provided.

Ta,
Matt <neko at bakuhatsu.net>