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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 27 May 2015, Jan Beulich wrote:
> >>> 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.

We already have to do stuff like that on ARM for other things too,
for example we modify the GIC and timer tables.


> 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.

Yes, your understanding is correct.


> > 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.

But this would be the same as for the hypercall, right? Except that I
guess it is easier to version a table than an hypercall.


> > 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.

Sure, we don't have to do the same thing here between x86 and ARM here.
For Xen on ARM we have been trying to export a set of ACPI tables that
actually matches the combination of virtual or physical hardware that
Dom0 is seeing. On x86 things are different.


Let's take a closer look at this table. After the boilierplate, these
are the interesting fields:

GNT Start, GNT Size
Evtchn Intr, Evtchn Intr Flags

After the table, it is clearly stated:

"The Grant Table region is optional."

and

"The Event Channel Interrupt is optional."

So I think there is no problem: we don't want to pass any info in that
table? Sure, let's not pass any. We can still use it to flag the
presence of Xen on the platform.

If we agree to that, we can move on to discussing whether we prefer to
pass the grant table region and evtchn interrupt via XENV or another
mechanism.

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