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. 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 >
-- _______________________________________________ meta-virtualization mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-virtualization
