[meta-virtualization] [RFC 0/8] Update to Xen 4.5.0 and add AArch64 support

Chris Patterson cjp256 at gmail.com
Wed Feb 4 06:39:10 PST 2015


On Wed, Feb 4, 2015 at 4:11 AM, Nathan Rossi <nathan.rossi at xilinx.com>
wrote:

> > -----Original Message-----
> > From: Chris Patterson [mailto:cjp256 at gmail.com]
> > Sent: Wednesday, February 04, 2015 3:25 PM
> > To: Nathan Rossi
> > Cc: meta-virtualization at yoctoproject.org
> > Subject: Re: [meta-virtualization] [RFC 0/8] Update to Xen 4.5.0 and add
> > AArch64 support
> >
> >
> >
> > On Wed, Feb 4, 2015 at 12:21 AM, Chris Patterson <cjp256 at gmail.com>
> wrote:
> >
> >
> >
> >
> >       On Mon, Feb 2, 2015 at 2:15 AM, Chris Patterson <cjp256 at gmail.com>
> > wrote:
> >
> >
> >
> >
> >               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> wrote:
> >
> >
> >                               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 patch
> >                               set, I am after feedback regarding the
> changes I
> > have made for these patches.
> >                               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 xen
> >                               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 is
> >                               part of oe-core to build with xen support
> > (PACKAGECONFIG_append = "xen"). Since
> >                               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 patch
> >                               set).
> >
> >
> >
> >
> >
> >               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 on
> >                               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 system
> >                               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.
> >
> >
> >
> >
> >       Actually, it seems to go beyond just the rom bin(s) with hvmloader.
> > What about making it arch dependent feature?
> >
> >
> >
> >
> > My mailing list foo is weak this week.  Please ignore the above comment,
> I
> > forgot that was in the old draft. :)
> >
> >
> >
> >
> >
> >                               Thanks,
> >
> >                               Nathan
> >
> >                               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 recipes-
> > extended/xen/files/flask-avoid-installing-policy-file-as-boot.patch
> >                                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
> >
> >                               --
> >                               2.1.1
> >
> >                               --
> >
>  _______________________________________________
> >                               meta-virtualization mailing list
> >                               meta-virtualization at yoctoproject.org
> >
> https://lists.yoctoproject.org/listinfo/meta-
> > virtualization
> >
> >
> >
> >
> >
> >               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.
> >
> >
> >               Nice work!
> >
> >               Cheers,
> >               -Chris
> >
> >
> >
> >
> >       Hey Nathan.  I made some progress on splitting out the firmware-
> > related packages on top of your patches.  I added a xen-hvmloader recipe
> > that would somehow need to be included in the image, but only for x86. I
> > still have some work to do, but my latest build seems to be usable for
> > basic x86 hvm.
> >
> >       Work in progress @ https://github.com/cjp256/meta-
> > virtualization/tree/master
> >
>
> Hi Chris,
>
> Nice work, I'm curious if there was any particular reason for the
> splitting of xen-hvmloader? As I was able to get it into the main xen
> recipe without any fuss, and 'configure' it via PACKAGECONFIG. (see branch
> mentioned below)
>
>
Originally it was because I started with a recipe that was used elsewhere,
and the hvmloader had the requirements for the ROM bits and I expected it
to be messier.  I do not see an issue with bringing it back together as you
did, I think that approach is ideal.

I have updated the patch series, and added some additional patches I was
> working on including systemd support, qemu PACKAGECONFIG setup/defaults and
> a patch for the xen -mno-sse issue. Instead of sending another patch series
> I have just uploaded it to github. Also I have two patches on the top of
> the branch with changes cherry-picked from your branch.
>
>
> https://github.com/nathanrossi/meta-virtualization/commits/nrossi/add-aarch64-support
>
>
Thanks for that, that looks good! For the cherry-pick of the "xen: break
out firmware bits" could you just add Signed-off by for Eric Chanudet <
eric.chanudet at gmail.com> for the portions I borrowed from his other work on
openxt?  I meant to do that before I pushed.  I fixed and rebased @
https://github.com/cjp256/meta-virtualization/tree/add-aarch64-support

Otherwise, there is just some minor recipe cleanup and an issue with
hvmloader picking up ipxe I wanted to look into which could be done with
follow up patches.

Out of curiosity, I noticed in your qemu bbappend that you use
PACKAGECONFIG[_defaultval].  I've never seen that before, is that
supported?  I have seen PACKAGECONFIG += which I believe accomplishes your
goal.  Your method apparently works though :)

Regards,
> Nathan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-virtualization/attachments/20150204/7ef6e01c/attachment-0001.html>


More information about the meta-virtualization mailing list