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

[Julien Grall <julien.grall@xxxxxxxxxx>]

On 24/05/2015 09:16, Parth Dixit wrote:
> On 21 May 2015 at 17:11, Julien Grall <julien.grall@xxxxxxxxxx
> <mailto:julien.grall@xxxxxxxxxx>> wrote:
>
>     On 21/05/15 12:38, Jan Beulich wrote:
>     >>>> On 21.05.15 at 12:52, <julien.grall@xxxxxxxxxx 
> <mailto:julien.grall@xxxxxxxxxx>> wrote:
>     >> On 21/05/15 11:46, Jan Beulich wrote:
>     >>>>>> On 21.05.15 at 12:34, <julien.grall@xxxxxxxxxx 
> <mailto: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?
>     >>
>     >> The content of this table is handled by Xen Project and can be modified
>     >> at our convenience during the review process.
>     >
>     > Now that reads as if the table contents and layout are _not_
>     > stable yet.
>
>     Sorry for been confusing.
>
>     >>>>> 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.
>     >>
>     >> It would still be necessary to expose the event channel, grant table
>     >> region...
>     >
>     > Sure, but once you know you run on Xen you could retrieve it via
>     > hypercall if there's no other means.
>
>     Good point.
>
> ok, so to summarize we are going with hypercall based approach for
> retreiving xen env. specific info instead of XENV table?
I would wait input from Stefano and Ian.

As we are talking about boot protocol, some maintainers such as Jan 
comes from the x86 world which as a different way to boot... They are 
not aware of all the background talk (during connect and by mail) we had 
and the requirements in order to make this series.
Can you provide an up to date doc/wiki page to explain how every 
components works together (i.e UEFI, boot protocol, DT, requirements...)?
> if yes, i'll remove xenv table and add a new patch for hypercall, please
> confirm.
I think we should make a consensus on the boot protocol before doing any 
change on this series.
Regards,

--
Julien Grall

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