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

Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition

Hi Ian,

On 10/30/18 4:13 PM, Ian Jackson wrote:
+Compatibility with Xen and Linux - requirements
+(Normally these issues are not a problem for x86, except perhaps for
+the network and storage controllers - see MASS STORAGE and NETWORKING,
+ * [1] Xen: The CPU and other hardware must be supported by current
+   versions of xen-unstable, at the very least.
+ * [2] Linux: The CPU and other hardware must be supported by existing
+   widely available versions of Linux.  There are two principal
+   requirements:
+   + Baremetal boot from Debian stable or stable-backports:
+     A suitable Linux kernel binary which can boot baremetal on the
+     proposed hardware must be available from Debian (at least
+     `stable', or, if that is not possible `stable-backports').  It is
+     not OK to require a patched version of Linux, or a version of
+     Linux built from a particular git branch, or some such.  If the
+     required kernel is not available in Debian, the vendor should
+     first work with the Debian project to ensure and validate that
+     the Debian stable-backports kernel binaries boot on the proposed
+     hardware.

While I understand this point, I think this is going to limit us a lot on the choice of hardware for Arm. While Debian is quite famous on the Server world, this is less the case on the automotive/embedded world where they tend to have there custom distribution.

Most of the time, the issue to boot Debian is related to the kernel. Yet, the price might be too high for some of the vendors to donate the hardware. Furthermore, at the moment Osstest is stuck on Jessie. This version does not support Thunder-X (stealing power and heating data for the past year and half...) and hardwares that will be donated in the next few months (i.e Renesas R-Car, and Xilinx MPSoc).

I still want to encourage vendor to work upstream but I would relax the requirements here to "Xen Arm kernel branch".

+   + Boot under Xen with Linux kernel built from source code.
+     For x86, recent Linux LTS or mainline kernel source code must be
+     able to boot under Xen, on the proposed hardware.
+     For ARM, there is a special Xen ARM kernel branch.  It must be
+     able to boot under Xen, on the proposed hardware.

I still want to keep that branch very close to Linux upstream. So it might be worth to say we have the liberty to not accept there patch...

+ * Board-specific Linux and Xen versions are not acceptable.

... That will avoid a vendor to try to workaround this by asking to merge hundreds of patch in "Xen Arm kernel" branch.

+ * Hardware vendor offering a "board support package" is a red flag.
+   We will not be using a "board support package".  If we are offered
+   one we will need explicit confirmation, and perhaps verification,
+   of the points above.
+ * For ARM systems using Device Tree: xxx what to write here ?
IIRC we are using the DT from the Linux tree. This was to workaround broken backward compatibility on the cubieboard. Am I correct?

I would write: "The firmware should provide a Device-Tree working for all version of Linux or provide a mechanisms to load a different Device-Tree at boot."


Julien Grall

Xen-devel mailing list



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