On Mon, 5 Mar 2018 19:46:12 -0300
Mauricio Faria de Oliveira <mauri...@linux.vnet.ibm.com> wrote:
> Hi Michael, Michal,
> I got back from vacation. Checking this one.
> On 02/20/2018 02:06 PM, Michal Suchánek wrote:
> >> 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 this thread eventually closes in 'ok, so that memory has to be
> reserved/wasted anyway', that can be done only in pseries, right?
> It seems not so much memory for this particular platform/hardware.
Yes, that is what I think too.
> > 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.
> Right, but that should be temporary, I think -- after updating some of
> the hosts, the LPAR(s) can be migrated back to one of them, where the
> fallback flush is not required anymore.
Temporary, yes. But for how long?
Also is it possible to migrate between P8 and P9 in P8 compat mode?
AFAIK on P9 fallback mode is used exclusively so far.
> >> 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.
> I beg to disagree. Since the matter is a security issue, the option
> of still have some sort of fix that works on unpatched firmware does
> look good and friendly to users (rather than require 'you _must_ get
> the firmware update') IMHO.
Specifically because this is a security issue user friendly is that
user can tell clearly if the fix is applied or not. If the kernel tells
the user the fix is applied and later it tells "sorry, could not
allocate more memory. disabling fix" this is really unfriendly.