[meta-virtualization] [RFC 0/8] Update to Xen 4.5.0 and add AArch64 support
cjp256 at gmail.com
Sun Feb 1 23:15:21 PST 2015
On Thu, Jan 29, 2015 at 11:44 PM, Chris Patterson <cjp256 at gmail.com> wrote:
> Nice! :) I'll try to take this for a test drive this weekend and provide
> some feedback.
> On Thu, Jan 29, 2015 at 10:31 PM, Nathan Rossi <nathan.rossi at xilinx.com>
>> This patch series updates the Xen recipes to use version 4.5.0 as well as
>> refactoring and adding support for AArch64.
>> The first 6 patches of this series are relatively trivial changes: adding
>> additional files to packages, updating dependencies and adding support for
>> additional architectures ontop of x86-64. The most important change is the
>> moving of some x86 of the packages from xen-base RDEPENDS to RRECOMMENDS.
>> Patches 7 and 8 are the reason for this set being a RFC instead of just a
>> set, I am after feedback regarding the changes I have made for these
>> In these two patches I disabled the building of xen-qemu and seabios from
>> within the xen build system. There are a number of issues in wrapping the
>> build system within OE (including source fetching and cross building).
+1 with this approach. I'm sure that the qemu rev included with the xen
release is better tested and has some appropriate patches for xen users.
However, the oe-core qemu recipe is in much better shape. Someone could
break it out into its own recipe, if so desired.
> Instead of building qemu from within xen, I have configured the qemu which
>> part of oe-core to build with xen support (PACKAGECONFIG_append = "xen").
>> xen support is available in mainline qemu this allows for easier support
>> of the
>> xen device emulation via qemu. The PACKAGECONFIG option in oe-core does
>> need to
>> be updated to point to the correct depends (which is seperate to this
Agreed, maybe document in README? In my local.conf, I added:
PACKAGECONFIG_append_pn-qemu = " xen "
> SeaBIOS is disabled due to fetching issues as well as only being supported
>> x86. I have not worked out the issues around this yet. I am querying as to
>> whether supporting it is desired, if so should it be via the xen build
>> or as a seperate recipe?
+1 to breaking it out as a separate recipe, but it is important for us x86
hvm users :) If you'd like, I could attempt to port the recipe we use on
openxt to meta-virtualization.
>> Nathan Rossi (8):
>> xen: Fix and refactor common include
>> xen: Add Build and Target architecture mapping
>> xen: Move x86/arch specific components into RRECOMMENDS
>> xen: Fix up architecture specific steps
>> xen: Add aarch64 as compatible host
>> xen-*image-minimal: Setup conditional based on MACHINE_FEATURES
>> xen: Update recipe to 4.5.0
>> xen-image-minimal: Install qemu instead of xen-qemu
>> recipes-extended/images/xen-guest-image-minimal.bb | 2 +-
>> recipes-extended/images/xen-image-minimal.bb | 6 +-
>> ...lask-avoid-installing-policy-file-as-boot.patch | 26 -----
>> recipes-extended/xen/xen-arch.inc | 18 ++++
>> recipes-extended/xen/xen.inc | 113
>> recipes-extended/xen/xen_4.3.1.bb | 24 -----
>> recipes-extended/xen/xen_4.5.0.bb | 36 +++++++
>> 7 files changed, 150 insertions(+), 75 deletions(-)
>> delete mode 100644
>> create mode 100644 recipes-extended/xen/xen-arch.inc
>> delete mode 100644 recipes-extended/xen/xen_4.3.1.bb
>> create mode 100644 recipes-extended/xen/xen_4.5.0.bb
>> meta-virtualization mailing list
>> meta-virtualization at yoctoproject.org
I did some really basic testing of xen-image-minimal. I built against
master on a x86-64 host for an intel x86-64 target.
For my build, I had to set TUNE_CCARGS="" for xen as the -mno-sse flag
required in xen/arch/x86/Rules.mk was conflicting with the standard tune
args. I'm not sure the most appropriate way to do this, but that's how I
worked around it. Any ideas on a better way to handle this?
Without addressing seabios, I couldn't do much to validate running guests,
but otherwise it seem to run fine. We'll have to figure out something here.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the meta-virtualization