Okay, so it turns out the problem is
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
CONFIG_KERNEL_LZMA=y
the change was introduced by:
* Mon Jul 06 2009 Chuck Ebbert <cebbert@redhat.com>
- Use LZMA for kernel compression on X86.
Xen's bzImage loaded can only handle compressed gzip, not compressed LZMA
Switching to LZMA means that Fedora kernels cannot be booted by any deployed or upstream versions of Xen; we really should switch this back to gzip
Moving back to F12Alpha - we can easily do this in time for Alpha

Okay, we had a bit of a discussion on #fedora-virt; updating here since it's on the alpha blocker list
The gist of the conversation was:
- Switching from gzip to lzma means that Fedora 12 won't be usable on any
currently existing xen deployments
- This is analogous to the switch from vmlinuz to bzImage we made in Fedora 9,
except there was a patch to support this upstream well in advance of the
change and this patch was at least adopted by RHEL in reasonable time
- The difference here is that there isn't even upstream support yet, but we
plan to resolve that
- Suggestion is to delay switching to lzma until Fedora 13 so that upstream
and enterprise distros have time to react
- One argument against that is that Fedora shouldn't be held hostage to Xen's
deficiencies, although since Fedora is changing an ABI here which was
specifically added for Xen, I think it makes sense to give Xen time to catch
up
- Another argument is that lzma reduces the kernel size (e.g. vmlinuz 3.5M to
2.8M) and this could help livecd, but I think that's a fairly minor size
gain for dropping the ability to run on Xen

(In reply to comment #4)
> Okay, we had a bit of a discussion on #fedora-virt; updating here since it's on
> the alpha blocker list
>
> The gist of the conversation was:
>
> - Switching from gzip to lzma means that Fedora 12 won't be usable on any
> currently existing xen deployments
>
> - This is analogous to the switch from vmlinuz to bzImage we made in Fedora
> 9,
> except there was a patch to support this upstream well in advance of the
> change and this patch was at least adopted by RHEL in reasonable time
>
> - The difference here is that there isn't even upstream support yet, but we
> plan to resolve that
>
> - Suggestion is to delay switching to lzma until Fedora 13 so that upstream
> and enterprise distros have time to react
>
> - One argument against that is that Fedora shouldn't be held hostage to Xen's
> deficiencies, although since Fedora is changing an ABI here which was
> specifically added for Xen, I think it makes sense to give Xen time to
> catch
> up
>
> - Another argument is that lzma reduces the kernel size (e.g. vmlinuz 3.5M to
> 2.8M) and this could help livecd, but I think that's a fairly minor size
> gain for dropping the ability to run on Xen
Thanks Mark. As we discussed earlier today on IRC, I am working on a patch to make the Xen domain builder understand bzip2 and lzma, which I will post upstream and for RHEL-5 when it's ready. By delaying to F-13, that should give us time to get it into product, and give upstream time to get it in (maybe even in the stable 3.3 and 3.4 branches, depending on the invasiveness of the patch).
Chris Lalancette

At one point I had some patches to allow the domain builder to load a bzImage as-is and use its internal decompressor, specifically to deal with the case of the algorithm changing. It turned out to be fairly complex in a pretty fragile piece of code, and there was general pushback because "the algorithm isn't changing" (about a year ago).
Incorporating lzma into the domain builder should be pretty straightforward, at least for usermode. But I think the same libxc code is used by Xen for dom0 loading?
It would be nice, for completeness, to include support for the other possible algorithms too, though I'm not sure there's any reason to use them over lzma.