On Tue, 20 Feb 2018 20:59:18 +1100 Michael Ellerman <m...@ellerman.id.au> wrote:
> Mauricio Faria de Oliveira <mauri...@linux.vnet.ibm.com> writes: > > > Hi Michal and Michael, > > > > On 02/15/2018 05:13 AM, Michal Suchánek wrote: > >>> From: Michael Ellerman<m...@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