Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

[Andrew Turner]

On Thu, 10 Sep 2015 16:41:56 +0800
Shannon Zhao  wrote:

> From: Shannon Zhao 
> 
> These EFI stub parameters are used to internal communication between
> EFI stub and Linux kernel and EFI stub creates these parameters. But
> for Xen on ARM when booting with UEFI, Xen will create a minimal DT
> providing these parameters for Dom0 and Dom0 is not only Linux
> kernel, but also other OS (such as FreeBSD) which will be used in the
> future. So here we plan to standardize the names by dropping the
> prefix "linux," and make them common to other OS. Also this will not
> break the compatibility since these parameters are used to internal
> communication between EFI stub and kernel.

It is unlikely FreeBSD will use this property when booting ad Xen dom0.
The kernel expects to be passed a data structure to find boot this
information.

My preference would be to have the FreeBSD loader load the xen binary,
the FreeBSD kernel, and set up these data structs before passing
control to Xen, with the information it needs to boot the kernel. My
understanding is this is how it is done on x86.

I can see a few issues with this where, for example, the device tree or
ACPI tables need to be modified, but these should be solvable.

Andrew

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

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

[Andrew Turner]

On Wed, 12 Aug 2015 10:21:55 +0100
Julien Grall julien.gr...@citrix.com wrote:

 Hi,
 
 (Cc Andrew Turner who worked on the ACPI port for FreeBSD ARM64)
 
 On 12/08/2015 09:52, Ian Campbell wrote:
  On Wed, 2015-08-12 at 11:04 +0800, Shannon Zhao wrote:
  Hi Julien,
 
  On 2015/8/12 0:19, Julien Grall wrote:
  Hi Shannon,
 
  On 07/08/15 03:11, Shannon Zhao wrote:
  2. Create minimal DT to pass required information to Dom0
  --
  The minimal DT mainly passes Dom0 bootargs, address and size of
  initrd
  (if available), address and size of uefi system table, address
  and size
  of uefi memory table, uefi-mmap-desc-size and uefi-mmap-desc-ver.
 
  An example of the minimal DT:
  / {
   #address-cells = 2;
   #size-cells = 1;
   chosen {
   bootargs = kernel=Image console=hvc0
  earlycon=pl011,0x1c09
  root=/dev/vda2 rw rootfstype=ext4 init=/bin/sh acpi=force;
   linux,initrd-start = 0x;
   linux,initrd-end = 0x;
   linux,uefi-system-table = 0x;
   linux,uefi-mmap-start = 0x;
   linux,uefi-mmap-size = 0x;
   linux,uefi-mmap-desc-size = 0x;
   linux,uefi-mmap-desc-ver = 0x;
   };

Would it be possible to add a stdout property and node for the hvc0
device? It would help FreeBSD as we use this to find the kernel
console. We check for the stdout-path, linux,stdout-path, stdout,
stdin-path, and stdin properties, in that order, with the first
property selected as the console. If none are found we fall back to
searching for a serial0 device. You can see how we find the device at
[1].

  };
 
  For details loook at
  https://github.com/torvalds/linux/blob/master/Documentation/arm/uefi.
  txt
 
  AFAICT, the device tree properties in this documentation are only
  used in order to communicate between the UEFI stub and Linux.
 
  This means that those properties are not standardize and can
  change at any time by Linux folks. They don't even live in
  Documentation/devicetree/
 
  I would also expect to see the same needs for FreeBSD running as
  DOM0 with ACPI.
 
  I'm not very clear about how FreeBSD communicates with UEFI. And
  when booting with DT, how does FreeBSD communicate with UEFI? Not
  through these properties?

FreeBSD has a tool called loader.efi. It gets loaded by UEFI, and knows
how to communicate with it. It then loads the kernel and reads any
important data the kernel may need. Finally it puts this data into a
format the kernel understands, exits the boot services, and boots the
kernel. The kernel never communicates with UEFI, we have loaded any
data we need (however this may change in the future).

In the case of the memory may loader.efi calls GetMemoryMap from
EFI_BOOT_SERVICES. It then passes this data directly to the kernel for
the kernel to parse in the early boot code.

 
  These properties are in effect a Linux internal interface defined
  between the Linux UEFI stub and the Linux kernel proper. The
  stub and the kernel are notionally separate entities, although they
  are in the same tree etc there is a well defined transition/entry
  point between the two. Since they are in the same tree even though
  they are in theory separate I expect they will tend to co-evolve.
 
  IIRC we discussed with some of the maintainers (at Connect?) making
  this a more formal interface, i.e. exposing the entry point to
  Linux kernel proper which understands these properties to other
  than just the Linux UEFI stub specifically to external entities
  such as Xen.
 
  Probably part of this work needs to formalise that, such as by
  moving this binding into the proper external bindings dir.
 
  At which point BSD can (hopefully!) choose to support the same
  interface.

What are the advantages of these bindings over the existing UEFI calls
to get the memory map?

Andrew

[1]
https://svnweb.freebsd.org/base/head/sys/dev/uart/uart_cpu_fdt.c?revision=281438view=markup#l127

-- 
ABT Systems Ltd
Unit 11, Hove Business Centre, Fonthill Road, Hove, BN3 6HA
Registered in England and Wales, No. 9285513

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

Re: [Xen-devel] [RFC v2] Add support for Xen ARM guest on FreeBSD

[Andrew Turner]

On Sun, 23 Nov 2014 22:35:36 +
Julien Grall julien.gr...@linaro.org wrote:
 Hello all,
 
 At the beginning of the year, I have sent a first RFC to add support
 for FreeBSD on Xen ARM [1].
...
 Major changes in this new version:
   * Add Device Tree support via Linux Boot ABI
   * Add zImage support
   * Netfront support
   * Blkfront fixes
   * DOM0 support (separate branch see below)
 
 The former item is very hackish. I was wondering if there is another
 way to do it? Or maybe we should support FreeBSD Bootloader in ARM
 guest?

I think using the loader is the correct way to handle booting in Xen. It
allows us to relocate the dtb as required. It look like a zImage then
use the Xen console to interact with the user.

 
 The patch series is divided in X parts:
   * #1 - #14: Clean up and bug fixes for Xen. They can be
 applied without the rest of the series
  * #15 - #19: Update Xen interface to 4.4 and fix
 compilation. It's required for ARM.
  * #20 - #26: Update Xen code to support ARM
  * #27 - #33: Rework the event channel code for supporting
 ARM. I will work with Royger to come with a common interface with x86
  * #34 - #36: Add support for ARM in Xen code
  * #37 - #46: ARM bug fixes and new features. Some of thoses 
 patches (#37 - #40) could be applied without the rest of the series
  * #47 - #48: Add Xen ARM platform

I have committed patches 30 and 40 as they look good. I'm not familiar
with the code to review 37 or 38, however from my quick look at 38 I
appears _bus_dmamap_load_buffer does take in to account buflen and
dmat-maxsegsz when setting sgsize just not dmat-alignment.

...
 
 TODO:
   * Add SMP/PSCI support in FreeBSD. Could be useful other
 platform too

Adding PSCI support is on my TODO lost for arm64, however I don't
expect to get on ti in until early next year.

   * Only FreeBSD to load anywhere. Currently there is a 2M
 alignment which require a patch in Xen.

If you use the loader this will be fixed as the loader can load the
kernel at the correct alignment.


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