[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