On Sat, Aug 13, 2016 at 7:18 AM, Manjukumar Harthikote Matha <[email protected]> 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 >> <[email protected]> wrote: >>> >>> On Sun, Jul 31, 2016 at 7:49 AM, Nathan Rossi <[email protected]> >>> wrote: >>>> >>>> On Thu, Jul 28, 2016 at 7:26 AM, Alistair Francis >>>> <[email protected]> wrote: >>>>> >>>>> Signed-off-by: Alistair Francis <[email protected]> >>>>> --- >>>>> 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 -- _______________________________________________ meta-xilinx mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-xilinx
