[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Design doc of adding ACPI support for arm64 on Xen - version 3





On 18/08/2015 00:01, Jan Beulich wrote:
On 18.08.15 at 08:43, <julien.grall@xxxxxxxxxx> wrote:
Hi Jan,

On 17/08/2015 22:10, Jan Beulich wrote:
Julien Grall <julien.grall@xxxxxxxxxx> 08/17/15 6:27 PM >>>
On 17/08/2015 08:33, Jan Beulich wrote:
On 14.08.15 at 16:59, <shannon.zhao@xxxxxxxxxx> wrote:
b) Create EFI_MEMORY_DESCRIPTOR table. This will add memory start and
size information of Dom0. And Dom0 will get the memory information
through this EFI table.

To some degree the same applies here: While I see that you have no
legacy vehicle like x86's E820, I also don't see how Dom0 - not being
able to make EFI boot or runtime services calls - would get hold of this
table. And if a non-EFI mechanism is to be used here, using the EFI
data structure would turn out to be just an arbitrary (or convenience)
decision, not something inherently required. Which I think should be
said explicitly if so, rather than leaving the reader guess.

It's not an arbitrary decision, when UEFI stub in Linux is using device
tree properties to pass the UEFI table to the kernel ([1]).

When booting on Xen with ACPI, dom0 will use the non-EFI entry point.
The easiest way to pass the memory information to Linux is using the
UEFI DT properties.

In which case it is even more arbitrary to use the EFI data structure to
convey memory information (instead of expressing it in plain DT, which is
how I blindly assume non-EFI does it). Of course there's the small chance
that "UEFI DT properties" implies a certain binary format, but it's still
odd
for a non-EFI entry point to assume EFI properties to be there...

Linux is able to boot either on ACPI or DT. When ACPI is used, the EFI
stub (mandatory) will create a small DT in order to pass the command
line and other informations (such as the EFI memory table) to the
kernel. This is because the stub is self-contained and and never use
variable living in the kernel.

In order to know whether you are booting using DT or ACPI, they check if
the DT contains only the /chosen node.

Actually the EFI-stub will always jumped on the non-EFI path.

By passing the minimal DT as suggested on the design doc, we are
avoiding to get a different code path for Xen in the kernel and we are
finally acting as the EFI-stub was a nop for DOM0.

So I don't see how this would be arbitrary...

Indeed with your explanation this doesn't look arbitrary anymore.
But none of this was spelled out in the original document.

Sorry I'm forgetting every time that you may not be aware of all the justifications.

Regards,

--
Julien Grall

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.