Re: [Xen-devel] [PATCH v2 26/41] arm : acpi add xen environment table
+shannon On 29 May 2015 at 16:13, Jan Beulich wrote: On 29.05.15 at 12:31, wrote: >> On Thu, 28 May 2015, Jan Beulich wrote: >>> >>> On 28.05.15 at 14:12, wrote: >>> > Could you please make a concrete suggestion with table names and fields? >>> >>> I already pointed you at 6.0's new FADT field "Hypervisor Vendor >>> Identity". >> >> OK, that is a decent alternative. >> >> We don't have a suitable hypercall to retrieve the evtchn PPI but we >> could add one. Overall I still prefer the table approach, but if you >> really don't want it, I can live with the hypercalls. > > I'm clearly not in the position to force any design decision onto the > ARM side of Xen. But I continue to be of the opinion that custom > tables should be a last resort approach only, which isn't warranted > here (anymore). > > Jan > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 26/41] arm : acpi add xen environment table
>>> On 29.05.15 at 12:31, wrote: > On Thu, 28 May 2015, Jan Beulich wrote: >> >>> On 28.05.15 at 14:12, wrote: >> > Could you please make a concrete suggestion with table names and fields? >> >> I already pointed you at 6.0's new FADT field "Hypervisor Vendor >> Identity". > > OK, that is a decent alternative. > > We don't have a suitable hypercall to retrieve the evtchn PPI but we > could add one. Overall I still prefer the table approach, but if you > really don't want it, I can live with the hypercalls. I'm clearly not in the position to force any design decision onto the ARM side of Xen. But I continue to be of the opinion that custom tables should be a last resort approach only, which isn't warranted here (anymore). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 26/41] arm : acpi add xen environment table
On Thu, 28 May 2015, Jan Beulich wrote: > >>> On 28.05.15 at 14:12, wrote: > > On Thu, 28 May 2015, Jan Beulich wrote: > >> >>> On 28.05.15 at 12:58, wrote: > >> > 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. > >> > >> Even more so a reason to use what base ACPI has, without any > >> custom table. > > > > Could you please make a concrete suggestion with table names and fields? > > I already pointed you at 6.0's new FADT field "Hypervisor Vendor > Identity". OK, that is a decent alternative. We don't have a suitable hypercall to retrieve the evtchn PPI but we could add one. Overall I still prefer the table approach, but if you really don't want it, I can live with the hypercalls. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 26/41] arm : acpi add xen environment table
>>> On 28.05.15 at 14:12, wrote: > On Thu, 28 May 2015, Jan Beulich wrote: >> >>> On 28.05.15 at 12:58, wrote: >> > 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. >> >> Even more so a reason to use what base ACPI has, without any >> custom table. > > Could you please make a concrete suggestion with table names and fields? I already pointed you at 6.0's new FADT field "Hypervisor Vendor Identity". Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 26/41] arm : acpi add xen environment table
On Thu, 28 May 2015, Jan Beulich wrote: > >>> On 28.05.15 at 12:58, wrote: > > 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. > > Even more so a reason to use what base ACPI has, without any > custom table. Could you please make a concrete suggestion with table names and fields? ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 26/41] arm : acpi add xen environment table
>>> On 28.05.15 at 12:58, wrote: > 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. Even more so a reason to use what base ACPI has, without any custom table. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 26/41] arm : acpi add xen environment table
On Wed, 27 May 2015, Jan Beulich wrote: > >>> On 26.05.15 at 19:34, wrote: > > On Thu, 21 May 2015, Jan Beulich wrote: > >> >>> On 21.05.15 at 12:34, 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@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 26/41] arm : acpi add xen environment table
>>> On 26.05.15 at 19:34, wrote: > On Thu, 21 May 2015, Jan Beulich wrote: >> >>> On 21.05.15 at 12:34, 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@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 26/41] arm : acpi add xen environment table
On Thu, 21 May 2015, Jan Beulich wrote:
> >>> On 21.05.15 at 12:34, wrote:
> > On 21/05/15 07:22, Jan Beulich wrote:
> >> The linked to document (on our wiki) is versioned 0.,
> >> 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@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 26/41] arm : acpi add xen environment table
On 24/05/2015 09:16, Parth Dixit wrote: On 21 May 2015 at 17:11, Julien Grall mailto:julien.gr...@citrix.com>> wrote: On 21/05/15 12:38, Jan Beulich wrote: On 21.05.15 at 12:52, mailto:julien.gr...@citrix.com>> wrote: >> On 21/05/15 11:46, Jan Beulich wrote: >> On 21.05.15 at 12:34, mailto:julien.gr...@citrix.com>> wrote: On 21/05/15 07:22, Jan Beulich wrote: > The linked to document (on our wiki) is versioned 0., > 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@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 26/41] arm : acpi add xen environment table
On 21 May 2015 at 17:11, Julien Grall wrote: > On 21/05/15 12:38, Jan Beulich wrote: > On 21.05.15 at 12:52, wrote: > >> On 21/05/15 11:46, Jan Beulich wrote: > >> On 21.05.15 at 12:34, wrote: > On 21/05/15 07:22, Jan Beulich wrote: > > The linked to document (on our wiki) is versioned 0., > > 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? if yes, i'll remove xenv table and add a new patch for hypercall, please confirm. > Regards, > > -- > Julien Grall > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 26/41] arm : acpi add xen environment table
On 21/05/15 12:38, Jan Beulich wrote: On 21.05.15 at 12:52, wrote: >> On 21/05/15 11:46, Jan Beulich wrote: >> On 21.05.15 at 12:34, wrote: On 21/05/15 07:22, Jan Beulich wrote: > The linked to document (on our wiki) is versioned 0., > 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. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 26/41] arm : acpi add xen environment table
>>> On 21.05.15 at 12:52, wrote: > On 21/05/15 11:46, Jan Beulich wrote: > On 21.05.15 at 12:34, wrote: >>> On 21/05/15 07:22, Jan Beulich wrote: The linked to document (on our wiki) is versioned 0., 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. 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. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 26/41] arm : acpi add xen environment table
On 21/05/15 11:46, Jan Beulich wrote: On 21.05.15 at 12:34, wrote: >> On 21/05/15 07:22, Jan Beulich wrote: >>> The linked to document (on our wiki) is versioned 0., >>> 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. >From the ACPI perspective, only the signature has been reserved in order to avoid someone else using it. 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. It would still be necessary to expose the event channel, grant table region... Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 26/41] arm : acpi add xen environment table
>>> On 21.05.15 at 12:34, wrote: > On 21/05/15 07:22, Jan Beulich wrote: >> The linked to document (on our wiki) is versioned 0., >> 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? >>> 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. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 26/41] arm : acpi add xen environment table
Hi Jan,
On 21/05/15 07:22, Jan Beulich wrote:
On 20.05.15 at 19:00, wrote:
>> On 20/05/15 17:22, Jan Beulich wrote:
>> On 17.05.15 at 22:03, wrote:
Xen environment table is ACPI table that is used to pass grant table
and event channel interrupt information to dom0.
>>>
>>> The documents linked to by the uefi.org web site don't look like these
>>> are final, formally acceptable definitions. I'm not sure we want to
>>> include potentially in flux things in the hypervisor when it is not clear
>>> whether by the next release these would get finalized.
>>
>> What do you mean by "formally acceptable definitions"?
>
> Oops, sorry - s/acceptable/accepted/.
>
>> The XENV table is final and accepted as a separate table handle by Xen
>> Project.
>>
>> I would have to dig into my mail to find why we decide to only give a URL...
>
> The linked to document (on our wiki) is versioned 0.,
> 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.
>
>>> Apart from that I could do with an explanation of why the XENV table
>>> is needed in the first place, considering that on x86 we get away
>>> without.
>>
>> When you boot DOM0 on ARM there is no way to know that we are running on
>> Xen (no cpuid like, no specific boot path,...).
>
> Iirc ARM has a CPUID like identification mechanism - why can't that
> be used? And if it can't be used, considering that namely ARM64
> basically has virtualization support designed in from the beginning,
> doesn't this look like a design flaw? After all - do you really see
> each hypervisor kind to define their own ACPI table as a proper,
> scalable mechanism?
The ARM CPUID describe the hardware but doesn't offer the opportunity to
extend it as x86 in order to expose Hypervisor specific CPUID.
I know there was some discussion about adding Hypervisor CPUID but so
far it's not in the spec. We have to deal with it.
>> 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.
The "OEMx" could have clashed with the one provided by the hardware.
With a separate signature reserved ("XENV" is reserved since ACPI 6.0)
we avoid any clash.
>> Furthermore, on x86 all these informations are passed via the start_info
>> structure which doesn't exits on ARM. And there would be no easy way to
>> pass it to DOM0 at startup (the memory layout is different from every
>> board).
>
> There's no start_info structure for x86 HVM. And passing a pointer
> to the entry point in a register, or via EFI GUID (as you seem to tie
> together ACPI and EFI presence) could have done the same.
The entry point register is not an option. The current impact of XEN ARM
in the OS is very miminal and mostly self-contained. We would like to
keep the same impact with the ACPI support.
There was some concerns about exposing start_info to ARM. I don't
exactly remember which one. I will let Ian, Stefano answer to this.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 26/41] arm : acpi add xen environment table
>>> On 20.05.15 at 19:00, wrote: > On 20/05/15 17:22, Jan Beulich wrote: > On 17.05.15 at 22:03, wrote: >>> Xen environment table is ACPI table that is used to pass grant table >>> and event channel interrupt information to dom0. >> >> The documents linked to by the uefi.org web site don't look like these >> are final, formally acceptable definitions. I'm not sure we want to >> include potentially in flux things in the hypervisor when it is not clear >> whether by the next release these would get finalized. > > What do you mean by "formally acceptable definitions"? Oops, sorry - s/acceptable/accepted/. > The XENV table is final and accepted as a separate table handle by Xen > Project. > > I would have to dig into my mail to find why we decide to only give a URL... The linked to document (on our wiki) is versioned 0., which doesn't look like a final stable version. The same applies to the other (STAO?) one. >> Apart from that I could do with an explanation of why the XENV table >> is needed in the first place, considering that on x86 we get away >> without. > > When you boot DOM0 on ARM there is no way to know that we are running on > Xen (no cpuid like, no specific boot path,...). Iirc ARM has a CPUID like identification mechanism - why can't that be used? And if it can't be used, considering that namely ARM64 basically has virtualization support designed in from the beginning, doesn't this look like a design flaw? After all - do you really see each hypervisor kind to define their own ACPI table as a proper, scalable mechanism? > 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. > Furthermore, on x86 all these informations are passed via the start_info > structure which doesn't exits on ARM. And there would be no easy way to > pass it to DOM0 at startup (the memory layout is different from every > board). There's no start_info structure for x86 HVM. And passing a pointer to the entry point in a register, or via EFI GUID (as you seem to tie together ACPI and EFI presence) could have done the same. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 26/41] arm : acpi add xen environment table
Hi Jan, On 20/05/15 17:22, Jan Beulich wrote: On 17.05.15 at 22:03, wrote: >> Xen environment table is ACPI table that is used to pass grant table >> and event channel interrupt information to dom0. > > The documents linked to by the uefi.org web site don't look like these > are final, formally acceptable definitions. I'm not sure we want to > include potentially in flux things in the hypervisor when it is not clear > whether by the next release these would get finalized. What do you mean by "formally acceptable definitions"? The XENV table is final and accepted as a separate table handle by Xen Project. I would have to dig into my mail to find why we decide to only give a URL... > Apart from that I could do with an explanation of why the XENV table > is needed in the first place, considering that on x86 we get away > without. When you boot DOM0 on ARM there is no way to know that we are running on Xen (no cpuid like, no specific boot path,...). For the device tree, we include a new node. For ACPI, this table allow us to know the we are running on Xen. Furthermore, on x86 all these informations are passed via the start_info structure which doesn't exits on ARM. And there would be no easy way to pass it to DOM0 at startup (the memory layout is different from every board). Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 26/41] arm : acpi add xen environment table
>>> On 17.05.15 at 22:03, wrote: > Xen environment table is ACPI table that is used to pass grant table > and event channel interrupt information to dom0. The documents linked to by the uefi.org web site don't look like these are final, formally acceptable definitions. I'm not sure we want to include potentially in flux things in the hypervisor when it is not clear whether by the next release these would get finalized. Apart from that I could do with an explanation of why the XENV table is needed in the first place, considering that on x86 we get away without. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
