Comment 8 for bug 1761372

------- Comment From <email address hidden> 2018-04-05 12:50 EDT-------
(In reply to comment #9)
> So all that, to provide a -sxxm type that is NOT the default (not in your
> patches, so I didn't make it the default in mine).
>
> I wonder, what is the benefit of this then.
> If users need to change the machine type, then they can just as well set the
> CFPC/SBBC/IBS caps right?

I believe the issue is similar to what we initially hit with:

Bug 165081 - LP1752026- Ubuntu18.04:POWER9:DD2.2: Unable to start a KVM guest with default machine type(pseries-bionic) complaining "KVM implementation does not support Transactional Memory, try cap-htm=off" (kvm)

where due to lack of "-machine pseries-*,cap-*=on/off/*" support via libvirt we need to rely on machine type behavior to enable certain options in the interim.

>
> Since we are not changing the deafault (pseries-bionic) is what we
> essentially support.
> We don't even have to wrap it into the 2.11 type.
>
> Todays machine types in Bionic:
> [Upstream types]
> pseries-2.10 pSeries Logical Partition (PAPR compliant)
> pseries-2.11 pSeries Logical Partition (PAPR compliant)
> pseries-2.12 pSeries Logical Partition (PAPR compliant)
> [...]
> [Ubuntu recommended types (the defaults)]
> pseries pSeries Logical Partition (PAPR compliant) (alias of
> pseries-bionic)
> pseries-bionic pSeries Logical Partition (PAPR compliant) (default)
> [...]
>
> Your patch will add
> pseries-2.12-sxxm based on the 2.12 that was added in the stable 2.11.1
> patches.
> I mentioned this before on other places.
> That might be a nice simplification for users, but since 2.12 is not yet set
> in stone (at least it is on -rc now) we can't (and won't) make any
> guarantees about cross release migrations.
>
> pseries-bionic is what we can control, and the default and what we consider
> that shall work across releases.
> Since you provided the extra type as non-default convenience type I'll do
> the same.
>
> IFF there are changes to 2.12 in the remaining upstream 2.12 or the coming
> Ubuntu 18.10 development cycle we will not try (too hard) to keep e.g. a
> Bionic pseries-2.12-sxxm in sync with that of 18.10.

Doesn't seem likely to change at this point but that seems reasonable either way.

> If you want any of these sxxm defaults to be the default of the default
> machine type ... ARGL too much default exception.
> Rephrase:
> If you want the changes to the CAPs that the 2.12-sxxm type starts to be
> applied to the default machine type "pseries-bionic" let me know.
>
> Until Bionic release we could set:
> smc->default_caps.caps[SPAPR_CAP_CFPC] = SPAPR_CAP_WORKAROUND;
> smc->default_caps.caps[SPAPR_CAP_SBBC] = SPAPR_CAP_WORKAROUND;
> smc->default_caps.caps[SPAPR_CAP_IBS] = SPAPR_CAP_FIXED_CCD;
> In the pseries-bionic type (but not after release anymore).
>
> Same (=please let me know asap) is true if instead you want any of:
> pseries-2.11-sxxm
> pseries-bionic-sxxm

Adding pseries-2.11-sxxm/pseries-bionic-sxxm gives us some flexibility with different firmware/hardware and migration strategies so this would be our preference. This is also in line with how things are done with spectre-related CPU capabilities in 2.12/2.11.1 for x86 (new explicit cpu types as opposed to changed defaults).

In terms of upstream patches that need to be backported I think we also want "ppc/spapr-caps: Disallow setting workaround for spapr-cap-ibs". I got a pretty clean backport on top of 2.11.1 just cherry-picking:

ppc/spapr-caps: Define the pseries-2.12-sxxm machine type
ppc/spapr-caps: Convert cap-ibs to custom spapr-cap
ppc/spapr-caps: Disallow setting workaround for spapr-cap-ibs
ppc/spapr-caps: Convert cap-sbbc to custom spapr-cap
ppc/spapr-caps: Convert cap-cfpc to custom spapr-cap
ppc/spapr-caps: Add support for custom spapr_capabilities
target/ppc: Check mask when setting cap_ppc_safe_indirect_branch

Then an ubuntu-specific pseries-2.11-sxxm patch would basically mirror the "ppc/spapr-caps: Define the pseries-2.12-sxxm machine type" implementation and pseries-bionic-sxxm could point to that.

------- Comment From <email address hidden> 2018-04-05 12:51 EDT-------
*** Bug 166063 has been marked as a duplicate of this bug. ***