[meta-xilinx] [PATCH V2 3/5] config: Set the Xilinx QEMU as the prefered QEMU to build

[Nathan Rossi]

On Sat, Aug 13, 2016 at 7:18 AM, Manjukumar Harthikote Matha
<manjukumar.harthikote-matha at xilinx.com> wrote:
> Hi Nathan/Alistair,
>
>
> On 08/11/2016 04:33 AM, Nathan Rossi wrote:
>>
>> On Tue, Aug 2, 2016 at 9:52 AM, Alistair Francis
>> <alistair.francis at xilinx.com> wrote:
>>>
>>> On Sun, Jul 31, 2016 at 7:49 AM, Nathan Rossi <nathan at nathanrossi.com>
>>> wrote:
>>>>
>>>> On Thu, Jul 28, 2016 at 7:26 AM, Alistair Francis
>>>> <alistair.francis at xilinx.com> wrote:
>>>>>
>>>>> Signed-off-by: Alistair Francis <alistair.francis at xilinx.com>
>>>>> ---
>>>>>  conf/machine/include/machine-xilinx-default.inc | 2 ++
>>>>>  1 file changed, 2 insertions(+)
>>>>>
>>>>> diff --git a/conf/machine/include/machine-xilinx-default.inc
>>>>> b/conf/machine/include/machine-xilinx-default.inc
>>>>> index 02fa077..4ea68fd 100644
>>>>> --- a/conf/machine/include/machine-xilinx-default.inc
>>>>> +++ b/conf/machine/include/machine-xilinx-default.inc
>>>>> @@ -38,3 +38,5 @@ UBOOT_ELF_aarch64 ?= "u-boot.elf"
>>>>>  # kernel modules for ZynqMP
>>>>>  MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS_append_zynqmp = "
>>>>> kernel-module-mali-modules"
>>>>>
>>>>> +PREFERRED_VERSION_qemu-native = "2.2.5"
>>>>
>>>>
>>>> I am not sure if this approach will work as expected due to some other
>>>> parts of Yocto depending on QEMU in different ways. For example the
>>>> "qemu-usermode" distro flag and the corresponding linux-user execution
>>>> of tasks might break?
>>>
>>>
>>> Hmmm... How else can it be done?
>>
>>
>> 'Why not have both?' :)
>>
>> To avoid any issues with replacing qemu-native, I looked at setting it
>> up as a separate recipe. "qemu-xilinx" recipe which populates the
>> binaries in a sub-dir of the sysroots usr/bin.
>>
>> Here is a work in progress tree with the recipe:
>> https://github.com/nathanrossi/meta-xilinx/tree/nrossi/qemu-xilinx
>>
>> Essentially the binary is located here:
>> tmp-glibc/sysroots/x86_64-linux/usr/bin/qemu-xilinx/qemu-system-aarch64.
>> We can work in the ability to select the qemu to use into the runqemu
>> part, allowing to select depending on what you want to run on.
>>
> I think it should be according to PREFERRED_PROVIDER methodology and not
> build both. Currently Xilinx QEMU do support zynq, zynqmp and microblaze,
> user can change this PREFERRED_PROVIDER way to build upstream or Xilinx QEMU
> (just like kernel, u-boot etc)
>
> We have tested on various packages including xen-image-minimal with Xilinx
> QEMU, are we missing something in testing? or you witnessing any breakage
> with Xilinx QEMU and other components?
>
> Whats the strong reason for having both? I would prefer it that we built
> using PREFERRED_PROVIDER methodology and default to Xilinx QEMU in
> meta-xilinx.

So my reasoning for pushing for the multiple QEMU's (with modified
output paths) as opposed to selecting a single version approach is
essentially as follows:

 * Xilinx QEMU is primarily a system emulation fork of QEMU and as
such trails on bug fixes and support for other QEMU features that are
not in the release that it is based on
 * Xilinx QEMU is currently based on QEMU 2.2 (or slightly after
2.2?), and it is harder to track bugs/fixes that are present
 * Attempting to track, validate and maintain complete (or minimal)
functional parity with the OE QEMU version leads to no net benefits as
the Xilinx QEMU is only intended to provide additional features for
system emulation, aka Xilinx QEMU is only really providing the same as
an older release of QEMU (for non-system emulation)
 * Having a single QEMU which replaces the OE QEMU in the sysroot is
likely to lead to confusion and issues as only one version can be in
the sysroot at a time, so users that are switching machines are likely
to hit issues

Essentially I see little to no benefit from the non-system emulation
features that Xilinx QEMU is providing and the OE QEMU version is
currently (and likely to continue to be) a newer QEMU release. It is
also relatively straight forward to implement and handle the multiple
QEMU builds. This way it also puts considerably less pressure on
Xilinx to maintain and validate the parts of QEMU that are not
particularly critical to the features that are desired for customers.

Also this is actually a similar approach to how Xen handles its own
QEMU version in the xen recipes (in meta-virtualization). Except this
is for the target sysroot not the native sysroot
(http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/tree/recipes-extended/xen/xen.inc#n448).

Regards,
Nathan