[Pkg-xen-devel] xen reorganization

[Ian Campbell]

On Thu, 2006-08-31 at 09:20 +0200, Bastian Blank wrote:
> On Fri, Aug 18, 2006 at 11:13:14PM +0200, Bastian Blank wrote:
> > This way I can install a new kernel and have real chances that it will
> > not break unconditionaly.
> 
> The situation changed a little bit in between. Keir Fraser wrote in
> changeset 11257:
> | From here on we hope to maintain dom0 kernel compatibility. This
> | promise is not extended to tool compatibility beyond the existing
> | guarantee that compatibility will not be broken within a three-level
> | stable release [3.0.2, 3.0.3, etc.].
> 
> So we may rethink that and go back to the old naming scheme. But I
> propose to do that not and maintain that for tool compatibility. Also
> they may break the dom0 kernel compatibility also and we adress this
> now.

Sorry to butt in but I'm not sure I understand that last sentence. The
Xen team will not break dom0 kernel compatibility anymore so dom0 now
has the same compatibility guarantee as has been in place for domU
kernels since the 3.0.0 release.

Or did you mean "...they may accidentally break the dom0..." in which
case that would be a bug which I hope would get fixed pretty swiftly ;-)

A bit more background for people who might be interested... The existing
dom0_ops hypercall has been split into three pieces. The new
"platform_op" contains those hypercalls which dom0 uses over and above
those which form the domU ABI simply to run (it includes MTRR access,
platform quirks etc). This platform_op interface now has the same
compatibility guarantee as the domU hypercalls.

The new "domctl" and "sysctl" hypercalls which are used by the tools to
create and manage guest domains are not subject to the compatibility
constraints. Therefore you will always be able to boot dom0 but you
might not be able to start any guests etc without tools which match the
hypervisor. I think the intention is that 'tools' here means libxenctrl
and libxenguest which abstract the hypercalls into an API which _is_
stable. I'm not sure what formal guarantee there is on that bit though.

Ian.
-- 
Ian Campbell
Current Noise: Atheist - The Formative Years

Any circuit design must contain at least one part which is obsolete, two parts
which are unobtainable, and three parts which are still under development.