[PATCH] powerpc: ibmveth: Harden driver initilisation for kexec

Randy.Dunlap rdunlap at xenotime.net
Fri Mar 3 15:12:42 EST 2006


On Fri, 3 Mar 2006 12:10:47 +1100 Michael Ellerman wrote:

> On Fri, 3 Mar 2006 11:34, Randy.Dunlap wrote:
> > On Fri, 3 Mar 2006 11:22:45 +1100 Michael Ellerman wrote:
> > > Hi Jeff,
> > >
> > > I realise it's late, but it'd be really good if you could send this up
> > > for 2.6.16, we're hosed without it.
> >
> > I'm wondering if this means that for every virtual/hypervisor
> > situation, we have to modify any $interested_drivers.
> > Why wouldn't we come up with a cleaner solution (in the long term)?
> >
> > E.g., could the hypervisor know when one of it's virtual OSes
> > dies or reboots and release its resources then?
> 
> It does exactly that for a regular reboot, but when we kexec we _don't_ die or 
> reboot, as far as the Hypervisor is concerned it's all systems go.
> 
> It's something of a double-edged sword, we're totally in control which gives 
> us lots of flexibility, and _fast_ reboot times, but we also have to do a bit 
> of extra stuff (ie. this patch) to keep things sane.

s/this patch/some patch/

Yes, you have certainly thought about this more/longer than I have,
so why is something more generic like this bad instead of good:

Somewhere early in start_kernel() (e.g.), do an hv call that says
"free all assigned resources".

Maybe hv doesn't know "all assigned resources."
Maybe it's just that this patch is simpler than an hv change,
although this (current) patch could leave some other drivers that
need to be "fixed," while an hv change wouldn't do that.

So I'm not opposed to this current patch as a short-term solution,
but I don't think it's the right long-term solution.

---
~Randy



More information about the Linuxppc64-dev mailing list