Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Mark Rutland]

On Wed, Nov 12, 2014 at 01:59:30PM +0000, Paolo Bonzini wrote:
> 
> 
> On 12/11/2014 14:41, Mark Rutland wrote:
> > Writing a binding for the partiuclar device might be trivial. How this
> > would fit with the DT model is more complicated, and needs to be
> > specified. As far as I can see, those documents are quite strongly tied
> > to x86 ACPI (they talk in terms of OSPM, OST, GPE, APIC IDs).
> 
> OSPM -> replace with kernel driver
> OST -> used to generate events, doesn't need to be implemented in the
>        kernel driver.  Or just define the meaning based on the ACPI
>        _OST spec.
> GPE -> replace with GPIO
> APIC ID -> replace with whatever id ARM CPUs have
> 
> > I agree that we could do CPU and memory hotplug without ACPI, but we
> > need to specify the full firmware interface for doing so, and how this
> > interacts with the initial DTB if using DT.
> 
> The initial DTB has to expose the IDs for hotpluggable CPUs and the
> range for hotpluggable memory.  In the ACPI case this goes in the SRAT.
>  But none of this is insurmountable.

My only point is that it needs to be defined, not that this definition
is impossible. That does trickle into a few places -- we currently have
no way of defining a CPU in DT which is possible but not present, for
example (the status property historically means something different per
ePAPR).

> > We can't just pick-and-mix
> > portions of ACPI and state that it's specified and standard.
> 
> But that's what you already do if you want to build ACPI tables from DT.
>  You are already picking-and-mixing the variable portions of the ACPI
> tables and make a DT bindings for them.

I don't follow. I argued _against_ trying to build ACPI tables from DT
because the two don't quite match up anyway. I argued _against_ trying
to convert ACPI tables to DT in prior discussions for similar reasons.

> All that's left is to de-x86ify the existing spec (which is really
> easy), and to figure out a DT binding for it.  It's really not unlike
> any other MMIO device.

In addition to fixing up the other specs which are affected by this
(e.g. how we describe those additional CPUs). There's also some
de-ACPIing to be done in addition to de-x86ification, and we need to be
careful to ensure we have access to all the information we require in
the absence of ACPI, and that we have a well defined behaviour on both
sides of the interface for what would previously have been implicit in
ACPI.

I'm not saying that this is impossible. It's just a greater body of work
than modifying one spec.

Thanks,
Mark.