On Tue, 20 Feb 2018 20:59:18 +1100
Michael Ellerman [off-list ref] wrote:

Mauricio Faria de Oliveira [off-list ref] writes:
=20

quoted

Hi Michal and Michael,

On 02/15/2018 05:13 AM, Michal Such=C3=A1nek wrote: =20

quoted

quoted

From: Michael Ellerman<mpe@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.
=20

This sounds bad to me. Either we support RFI flush or we don't.
=20
If we do the fallback area should be allocated at boot so it is
always available. [snip] =20

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. =20

=20
No, supporting different cache sizes is a good idea though :)
=20
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.

=20
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.

=20
So that just seemed a bit gross.
=20
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.=20

Thanks

Michal