Re: [Xen-devel] [PATCH v2 26/41] arm : acpi add xen environment table
+shannon On 29 May 2015 at 16:13, Jan Beulich jbeul...@suse.com wrote: On 29.05.15 at 12:31, stefano.stabell...@eu.citrix.com wrote: On Thu, 28 May 2015, Jan Beulich wrote: On 28.05.15 at 14:12, stefano.stabell...@eu.citrix.com 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, stefano.stabell...@eu.citrix.com wrote: On Thu, 28 May 2015, Jan Beulich wrote: On 28.05.15 at 12:58, stefano.stabell...@eu.citrix.com 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 29.05.15 at 12:31, stefano.stabell...@eu.citrix.com wrote: On Thu, 28 May 2015, Jan Beulich wrote: On 28.05.15 at 14:12, stefano.stabell...@eu.citrix.com 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 Wed, 27 May 2015, Jan Beulich wrote: On 26.05.15 at 19:34, stefano.stabell...@eu.citrix.com wrote: On Thu, 21 May 2015, Jan Beulich wrote: On 21.05.15 at 12:34, julien.gr...@citrix.com 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 Thu, 28 May 2015, Jan Beulich wrote: On 28.05.15 at 12:58, stefano.stabell...@eu.citrix.com 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, stefano.stabell...@eu.citrix.com 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 28.05.15 at 14:12, stefano.stabell...@eu.citrix.com wrote: On Thu, 28 May 2015, Jan Beulich wrote: On 28.05.15 at 12:58, stefano.stabell...@eu.citrix.com 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 26.05.15 at 19:34, stefano.stabell...@eu.citrix.com wrote: On Thu, 21 May 2015, Jan Beulich wrote: On 21.05.15 at 12:34, julien.gr...@citrix.com 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 24/05/2015 09:16, Parth Dixit wrote: On 21 May 2015 at 17:11, Julien Grall julien.gr...@citrix.com mailto:julien.gr...@citrix.com wrote: On 21/05/15 12:38, Jan Beulich wrote: On 21.05.15 at 12:52, julien.gr...@citrix.com mailto:julien.gr...@citrix.com wrote: On 21/05/15 11:46, Jan Beulich wrote: On 21.05.15 at 12:34, julien.gr...@citrix.com 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.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@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, julien.gr...@citrix.com 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@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 julien.gr...@citrix.com wrote: On 21/05/15 12:38, Jan Beulich wrote: On 21.05.15 at 12:52, julien.gr...@citrix.com wrote: On 21/05/15 11:46, Jan Beulich wrote: On 21.05.15 at 12:34, julien.gr...@citrix.com 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? 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 20.05.15 at 19:00, julien.gr...@citrix.com wrote: On 20/05/15 17:22, Jan Beulich wrote: On 17.05.15 at 22:03, parth.di...@linaro.org 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.something, 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
On 21.05.15 at 12:52, julien.gr...@citrix.com wrote: On 21/05/15 11:46, Jan Beulich wrote: On 21.05.15 at 12:34, julien.gr...@citrix.com 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. 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 12:38, Jan Beulich wrote: On 21.05.15 at 12:52, julien.gr...@citrix.com wrote: On 21/05/15 11:46, Jan Beulich wrote: On 21.05.15 at 12:34, julien.gr...@citrix.com 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. 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, julien.gr...@citrix.com 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? 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, julien.gr...@citrix.com wrote: On 20/05/15 17:22, Jan Beulich wrote: On 17.05.15 at 22:03, parth.di...@linaro.org 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.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. 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 21/05/15 11:46, Jan Beulich wrote: On 21.05.15 at 12:34, julien.gr...@citrix.com 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. 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
Hi Jan, On 20/05/15 17:22, Jan Beulich wrote: On 17.05.15 at 22:03, parth.di...@linaro.org 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
[Xen-devel] [PATCH v2 26/41] arm : acpi add xen environment table
Xen environment table is ACPI table that is used to pass grant table
and event channel interrupt information to dom0.
Signed-off-by: Parth Dixit parth.di...@linaro.org
---
xen/include/acpi/actbl2.h | 20
1 file changed, 20 insertions(+)
diff --git a/xen/include/acpi/actbl2.h b/xen/include/acpi/actbl2.h
index 9c8d807..fc3ec2d 100644
--- a/xen/include/acpi/actbl2.h
+++ b/xen/include/acpi/actbl2.h
@@ -80,6 +80,7 @@
#define ACPI_SIG_WDDT WDDT /* Watchdog Timer Description Table */
#define ACPI_SIG_WDRT WDRT /* Watchdog Resource Table */
#define ACPI_SIG_STAO STAO /* Status Override Table */
+#define ACPI_SIG_XENV XENV /* Xen Environment Table */
#ifdef ACPI_UNDEFINED_TABLES
/*
@@ -909,6 +910,25 @@ struct acpi_table_stao {
/***
*
+ * XENV - Xen Environment Table
+ *Version 0.2
+ *
+
**/
+
+struct acpi_table_xenv {
+struct acpi_table_header header;/* Common ACPI table header */
+u64 gnt_start;/* Starting address of Xen grant table region */
+u64 gnt_size; /* Size of Xen grant table region */
+u32 evt_intr;/* Xen event channel interrupt */
+u8 evt_intr_flag;/* Flags for event channel interrupt */
+};
+
+/* Event Channel Interrupt Flags */
+#define EVT_CHN_INTR_MODE (1 0)
+#define EVT_CHN_INTR_TRIG (1 1)
+
+/***
+ *
* WAET - Windows ACPI Emulated devices Table
*Version 1
*
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
