[PATCH 2/3] rfi-flush: Make it possible to call setup_rfi_flush() again

[Michal Suchánek]

On Tue, 20 Feb 2018 20:59:18 +1100
Michael Ellerman <mpe at ellerman.id.au> wrote:

> Mauricio Faria de Oliveira <mauricfo at linux.vnet.ibm.com> writes:
> 
> > Hi Michal and Michael,
> >
> > On 02/15/2018 05:13 AM, Michal Suchánek wrote:  
> >>> From: Michael Ellerman<mpe at ellerman.id.au>
> >>>
> >>> For PowerVM migration we want to be able to call setup_rfi_flush()
> >>> again after we've migrated the partition.
> >>>
> >>> To support that we need to check that we're not trying to
> >>> allocate the fallback flush area after memblock has gone away. If
> >>> so we just fail, we don't support migrating from a patched to an
> >>> unpatched machine. Or we do support it, but there will be no RFI
> >>> flush enabled on the destination.
> >>>  
> >> This sounds bad to me. Either we support RFI flush or we don't.
> >> 
> >> If we do the fallback area should be allocated at boot so it is
> >> always available. [snip]  
> >
> > I think the problem with this is the size of the fallback area might
> > have to be different between the origin and destination systems,
> > say, a larger L1 data cache at the destination.
> >
> > In that case, the original size might not be enough to fully flush
> > the L1 data cache.
> >
> > Michael, is that the reason it is done that way?  I thought of that,
> > but don't know for sure.  
> 
> No, supporting different cache sizes is a good idea though :)
> 
> I did it the way I did because otherwise we waste memory on every
> system on earth just to support a use case that we don't actually
> intend for anyone to ever use - ie. migrating from a patched machine
> to an unpatched machine.

If you have multiple hosts running some LPMs and want to update them
without shutting down the whole thing I suppose it might easily happen
that a machine (re)started on a patched host is migrated to unpatched
host.

> 
> In fact without further checks we'd be allocating the fallback area on
> powernv machines which don't even support LPM.

They support suspend to disk which basically amounts to the same thing.
Downgrading the firmware while in sleep does not sound like a good
idea, though.

> 
> So that just seemed a bit gross.
> 
> I think I'm inclined to leave it the way it is, unless you feel
> strongly about it Michal?

I think it would be more user friendly to either support the fallback
method 100% or remove it and require patched firmware. 

Thanks

Michal