> -----Original Message----- > From: Chris Patterson [mailto:[email protected]] > Sent: Thursday, February 05, 2015 12:39 AM > To: Nathan Rossi > Cc: [email protected] > 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 <[email protected]> > wrote: > > > > -----Original Message----- > > From: Chris Patterson [mailto:[email protected]] > > Sent: Wednesday, February 04, 2015 3:25 PM > > To: Nathan Rossi > > Cc: [email protected] > > 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 > <[email protected]> wrote: > > > > > > > > > > On Mon, Feb 2, 2015 at 2:15 AM, Chris Patterson > <[email protected]> > > wrote: > > > > > > > > > > On Thu, Jan 29, 2015 at 11:44 PM, Chris Patterson > > <[email protected]> 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 > > <[email protected]> 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 > > [email protected] > > > 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 > <[email protected]> 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 -- _______________________________________________ meta-virtualization mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-virtualization
