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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Thu, 21 May 2015, Jan Beulich wrote:
> >>> On 21.05.15 at 12:34, <julien.grall@xxxxxxxxxx> wrote:
> > On 21/05/15 07:22, Jan Beulich wrote:
> >> The linked to document (on our wiki) is versioned 0.<something>,
> >> which doesn't look like a final stable version. The same applies to
> >> the other (STAO?) one.
> > 
> > That's a mistake in the version number. Those tables has been reviewed
> > by Citrix and Linaro people and we agreed about the final tables.
> 
> And Citriy+Linaro are the standardizing body here? With no-one
> else involved?

Sorry Jan, it would have been far nicer to discuss this in public with
the community, but unfortunately one needs to be a UEFI Forum member to
be able to submit requests to it. Both Citrix and Linaro are.

But the good news is that now that we positively reserved a signature
("XENV") and we established that the relative table is externally
handled by Xen Project, we can safely discuss the evolution of the spec
in public.

But we should have sent an email to xen-devel about this sooner, sorry.


> >>> For the device tree, we
> >>> include a new node. For ACPI, this table allow us to know the we are
> >>> running on Xen.
> >> 
> >> Which seems superseded by 6.0's hypervisor vendor identification
> >> in FADT. And the OEM IDs in various table headers could have
> >> served such identification purposes too, as could have "OEMx"
> >> tables.
> > 
> > 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.

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.

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.

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