Re: [Xen-devel] [PATCH v2 26/41] arm : acpi add xen environment table

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 26.05.15 at 19:34, <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> On Thu, 21 May 2015, Jan Beulich wrote:
>> >>> On 21.05.15 at 12:34, <julien.grall@xxxxxxxxxx> wrote:
>> > ACPI 6.0 has been released few months after Parth and Naresh began to
>> > implement ACPI for Xen. We could take advantage of this new field.
>> 
>> If at all possible - yes please, in favor of any custom tables.
> 
> Let me give you some more context.
> 
> As Julien pointed out, neither the "cpuid" like mechanism nor the
> existing ACPI tables seemed to fit the bill, so we thought that the best
> way forward was to simply add one more ACPI table to advertise the
> presence of Xen on the platform.
> 
> Since we have a table in our hands, we might as well use it to pass some
> useful information, specifically we thought that the existing
> information passed via device tree would be a good place to start. This
> is how we got to the XENV table that we have now.
> 
> In general I think that passing information via tables or data trees,
> that are made for this purpose, is nicer compared to using hypercalls.

There are certainly up and down sides to each of them. For ACPI
tables, I'm particularly puzzled by the need to re-write XSDT/RSDT
if you want to add a table of your own to what came from firmware.
Which in turn requires the EFI configuration table to be modified or
replaced. Doable, but I doubt this is a very clean approach.

If this was only for DomU (where the tables gets crafted from
scratch anyway) it would be a different thing. But my understanding
so far was that this is particularly also (if not exclusively) for Dom0.

> Regarding stable vs non-stable, the discussion is off point. What
> matters is the version number. We can implement the current version of
> the spec, v0.2, or we can make changes to it, introduce a new version
> and implement that one instead. We can pick any version number we like.

Prior to a first consumer implementation - yes. But afterwards you
need to remain backwards compatible.

> I am biased because I contributed to the current spec, so I think that
> the version we have is reasonable, but if we want to change it that's
> also OK for me.  In fact if you like it, I guess we could try to make it
> arch-independent and use it on x86 too.

As you may already have guessed from my earlier response - I'd rather
not, unless unavoidable.

Jan


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