[meta-virtualization] [RFC 0/8] Update to Xen 4.5.0 and add AArch64 support
Nathan Rossi
nathan.rossi at xilinx.com
Wed Feb 4 22:26:04 PST 2015
> -----Original Message-----
> From: Chris Patterson [mailto:cjp256 at gmail.com]
> Sent: Thursday, February 05, 2015 12:39 AM
> 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 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.
I have updated my branch from yours, I have also rebased it on top of current master.
>
>
> 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 :)
>
The _defaultval flag is an bitbake internal one, it is how bitbake stores the ??= value until its finished parsing. So += onto it works as desired. Looking into it I cannot find any use or mention on whether or not internal flags are acceptable for use in user recipes. I liked this method the best as it allowed for future control of what is done within to be in the meta-virtualization layer, the alternatives to get the same functionality is to either submit the change to oe-core or to use ??= and override the default (which means the override might get out of sync and cause people issues). I had initially planned on submitting the qemu changes to oe-core (until I found the _defaultval trick), do you think that would be a better approach?
Also PACKAGECONFIG += "xen" unfortunately ignores the value set by ??= and becomes just "xen", _append would work fine however it will always apply the append (even when overriding with _pn-qemu = "" from local.conf). Which is why the patch uses += to the defaultval.
Regards,
Nathan
More information about the meta-virtualization
mailing list