Re: dom0 pvh, old projects

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

On Sep 14, 19:14, Greg Troxel wrote:
} 
} So:
} 
}   - It seems DOM0OPS is necessary and that makes sense.

     Yes, as that is what allows the kernel to communicate with
the Xen hypervisor and provide services (device backend, etc.) to
it.

}     + Will GENERIC with DOM0OPS still boot bare metal?

     I believe that it should, and if not, shouldn't be that
difficult to make it work.

}     + Should it be in GENERIC?

     This is a different debate.  It makes GENERIC more useful.
However, it could also be argued that GENERIC is already quite
bloated.

}     + Should we have XEN3_DOM0PVH with this defined?

     If it doesn't go in GENERIC, then yes.

}   - The other pseudodevices are the dom0 halves of the pv ops.
}   
}     + Will GENERIC with these still boot bare metal?

     I believe it should.  The devices should simply not attach if
not running under XEN, like any other device driver when the
underlying device isn't in the system.  If it isn't currently the
case, it shouldn't be too hard to modify their attachment routines.

}     + Should they be in GENERIC?
}     + Should we have XEN3_DOM0PVH with this defined?

     Same comments as above.

     There is a rather obvious quick test for all of this:  once
you know that your PVH kernel boots successfully under Xen, try
booting it on bare metal.

} (Or maybe alternatively a DOM0PVH.include that has them, for people to
} add?)

     This is another option.  It could even be a commented out
option in GENERIC, so it is easily enabled in a custom kernel.
However, we might still want to provide a XEN3_DOM0PVH for convenience.
Actually, once DOM0 PVH becomes stable, we should probably make it
the default DOM0 kernel as my understanding is that it will have
much better performance.

}-- End of excerpt from Greg Troxel