Opened 6 years ago

Closed 3 years ago

#7813 closed defect (wontfix)

Need to build a separate image specifically for emulation

Reported by: cjb Owned by: cscott
Priority: high Milestone: 8.2.0 (was Update.2)
Component: kernel Version: not specified
Keywords: blocks:8.2- Cc: dilinger, mstone, gregorio, dsd
Blocked By: Blocking:
Deployments affected: Action Needed: code
Verified: no

Description

We don't have a good way to virtualize builds since switching to 2.6.24+, since qemu/kvm/etc don't emulate 3dnow and the kernel refuses to boot on them. Choices:

  • get a separate kernel build for ext3
  • remove the kernel limitation that refuses to boot without 3dnow?

The former seems more likely. Michael also suggests having a tinderbox test for each new build detecting whether it boots under qemu, which I'd be happy to start doing once it's working again.

Attachments (1)

kernel-build-qemu.patch (2.5 KB) - added by dsaxena 6 years ago.
Patch to Dilinger's build scripts to spit out a qemu kernel RPM

Download all attachments as: .zip

Change History (18)

comment:1 Changed 6 years ago by dsaxena

  • Cc dilinger added

Andres,

Do you want to take this one and update your scripts to build a second kernel RPM with
3DNow disabled? That's probably the quickest solution.

comment:2 in reply to: ↑ description Changed 6 years ago by dsaxena

Replying to cjb:

We don't have a good way to virtualize builds since switching to 2.6.24+, since qemu/kvm/etc don't emulate 3dnow and the kernel refuses to boot on them. Choices:

  • get a separate kernel build for ext3

I don't know that this is the right long-term approach as I may want to run an ext3 image
directly on an XO via USB or SD. We need a separate ext3 image that pulls in this kernel
vs the ext3 image meant for use on XO.

comment:3 Changed 6 years ago by cjb

  • Cc mstone added

Michael,

I'd like to nominate this (having a bootable emulated image) as an 8.2 blocker. Do you agree?

comment:4 Changed 6 years ago by dsaxena

We need to figure out what to do about this one.

  • Easy answer is to update Dilinger's build scripts to spit out a second kernel RPM with 3dNow disabled.
  • Harder option is to setup our spec file to spit out both 3dnow and non-3dnow kernel RPMs. The spec file we're currently using are derived from ones that support building multiple kernel configs for Fedora (PAE, Xen, etc) but we're not making use of this feature and I'm not sure

how easy it would be to use it with our git kernel tree.

Unless someone complains, I'm going to implement #1.

I think long term I actually want to get rid of the kernel requirement by allowing the kernel to determine at boot time which memcpy() or clear_page() we should copy, but I'm wanting to keep kernel changes to minimal for 8.2.

comment:5 follow-up: Changed 6 years ago by cjb

Easy answer is to update Dilinger's build scripts to spit out a second kernel RPM with 3dNow disabled.

That's okay with me. We'll need to update the build scripts to pull that kernel, too.

comment:6 in reply to: ↑ 5 Changed 6 years ago by dsaxena

Replying to cjb:

Easy answer is to update Dilinger's build scripts to spit out a second kernel RPM with 3dNow disabled.

That's okay with me. We'll need to update the build scripts to pull that kernel, too.

The kernel KConfig scripts automagically enable 3DNow if the Geode CPU is selected and
making it not so, while trivial, is not the right solution:

  • No other CPU acceleration options are configurable in the kernel and we'd be diverging from this by adding a change to our Kconfig scripts.
  • More importantly, if we just build an image w/o 3DNow support and stuff that into the ext3 image, we don't make use of the 3DNow acceleration for certain operations when running from USB.

Instead, I've added a new defconfig target 'olpc_qemu_defconfig', that will build a kernel for a generic Pentium/MMX CPU that qemu supports. This kernel does not work on OLPC HW, but this is no different than what Fedora does with with their regular vs Xen kernels. We will have to pull this kernel into a third image that we build (os<build_number>.qemu?) as it is meant only for emulation and not for running on real XO HW.

This approach allows users booting from USB or SD to continue getting improved performance from the accelerated features while providing a way for emulation to work.

How difficult is it to add a new os image target to the build system? It's basically the
ext3 target with a different kernel RPM.

I'm still fleshing out the build script patches, will post when done.

comment:7 Changed 6 years ago by dsaxena

  • Cc gregorio added
  • Keywords blocks:8.2? added

Changed 6 years ago by dsaxena

Patch to Dilinger's build scripts to spit out a qemu kernel RPM

comment:8 Changed 6 years ago by dsaxena

  • Summary changed from devel_ext3 should pull a kernel that doesn't require 3dnow to Need to build a separate image specifically for emulation

comment:9 Changed 6 years ago by dsaxena

I've uploaded a patch to Dilinger's build script to spit out a kernel RPM meant specifically for emulation, using the new olpc_qemu_defconfig configuration. This needs to be committed to the olpc-2.6-rpm repository and then we need to add the code to pilgrim (I think?) to generate a new emulation OS image.

comment:10 Changed 6 years ago by cjb

  • Owner changed from dsaxena to cscott

Thanks. Scott, feel like adding a devel_emu target to pilgrim that pulls this kernel stream?

comment:11 Changed 6 years ago by tvoverbeek

FYI I have a working qemu running on Win XP on an Intel machine with 3DNow support.
The current subversion version of qemu has 3DNow emulation built-in. So I pulled a version and recompiled on Windows (Cygwin/Mingw).
Have been successfully running recent devel-ext3 images under qemu.
Of course a separate emulation kernel will make it also run under VMware player.

comment:12 follow-ups: Changed 6 years ago by dilinger

Committed the patch. Would be kind of nice to have a generic method for doing this; rather than just testing, building two separate kernels (using two separate .configs) for each branch. This would allow us to drop things like CONFIG_PIIX4 from the xo builds.

comment:13 in reply to: ↑ 12 Changed 6 years ago by dsaxena

Replying to dilinger:

Committed the patch. Would be kind of nice to have a generic method for doing this; rather than just testing, building two separate kernels (using two separate .configs) for each branch. This would allow us to drop things like CONFIG_PIIX4 from the xo builds.

ACK. The new fedora SPEC files seem to make it really easy to do different configs but they are built around rhats quilt tree. I'm going to poke fedora folks about what it would take to make them work cleanly with our trees.

comment:14 in reply to: ↑ 12 Changed 6 years ago by dsaxena

Replying to dilinger:

Committed the patch. Would be kind of nice to have a generic method for doing this; rather than just testing, building two separate kernels (using two separate .configs) for each branch. This would allow us to drop things like CONFIG_PIIX4 from the xo builds.

Did you forget to push? I don't see the change in http://dev.laptop.org/git/users/dilinger/olpc-2.6-rpm

comment:15 Changed 6 years ago by dilinger

Grr, yeah, sorry. Pushed now.

comment:16 Changed 6 years ago by kimquirk

  • Keywords blocks:8.2- added; blocks:8.2? removed

Not a blocker for 8.2.

comment:17 Changed 3 years ago by dsd

  • Cc dsd added
  • Resolution set to wontfix
  • Status changed from new to closed

we don't produce emulation images right now, see #8369

Note: See TracTickets for help on using tickets.