Announcing: Xen / paravirt_ops git tree

From Jeremy Fitzhardinge in xen-devel:

Over the last week I’ve been migrating the Xen paravirt_ops tree from a Mercurial patch-queue based model to a git tree.  This makes it easier for me to work with the various Linux kernel subsystem maintainers in upstreaming patches, but it should also make it easier for people in the Xen community to contribute to mainline Xen development.

At the moment the git tree is hosted on at


In general, the Xen parts of the tree are based on tip.git (…)

Interesting topic branches are:

Core Xen stuff.  Almost all merged upstream already.
/dev/evtchn driver
Changes to hook dom0 apic stuff into the platform apic code xen/dom0/backend/blkback xen/dom0/backend/core xen/dom0/backend/netback
Backend driver support
Core dom0 support code
Updates to mtrr driver
Hooks into the pci code, for both pcifront and dom0 xen/dom0/swiotlb
Swiotlb hooks
Updates to /proc/xen for dom0 support xen/fs
/proc/xen filesystem code (excl dom0-specific parts) xen/hg-queue-import
Raw dump from original hg mq patch queue.  Mostly merged into
appropriate places in git, but still here for reference.
Interrupt changes
Start of support for pvhvm drivers.
Xenbus code

If you want to get started, either xen/dom0/hackery or xen/master are the places to start;

Master dom0 branch.  This is all the interesting dom0-related topic
branches merged together, and is a superset of xen/master.
Master domU branch, with everything interesting merged in.  This is
likely to be more stable and closer to upstream than dom0/hackery.

If you want to do development against this tree, branch off the most appropriate topic branch and get hacking, and tell me when you have something you want me to pull.  I think I’ll adopt a fairly broad policy for hosting people’s topic trees, and merging into xen/master and/or xen/dom0/hackery if the trees are at least a no-op (ie, don’t break things).

At the moment I’m upstreaming everything via the x86/tip.git tree (;a=summary),
but I expect that I’ll start sending Xen-specific changes directly to Linus via this tree (obviously anything interacting with the x86 arch code will need to be coordinated with the x86 maintainers).