"Christian Limpach" <Christian.Limpach at xensource.com> writes: >> From: virtualization-bounces at lists.osdl.org >> [mailto:virtualization-bounces at lists.osdl.org] On Behalf Of >> Eric W. Biederman >> >> What I don't want to do is have a lot of variation in /sbin/kexec >> for loading linux under different hypervisors for no particular >> reason. > > That's very reasonable, but at the same time: > What we don't want to do is have a lot of variation in our domain > builder for loading different operating systems for no particular > reason. Sure. A reasonable concern. Do you have an ELF format windows kernel? My point being this is a fundamental point where variation happens. No boot-loader has been able to see OS vendors on a single format. I don't expect Xen will be able to change this trend. The important part is that we be able to autodetect what we are working with. > And also, I think there are much better paravirtual approaches to kexec > in a paravirtual environment: > - kexec proper is best done by putting the image in memory and then > having the control plane build a new domain using this image Yes, and /sbin/kexec composes that image, including all of the glue code necessary to make it work under Xen. Which typically is the parameter block capture. Beyond that I think the rest of your kexec implementation comments are best discussed when we have patches to that part of the code. >> We can easily stuff a hypervisor id in the parameter block. So >> we can do: "paravirts[%esi->hypervisor]->init();" > > If you make %esi->hypervisor a 32bit ident and add a lookup of > %esi->hypervisor by comparing it to paravirts.ident for each compiled in > paravirts ops structure, then this starts to look quite good. We have a 16bit field we can easily use. 32bit seems a little extravagant. > If given the choice, I would still choose the per-hypervisor entry point > though... Eric
