On Fri, Apr 07, 2006 at 05:09:15PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > Here is a first cut of kexec for dom0/xen, which will actually
> > kexec the physical machine from xen. The approach taken is
> > to move the architecture-dependant kexec code into a new hypercall.
>
> First you need some more security checks. On a first quick look it
> seems you can zap and takeover the whole machine from within a domU by
> kexec-booting the machine.
Yes, I think you are right, I had completely forgotten about that.
> Second I think we'll need a new kexec flag to indicate we'll go zap the
> physical machine, not the virtual machine. I'm looking into the later,
> and I think we'll be able to do both at some point in the future. Maybe
> it is enougth to care about dom0 (physical machine kexec) vs. domU
> (virtual machine kexec) only though. We certainly don't want allow
> domUs kexec the whole machine, and virtual machine kexec for dom0
> doesn't make that much sense given how tight xen and dom0 work hand-in-hand.
Sounds fine by me. The focus of what I was trying to achive is to zap
the entire physical machine, which is what the current code does. I am
actually most interested in kdump, though its not working yet. In any
case a flag makes perfect sense. Though it might make sense to add it
when more flexible incarnations of kexec are added.
> > * kexecing into xen does not seem to work, I think that
> > kexec-tools needs updating, but I have not investigated yet
>
> Yep, actually _alot_ of the kexec magic happens in userspace.
Yes, I became aware of that along the way. I'm pretty confident that
the way I have done things, if you fixed up user-space kexec so
that linux -> xen worked, then xen -> xen would also work.
--
Horms
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home